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/