> Oh, it's certainly more that 6 hours of work. But it *will* get done.
Even the mtrr driver was a good 8 hours to clean up, make readable and
more object-oriented. I wish you luck, as well as anyone that has to
attempt to decipher it.
> > > At that point devfs will mostly be:
> > > - an API
> > > - a way fo supporting the devfsd protocol.
> > I argue that you shouldn't need a separate daemon. We already have
> > the /sbin/hotplug interface. It's simple and sweet. We shouldn't
> > need to rely on an entirely separate daemon.
> The devfsd protocol is more lightweight. Plus it doesn't require
> fork(2)+execve(2) overheads. And more importantly, you can capture
> lookup() events.
These events are not performance critical, so the overhead is less
important. Besides, almost all systems have /sbin/hotplug, since it can be
anything - a shell script, a perl script, a tiny C executable.
The hotplug interface doesn't rely on any particular implementation. It
only relies on something on the other side implementing a particular
interface. The implementation can be replaced, as well as the format of
the policy, based on the constratints of the system or the whims of
It also doesn't rely on a process running to capture events. What happens
if the devfsd process is killed?
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to email@example.com
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue May 07 2002 - 22:00:31 EST