From owner-freebsd-arch Mon Nov 26 15: 5:57 2001 Delivered-To: freebsd-arch@freebsd.org Received: from beppo.feral.com (beppo.feral.com [192.67.166.79]) by hub.freebsd.org (Postfix) with ESMTP id 882E237B416 for ; Mon, 26 Nov 2001 15:05:48 -0800 (PST) Received: from mailhost.feral.com (mjacob@mailhost.feral.com [192.67.166.1]) by beppo.feral.com (8.11.3/8.11.3) with ESMTP id fAQN5iW69528; Mon, 26 Nov 2001 15:05:45 -0800 (PST) (envelope-from mjacob@feral.com) Date: Mon, 26 Nov 2001 15:05:44 -0800 (PST) From: Matthew Jacob X-Sender: mjacob@beppo Reply-To: mjacob@feral.com To: Peter Wemm Cc: Dima Dorfman , arch@FreeBSD.ORG Subject: Re: Anybody working on devd? In-Reply-To: <20011126212937.AD31B380D@overcee.netplex.com.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, 26 Nov 2001, Peter Wemm wrote: > Matthew Jacob wrote: > > I'm curious what you think a devd is now needed for. > > As a common place to hook in "device related" trigger events. Currently > pccardd (on OLDCARD) performs two functions.. It drives the bus scan and > driver assignment, and secondly it runs userland programs in response to > device events (insert/remove). usbd used to do the same thing, but now > it is solely an optional userland event trigger. NEWCARD does not > have this functionality anywhere. Insert a card and a network interface > appears.. and thats it. There is no place to add (for example) a dhclient > event. > > devd would be a general purpose replacement for usbd and the trigger part > of pccardd, and provide the functionality to newcard. Yes, I see that now. I would rather imagine, though, that infrastructure that comes and goes should be only coincidental to device node creation- whole stacks of devices come and go that don't have device nodes. Still- one has to ask, "if usbd or pccard disks are driven by 'ata' or 'da', then it's up to 'ata' or 'da' to call make_dev"- and that seems like this is all that we need devfs to do. Adding hooks via devfs makes a linkage that requires a device node when in fact most of the stuff that usbd or pccard do has nothing to do with device node names. (I guess implicit in all of this is a desire to see FreeBSD avoid the obligate device tree hierarchy path (no pun intended) that Sun and other OBP machines have taken). > > It would also be a place where a program could be called to respond to new > nodes appearing in /dev for adjusting any permissions needed according > to some sort of template system or something. (But it would be a mistake > to mix the two things up at this point, as the permissions setter is prime > bikeshed material. IMHO, provide the hooks first, then once we have the > framework, then revisit the permissions). It seems to me wrong to do 'adjustments'. Either you have a model that trusts drivers to do the right thing when the call make_dev, or you don't. -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message