Re: [linux-usb] Re: USB device allocation

Jason Gunthorpe (jgg@ualberta.ca)
Tue, 5 Oct 1999 22:45:36 -0600 (MDT)


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/