usb4bsd patch review
M. Warner Losh
imp at bsdimp.com
Sat Aug 23 16:01:53 UTC 2008
In message: <10490.1219505244 at critter.freebsd.dk>
"Poul-Henning Kamp" <phk at phk.freebsd.dk> writes:
: In message <200808231034.54484.hselasky at c2i.net>, Hans Petter Selasky writes:
: >The problem about "devfs.rules" with regard to USB is that you don't know what
: >you are giving permissions to. A rule that gives permission to "/dev/ulpt0"
: >will give permissions to the first printer you plug into the USB system. That
: >is not neccessarily what the user wants.
: I think this might be a good time to consider the devd/devfs
: distribution of work.
: The reason devfs(8) works like "firewall rules" is that we did not want
: some mandatory daemon to set the modes, in particular on embedded
: The alternative solution is to always create device nodes "root:wheel r--"
: and let the daemon set the mode as desired.
: This model has the advantage of not needing the uid, gid and mode arguments
: to make_dev, something that has always been acknowleded as a kludge.
: The down side is that devd(8) becomes a mandatory daemon on most systems.
: Given that devfs(8) has not exactly been a stellar success and that it
: often and repeatedly bites people with it slightly pedantic semantics,
: transitioning in that direction might be a good thing.
While this may be a good idea, I'm hesitant about races that it may
introduce. This is the classic point of attack: do something between
steps of a formerly atomic operation that was made non-atomic. I
can't think of anything off the top of my head, but I'm still
More information about the freebsd-usb