Messages in this thread | | | Date | Tue, 5 Oct 1999 22:45:36 -0600 (MDT) | From | Jason Gunthorpe <> | Subject | Re: [linux-usb] Re: USB device allocation |
| |
On Tue, 5 Oct 1999, Theodore Y. Ts'o wrote:
> Devfs uses the dynamic filesystem idea for the first and third parts, > while it's "neat", it's not the right interface for doing things. The > problems are most obvious in the third part: /dev has state that needs
> to be persistent. If you store it in a real filesystem, you get that > for free. With devfs, you have this extra kernel code to store all of > the devices in memory, and in a real filesystem you get this for free.
One of the things I've seen mentioned before, but I'd just like to re-iterate again.. devfs is really nice if you don't actually have a filesystem with unix semantics or a r/w filesystem to store /dev on. My embedded systems use devfs because it really nicely solves those two problems.
> In order to handle persistence, in devfs you have to have this horrible > kludge where you run tar over the devfs at shutdown time. And, any
I think that is a kludge yes, but I really don't think it is an inherent flaw with the idea of a virtual /dev/ filesystem.
See, how I always just -assumed- devfs would work till I looked at it closely is that the device driver would request a device inode, and part of the request would be some wack of device-specific information. DevFS would fire that over to the 'policy module' which would be located in user space. The module would then consider that wack of device-specific information, look into a database, or whatever, and tell DevFS what that inode should look like - permissions, ownership and the path to give it. devfs then creates the inode as it was instructed. Changes to the perms/owner of the node would be passed to the userspace daemon for logging/process/discard - whatever the user wants.
For my embedded systems the absence of a daemon would just result in devfs using defaults provided by the driver.
Distributions will like this because they can ship a file that contains the distribution policy for permissions and ownership of /dev/ files [formally known as /dev/MAKEDEV] and provide a file so the user can override with their preferences. chmod/chown just become a round about way of editing the user preference file [tar hack goes away].
The entire scheme works almost as well if you don't use a virtual /dev/. You still have the weird userspace daemon controlling policy - but inside the kernel you still have the problem of assigning unique device numbers for very large busses and all the problems Richard outlines regarding the scalablility of the major/minor system. If devices are attached directly to an inode then that goes away too.
Just something to think about, Jason
- 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/
| |