Messages in this thread | | | Date | Mon, 10 Jan 2000 18:26:36 -0500 (EST) | From | Alexander Viro <> | Subject | Re: [ANNOUNCE] block device interfaces changes |
| |
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/
| |