Date: Sat, 23 Aug 2008 10:01:55 -0600 (MDT) From: "M. Warner Losh" <imp@bsdimp.com> To: phk@phk.freebsd.dk Cc: freebsd-usb@freebsd.org Subject: Re: usb4bsd patch review Message-ID: <20080823.100155.1310242209.imp@bsdimp.com> In-Reply-To: <10490.1219505244@critter.freebsd.dk> References: <200808231034.54484.hselasky@c2i.net> <10490.1219505244@critter.freebsd.dk>
index | next in thread | previous in thread | raw e-mail
In message: <10490.1219505244@critter.freebsd.dk>
"Poul-Henning Kamp" <phk@phk.freebsd.dk> writes:
: In message <200808231034.54484.hselasky@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
home |
help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080823.100155.1310242209.imp>