Date: Tue, 27 Nov 2001 23:21:19 +0000 From: Dima Dorfman <dima@trit.org> To: Warner Losh <imp@harmony.village.org> Cc: arch@FreeBSD.ORG Subject: Re: Anybody working on devd? Message-ID: <20011127232124.2AED53EE0@bazooka.trit.org> In-Reply-To: <200111272243.fARMhbM17326@harmony.village.org>; from imp@harmony.village.org on "Tue, 27 Nov 2001 15:43:37 -0700"
next in thread | previous in thread | raw e-mail | index | archive | help
Warner Losh <imp@harmony.village.org> wrote: > 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 write > s: > : > : 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. Well then, it looks like I've done an excellent job of misunderstanding the issue. I'll go reread the usenix conference logs to see if I can figure it out. 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?20011127232124.2AED53EE0>