Date: Tue, 27 Nov 2001 15:01:49 -0800 From: Mike Smith <msmith@freebsd.org> To: arch@FreeBSD.ORG Subject: Re: Anybody working on devd? Message-ID: <200111272301.fARN1nj04294@mass.dis.org> In-Reply-To: Message from Warner Losh <imp@harmony.village.org> of "Tue, 27 Nov 2001 15:45:20 MST." <200111272245.fARMjKM17357@harmony.village.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> I'd also point out that devfsd, in my world view, dealt with dev_t, > while devd dealt with device_t. I think the problem here is that the line is being drawn in the wrong place. Yes, there are a group of different things which need to be considered; responses to new devices, new device nodes, new media, etc. However, all of these group under the single heading of "dynamic changes in system configuration". And it would be highly desirable to group the policies that react to these changes in a single place, and manage them with a single tool. The alternative is a confusing mess. So, yes, we want a generic event-responsive architecture. And yes, we need to be able to script the responses to these events accordingly. And whether we call this facility "devd" or "devfsd" or "theamazingmancinid" is IMO immaterial. There are a couple of well-understood sets of event-response sets already: - new dev_t - new device_t - new media / media ejection request and probably several more that I've left out. Let's quite the squabbling over what the damn application is going to be called and get on with implementing something do to the work, ok? 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?200111272301.fARN1nj04294>