Date: Sat, 09 Jan 1999 14:42:30 -0700 From: "Justin T. Gibbs" <gibbs@plutotech.com> To: freebsd-arch@FreeBSD.ORG Subject: Re: Implementing a DEVFS daemon Message-ID: <199901092150.OAA20842@pluto.plutotech.com> In-Reply-To: Your message of "Wed, 06 Jan 1999 19:45:36 %2B0100." <25286.915648336@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199901092150.OAA20842>