From owner-freebsd-arch Fri Dec 14 19:15: 2 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mailgate.originative.co.uk (mailgate.originative.co.uk [62.232.68.68]) by hub.freebsd.org (Postfix) with ESMTP id 0822737B416; Fri, 14 Dec 2001 19:14:58 -0800 (PST) Received: from lobster.originative.co.uk (lobster [62.232.68.81]) by mailgate.originative.co.uk (Postfix) with ESMTP id 7D1011D169; Sat, 15 Dec 2001 03:14:55 +0000 (GMT) Date: Sat, 15 Dec 2001 03:14:55 -0000 From: Paul Richards To: Mike Smith , 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> X-Mailer: Mulberry/2.1.1 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --On Tuesday, November 27, 2001 15:01:49 -0800 Mike Smith 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