Date: Mon, 26 Nov 2001 15:05:44 -0800 (PST) From: Matthew Jacob <mjacob@feral.com> To: Peter Wemm <peter@wemm.org> Cc: Dima Dorfman <dima@trit.org>, arch@FreeBSD.ORG Subject: Re: Anybody working on devd? Message-ID: <Pine.BSF.4.21.0111261459170.60524-100000@beppo> In-Reply-To: <20011126212937.AD31B380D@overcee.netplex.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0111261459170.60524-100000>