Messages in this thread | | | Date | Fri, 18 Jun 1999 09:59:07 +0100 | From | Paul Jakma <> | Subject | Re: UUIDs (and devfs and major/minor numbers) |
| |
> With devfsd, I have a very nice way of implementing persistence. I can > support the existing semantics, where a sysadmin goes in and manually > changes things, and I already support a more powerful scheme where > groups of device entries are "saved". > > Regards, > > Richard....
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/
| |