Date: Wed, 06 Jan 1999 19:45:36 +0100 From: Poul-Henning Kamp <phk@critter.freebsd.dk> To: freebsd-arch@FreeBSD.ORG Subject: Re: Implementing a DEVFS daemon Message-ID: <25286.915648336@critter.freebsd.dk> In-Reply-To: Your message of "Tue, 05 Jan 1999 04:56:44 PST." <199901051256.EAA65568@silvia.hip.berkeley.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?25286.915648336>