Messages in this thread | | | Date | Mon, 11 Oct 1999 14:19:56 -0400 | From | Jeff Garzik <> | Subject | devd and device events (was Re: My $0.02 on devd and devfs) |
| |
"H. Peter Anvin" wrote: > David Harris wrote: > > > Depending on the kind of daemon used, it would either be respawned or > > > the info would get queued up until it is restarted. I don't think it's > > > particularly anything to worry about, though...
> > If you re-spawn the daemon and it gets to see all of the events that have been > > stored up, it still does not have a proper view of the device configuration. > > The kernel really has to be smarter than just issuing events and buffering > > them.
> It doesn't have to -- the additional information it needs is in the file > system.
It doesn't have to, yes, but scanning the fs would be ugly and probably time consuming.
IMHO /proc/device_events should be an ASCII list of device events, like described previously in this thread. Each line in that list, though, would need a timestamp of some sort.
devd then maintains its own state, [optionally] syncing up after a restart using the timestamps to handle as-yet-unprocessed events. This allows for any amount of time to pass between kernel bootup and devd doing its work.
To continue along this train of thought: any suggestions for creating /proc/device_events? Presumeably stealing code from PCMCIA would be a good place to start.
Jeff
-- Custom driver development | Never worry about theory as long Open source programming | as the machinery does what it's | supposed to do. -- R. A. Heinlein
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |