what about the current devfs, but without the filesystem code?
ie a central kernel devfs layer to handle accept driver registrations and
communicate with daemon.
daemon to handle updating the already existing /dev on filesystem?
Would such a solution be acceptable? It seems a decent compromise between
Richards full-blown devfs, and the minimal user-space daemon/scripting
approach favoured by others. Plus we can retain some of the existing devfs
code, and the API it has established.
regards,
Paul Jakma.
-
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/