> b) it would be really nice to get rid of it completely someday
Or at the very least, to selectively not compile large chunks of stuff
that went in that I will never need. Stuff that isn't there on libc5
and other Unices. Something that takes up less than half a floppy.
And having source and binary compatibility between major releases
wouldn't hurt either!
> > Concerning devfs, I don't use it and have not really thought about it.
> > I think my point of view would be that devfs provides a different object.
> > A device node in a filesystem is a pair (pathname, dev_t).
> > Opening it gives the triple (pathname, dev_t, kdev_t).
> > What devfs provides is (pathname), after opening (pathname, kdev_t).
> Wait a second. To hell with devfs, I'm talking about any synthetic
> tree containing device nodes. Being forced to allocate a point in
> numeric namespace just to be able to associate a driver-created
> inode with (also driver-created) device... Looks rather bogus, not
> to mention the ugliness of maintaining said numeric namespace.
> > But I think the pointer kdev_t (or i_bcdev) must still be recomputed:
> > it remains true that modules can be unloaded.
> Umm... So what? They can be unloaded only when we have device not opened.
> We might leave both allocation and freeing to driver-side code (and that
> includes grok_partitions()) and let the freeing code reset ->i_bdev and
> friends in all relevant inodes.
Yep. Having to allocate/search for a device structure during open(2)
is insane. It's wasteful. For ext2fs you can do it in lookup(), and
for devfs (or similar) you can do the ideal thing: when the device
entry is registered with the FS (i.e. only once).
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to email@example.com
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/