From owner-freebsd-arch Sat Jan 9 13:04:54 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA13778 for freebsd-arch-outgoing; Sat, 9 Jan 1999 13:04:54 -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 NAA13770 for ; Sat, 9 Jan 1999 13:04:51 -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 WAA05348 for ; Sat, 9 Jan 1999 22:04:16 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id WAA25054 for freebsd-arch@freebsd.org; Sat, 9 Jan 1999 22:04:15 +0100 (MET) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.40.131]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA19578 for ; Wed, 6 Jan 1999 10:46:06 -0800 (PST) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.9.1/8.8.5) with ESMTP id TAA25288 for ; Wed, 6 Jan 1999 19:45:36 +0100 (CET) To: freebsd-arch@FreeBSD.ORG Subject: Re: Implementing a DEVFS daemon In-reply-to: Your message of "Tue, 05 Jan 1999 04:56:44 PST." <199901051256.EAA65568@silvia.hip.berkeley.edu> Date: Wed, 06 Jan 1999 19:45:36 +0100 Message-ID: <25286.915648336@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Satoshi Asami writes: > Another hairy issue is how to keep the "easily editable ASCII" file > in a consistent state. Suppose the daemon and the editor (videvfs?) > need to lock the file before they make modifications. Now I edit > the configuration file [...] 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. 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. 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. -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message