In other words, you can implement what traditional filesystems can do.
We know that. It also means devfs is superfluous. You might as well
have a devmgr process with no need for a devfs at all.
-hpa
oh come on....
a devmgr without kernel interaction would be a complicated, gross hack.
How would you handle dynamic devices with your devmgr? poll every second
for new devices? and what do you poll? Your devmgr has to get the
information about new/expired devices from somewhere - so the kernel has
to export this information somewhere. Why not in the most logical way:
directly to /dev?
Richards solution is a lot cleaner:
- A driver registers itself with devfs (in place of registering its
major/minor numbers).
- Devfs tells devfsd about it.
- devfsd decides the policy and communicates it to in-kernel devfs
- devfs creates the device accordingly
And it's a similar procedure for device un-registration.
A couple of points to take from this:
- policy is set in userspace! it could also be feasible for this to
include namespace aswell, if you don't like the default.
- in-kernel devfs stays light-weight and clean.
- all the dirty stuff - persistence, *whatever other feature you want* -
is done in userspace by devfsd.
So what's the problem?
regards,
Paul.
-
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/