Messages in this thread | | | Date | Mon, 10 Jan 2000 16:04:39 -0500 (EST) | From | Alexander Viro <> | Subject | Re: [ANNOUNCE] block device interfaces changes |
| |
On Sun, 9 Jan 2000, Oliver Xymoron wrote:
> On Sat, 8 Jan 2000, Alexander Viro wrote: > > > > Don't forget to include the bdev/cdev bit in devno.] > > > > No, thanks. Character devices _are_ different; by coincidence we > > are using 16bit integers to refer both to block and character devices, but > > that's about it. > > But they're still both "files". What is gained by having any code outside > of the functions that are pointed to in the file operations table know > there's a difference? I just don't get it. How is this simpler? Why can't > a device id (type:major:minor) simply be a way to locate the file > operations table for a device?
Because they are _more_ than files. Because their native interface is _not_ a file one. Because there is a way to produce a file interface from block device one and _that_ is what fs/block_dev.c does. I.e. it's an interface converter.
Now, look at the mount(). Or swapon(). Tell me, where is a file? Or inode, for that matter (esp. for root mount). See also ioctl() usage in ISOFS. Where the hell is a file? See also raw devices - there you _have_ file, but the problem is that it's already in use.
They are not files. There is a way to make a file out of a block device, and that's fine - that's all users see (almost). But for the kernel they _are_ different.
> Plus the i_bdev thing is kindof ugly too - it should be i_private or > something like the private_data in struct file. If the inode in question > is not a block device, then someone else (named pipes, perhaps?) can use > the pointer for their own private storage.
Oh, please. Yes, we can merge that with FIFO pointer. But complaining about the struct inode bloat is kinda funny - the first thing to do is going for separate allocation of per-fs data.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |