Date: Sat, 15 Dec 2001 03:14:55 -0000 From: Paul Richards <paul@freebsd-services.com> To: Mike Smith <msmith@freebsd.org>, arch@FreeBSD.ORG Subject: Re: Anybody working on devd? Message-ID: <12520000.1008386095@lobster.originative.co.uk> In-Reply-To: <200111272301.fARN1nj04294@mass.dis.org> References: <200111272301.fARN1nj04294@mass.dis.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--On Tuesday, November 27, 2001 15:01:49 -0800 Mike Smith <msmith@freebsd.org> wrote: >> 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. I wanted to call it eventd :-) > 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 If eventd is a generic handler for all kernel events then all sorts of things can be hooked into it. What would be needed is an api call in the kernel to signal an event and then any part of the kernel would have a mechanism to cause an userland action to occur. I think focussing the design around device type events would be a big mistake in the long run. Paul Richards FreeBSD Services Ltd http://www.freebsd-services.com 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?12520000.1008386095>