On Mon, 10 Jan 2000, Alexander Viro 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.
Having a mount method on file is great. You just call it. If the file in
question doesn't support it, it says so. Alternately, you have to check
whether you're mounting a block device in the syscall. In terms of code,
it's six of one, half dozen of the other. I just think it's better to have
that half dozen down in the driver function tables or in a helper function
for block device registration rather than as if statements all over the
place.
> > 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.
The funny part is that you're one of the more vocal opponents of inode
bloat (the per-fs part in particular) so you should know better. ;)
-- "Love the dolphins," she advised him. "Write by W.A.S.T.E.."- 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