On Mon, 10 Jan 2000, Oliver Xymoron wrote:
> > 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.
You missed the point. In the mount() you DON'T HAVE ANY STRUCT FILE.
Period. There is _no_ mount() method and there is no sane fs-independent
semantics to associate with it. It applies _only_ to block devices and it
does precisely the same as ->open(). So once you've introduced it you are
(a) facing the lack of object and (b) just got a caller-visible flag
->is_block_device. Fine, but... what did you win? You still have to create
fake struct file, struct dentry and struct inode and you _already_ have
both the method and flag. You've just bloated the set of methods. Great
idea, that...
> > > 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. ;)
Per-fs part outweights any small changes in inode proper at least 30:1.
_That_ is the target for cleanup. And yes, I prefer to have readable VFS
code first. Minor cleanup of struct inode may go when the things will
become stable.
-
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:17 EST