Date: Tue, 27 Nov 2001 15:43:37 -0700 From: Warner Losh <imp@harmony.village.org> To: Dima Dorfman <dima@trit.org> Cc: arch@FreeBSD.ORG Subject: Re: Anybody working on devd? Message-ID: <200111272243.fARMhbM17326@harmony.village.org> In-Reply-To: Your message of "Tue, 27 Nov 2001 22:38:49 GMT." <20011127223854.78E853EF3@bazooka.trit.org> References: <20011127223854.78E853EF3@bazooka.trit.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <20011127223854.78E853EF3@bazooka.trit.org> Dima Dorfman writes: : Warner Losh <imp@harmony.village.org> wrote: : > In message <20011126171018.F39FD3EDE@bazooka.trit.org> Dima Dorfman writes: : > : Is anybody working, or planning on starting in the near future, on : > : devd or similar? I'm thinking of giving it a shot, but I'd rather not : > : duplicate effort and/or step on anybody's toes. : > : > Which part of devd? "The do commands when devices are added to the : > configured device tree," or "the preserve permissions in /dev" one :-) : : I was talking about the former. What I have in mind is a generic : "something has happened to this device, would the userland like to do : anything in response?" kind of thing. Basically, we can have a : notify_userland() API in the kernel which takes a dev_t and an event : type, which gets filtered down to a devd userland daemon, which can : take the appropriate action (this can either be executing an external : program, or, in the case of something more complex and integrated like : pccard, a builtin function). But pccard doesn't deal in terms of dev_t, but rather device_t. The pccard bus system has no earthly clue what you just added to the system. Plus, unless jlemon has been busy, the network drivers do not add dev_t's. : The advantages of this approach is that it's very simple, doesn't : strictly depend on devfs, can probably be used to replace pccardd and : usbd (although I haven't looked at the latter much), and if we stick a : call to the hypothetical notify_userland() function in make_dev(), it : can somewhat be used to control permissions in /dev, although not : satisfactorily. I dislike this approach because it depends on dev_t rather than device_t. And there's no way to notify userland that "The bus says the plug and play info is XYZ, but no driver attached." so that the daemon can load the right driver. Warner 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?200111272243.fARMhbM17326>