Messages in this thread | | | Date | Sun, 10 Oct 1999 23:31:23 -0600 | From | Richard Gooch <> | Subject | Re: My $0.02 on devd and devfs |
| |
H. Peter Anvin writes: [I'm breaking my silence because this is one of the few coherent posts on the subject, and because it raises a point that, while I've tried to address it before, in retrospect I might not have gotten the point across.]
> By author: Nathan Hand <nathanh@chirp.com.au> > > HPA, would you be open to the idea of /proc/devices. This won't be > > a terrific loss of functionality from the existing devfs. > > I have thought a lot about this, and I have been trying to avoid > sounding like I flame. I *do* believe that devfs is a very inelegant > solution, but it is a solution to a real problem. It is not, in my > opinion however, the *right* solution. [...] > The right solution -- which the devfs people have correctly identified > -- is a user-space daemon. However, once you have the user-space > daemon, "devd", I believe you neither need nor want the virtual > filesystem, in the general case. However, I can understand that in > some configurations (like embedded systems) it may be desirable. > > This is what I would like to see: > > * A device daemon, devd, which can add devices on demand. I was > thinking of one which would receive data packets like the following: > > <stub_name, type, major, first_minor, count, naming_scheme> > > e.g. > > <"ttyS", char, 4, 64, 192, "serial"> > > ... where "serial" would mean the daemon should find the iterator > for this particular class in "/usr/lib/devd/serial.so".
OK, we agree that fundamentally, the kernel has to provide device availability information in a consistent and coherent manner to user-space. Either /proc/device_notifier or devfs can provide this. There are two ways that /proc/device_notifier could work:
- it's a true notifier, and doesn't mantain state (i.e. a list of what's already there). I see this as totally unworkable because devd would then not know about devices found before it starts
- it *does* maintain state, which is then a degenerate case of devfs.
So a stateful /proc/device_notifier could work. But I think devfs is a better approach, because:
- it does not require the daemon to parse a file to work out what devices are present. A filesystem is a natural way to present a tree structure; a file is not. Devfs is moving towards a structure that also reflects the physical topology of the hardware (i.e. bus# and slot# will appear in device paths), which will reinforce this point
- not having the virtual FS means you don't trap FS events (like inode lookups) which means that you can't do module autoloading, nor can you speculatively create arbitrary namespaces
- since you need to store the device tree structure in the kernel anyway (see above), you may as well allow it to be mounted, which gives maximum flexibility to users (and adds very little extra code).
/proc/device_notifier is a functional subset of devfs, but prohibits users to make the choice to have a virtual /dev. As I've said time and again, devfs gives *choice*. People can not use it at all, or mount it elsewhere and use devfsd to manage a disc-based /dev. Despite (often offensive) claims to the contrary, devfs won't stop people from maintaining their traditions.
> * devd should not *delete* devices in normal operation, unless they > have been superceded. Deleting device nodes is generally a > destructive operation.
Well, I don't agree, but that's a policy issue that the user can decide.
> Notice that this interface would *also* be usable for devfs (which > would have to include all the various iterators etc in kernel space, > but it would have to anyway), which makes devfs an optional, > isolated feature. This is a Good Thing: I don't have anything > against devfs as an *isolated* feature for the people who want to > use it (lazy/careless admins, embedded systems...) I *do* have a > problem with it becoming ubiquitous, and I do have a problem with it > being a requirement for each device driver. However, with this > configuration devd would effectively be the "standard" mode of > operation, and devfs would be an "alternate", using the same > interfaces.
Having devfs in the kernel *absolutely does not* mean that each device driver has to call <devfs_register>. In the early days of the patch, not all the device drivers I use were patched. Nevertheless, my system continued to work.
Regards,
Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca
- 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/
| |