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/
This archive was generated by hypermail 2b29 : Sat Jan 15 2000 - 21:00:16 EST