From owner-freebsd-arch Sun Jan 10 16:46:19 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA07627 for freebsd-arch-outgoing; Sun, 10 Jan 1999 16:46:19 -0800 (PST) (envelope-from owner-freebsd-arch@FreeBSD.ORG) Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA07622 for ; Sun, 10 Jan 1999 16:46:16 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.1a/8.9.1) with ESMTP id BAA04178 for ; Mon, 11 Jan 1999 01:45:42 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id BAA42772 for freebsd-arch@freebsd.org; Mon, 11 Jan 1999 01:45:42 +0100 (MET) Received: from pluto.plutotech.com (mail.plutotech.com [206.168.67.137]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA20345 for ; Sat, 9 Jan 1999 13:55:11 -0800 (PST) (envelope-from gibbs@plutotech.com) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by pluto.plutotech.com (8.9.1/8.9.1) with ESMTP id OAA20842; Sat, 9 Jan 1999 14:50:37 -0700 (MST) (envelope-from gibbs@plutotech.com) Message-Id: <199901092150.OAA20842@pluto.plutotech.com> X-Mailer: exmh version 2.0.2 2/24/98 X-To: Poul-Henning Kamp To: freebsd-arch@FreeBSD.ORG Subject: Re: Implementing a DEVFS daemon In-reply-to: Your message of "Wed, 06 Jan 1999 19:45:36 +0100." <25286.915648336@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 09 Jan 1999 14:42:30 -0700 From: "Justin T. Gibbs" Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I think this can only be solved by using the classical "kill -1" > strategy for rereading config files. > > But wait! It gets worse: If devd uses a plain chown(2) to apply the > policy, > [Upcall version:] devfs will notice that somebody changed a device > owner and inform devd which will need to realize that this > modification was one it did itself. > [devd poll version:] devd will encounter the changed modes on the next > scan and have to figure out that the change was not one done "by > hand", but merely its own application of the policy. The notification causes a comparison between currently visible policy and stored policy. If the policies match, there is nothing to do. I don't see this as much of a special case. > JMB said: >> The timing issues seem to be ugly to me. It would be nice if >> shutdown forced this daemon to roam over the /devfs tree. It almost >> sounds like we need upcalls from the kernel to the daemon -- at >> which point I wonder why the daemon is not in the kernel. I still >> have to read 99% of the kernel, so if this is wacky tell me and I'll >> shut up. This problem isn't too hard to solve. Devd re-mounts all devfs instances R/O, takes a last snapshot, then exits. > Upcalls will be needed if we decide to tackle PnP/USB and so on, > but belive me, it is still at lot less ugly than to implement the > devd in the kernel. You wouldn't need upcalls if all PnP/USB devices instantiated DEVFS nodes upon arrival/departure events. Then the only thing you need is a way to notice changes in a directory which should be possible to do with an enhanced poll(2). If you don't like this, you could also trigger events off of the modification time of '/dev/PnP' or '/dev/USB' that caused reconfiguration of those types of devices, but this seems less elegant than the file per device paradigm. -- Justin [In a followup series of short mails, phk+gibbs notes that we also may need to be able to modify configuration of the system depending on what is available at just that time - e.g, use DHCP when pccard is available, and that this may need notifications. -EE] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message