lkml.org 
[lkml]   [2002]   [May]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] 2.5.14 IDE 56

> 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
the distro.

It also doesn't rely on a process running to capture events. What happens
if the devfsd process is killed?

-pat

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:25    [W:0.106 / U:41.844 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site