In message: <[EMAIL PROTECTED]>
"Poul-Henning Kamp" <[EMAIL PROTECTED]> writes:
: In message <[EMAIL PROTECTED]>, 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
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
