From owner-freebsd-usb@FreeBSD.ORG Sat Aug 23 16:01:53 2008 Return-Path: Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B00CC106564A for ; Sat, 23 Aug 2008 16:01:53 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 6BD838FC0C for ; Sat, 23 Aug 2008 16:01:53 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.2/8.14.1) with ESMTP id m7NG1N65001805; Sat, 23 Aug 2008 10:01:23 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Sat, 23 Aug 2008 10:01:55 -0600 (MDT) Message-Id: <20080823.100155.1310242209.imp@bsdimp.com> To: phk@phk.freebsd.dk From: "M. Warner Losh" In-Reply-To: <10490.1219505244@critter.freebsd.dk> References: <200808231034.54484.hselasky@c2i.net> <10490.1219505244@critter.freebsd.dk> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-usb@freebsd.org Subject: Re: usb4bsd patch review X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Aug 2008 16:01:53 -0000 In message: <10490.1219505244@critter.freebsd.dk> "Poul-Henning Kamp" 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