Messages in this thread | | | From | (H. Peter Anvin) | Subject | My $0.02 on devd and devfs | Date | 11 Oct 1999 04:02:28 GMT |
| |
Followup to: <19991010011136.C30460@wookie.chirp.com.au> By author: Nathan Hand <nathanh@chirp.com.au> In newsgroup: linux.dev.kernel > > > One of the things I do with Linux is to write my own distribution. > > As part of this, I'm trying to build an installer that autodetects > > as much of the system as it can. Currently I need to jump through a > > lot of poorly-documented hoops to do this; for example, with a > > devfs numerating the number of partitions on a system is a simple > > case of trawling through /dev for the appropriate files, but if I > > don't have devfs, I get chore of running ``fdisk -l'' and picking > > the output apart. > > 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.
I don't think a /proc/dev/ is the right solution either; although it is less severe (since all entries in /proc/dev/ can have 600 root,root) it isn't a *solution*, really.
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".
* devd should not *delete* devices in normal operation, unless they have been superceded. Deleting device nodes is generally a destructive operation.
* On modules, additional ELF sections as needed to include necessary detection- and hopefully device information. This will be part of the "supermodule" proposal I'm working on for the Genesis boot loader ("supermodules" will be able to be either linked into the kernel or runtime loaded, using the same binary -- the idea is that Genesis will link a kernel with the necessary/desired drivers on the fly.)
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.
-hpa -- <hpa@transmeta.com> at work, <hpa@zytor.com> in private!
- 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/
| |