usb4bsd patch review

[M. Warner Losh]

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
: systems.
: 
: 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
concerned.

Warner