Messages in this thread | | | Date | Mon, 11 Oct 1999 00:28:02 -0400 | From | Johannes Erdfelt <> | Subject | Re: My $0.02 on devd and devfs |
| |
On Mon, Oct 11, 1999, H. Peter Anvin <hpa@transmeta.com> wrote: > 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.
Thanks for putting forth your input into the matter.
I'd like to here your thoughts on major/minor allocation for PnP devices. The hypothetical example being used is connecting 1000+ modems to a machine. (Apparentely someone has done this on an Irix machine further solidifying the fact this can and will happen).
Right now, it's impossible to do with the current 8/8 split of major/minor. Some people are proposing increasing it a 16/16 split which will significantly improve the situation, but as we've fallen into in the past, any arbitrary limit will be broken.
Do you think simply increasing the major/minor will solve the problem? It seems like when you increase the major/minor space you also increase computational complexity in determining which driver owns that major/minor.
JE
- 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/
| |