Load hid.o module synchronously?

Load hid.o module synchronously?

[Patrick J. LoPresti]

I am using the 2.6.5 kernel on a modular boot disk.  I am finding that
invocations of "modprobe" are returning sooner than I would like.

For example, I invoke "modprobe hid" to make my USB keyboard work.
This loads the module and exits immediately, causing my script to
proceed, before the USB keyboard is probed and ready.

I want to wait until the driver is finished initializing (i.e., a USB
keyboard is either found or not found) before my script continues.
How can I do that?

I seem to be having similar problems loading certain other modules
(PCMCIA, Ethernet), but hid.o is the only one for which I have not
found a convenient workaround.

I apologize if this is a stupid question.  I have spent some time
searching both the Linux source code and the linux-kernel archives to
no avail.

Thanks!

 - Pat

Re: Load hid.o module synchronously?

[Chris Friesen]

Patrick J. LoPresti wrote:

> For example, I invoke "modprobe hid" to make my USB keyboard work.
> This loads the module and exits immediately, causing my script to
> proceed, before the USB keyboard is probed and ready.
> 
> I want to wait until the driver is finished initializing (i.e., a USB
> keyboard is either found or not found) before my script continues.
> How can I do that?

How about scanning the usb device tree to see if the keyboard is present and properly detected?

Chris

Re: Load hid.o module synchronously?

[Patrick J. LoPresti]

Chris Friesen <cfriesen@nortelnetworks.com> writes:

> Patrick J. LoPresti wrote:
> 
> > For example, I invoke "modprobe hid" to make my USB keyboard work.
> > This loads the module and exits immediately, causing my script to
> > proceed, before the USB keyboard is probed and ready.
> > I want to wait until the driver is finished initializing (i.e., a USB
> > keyboard is either found or not found) before my script continues.
> > How can I do that?
> 
> How about scanning the usb device tree to see if the keyboard is
> present and properly detected?

You mean under sysfs or usbfs?  Or both?

I see how I can scan for a USB keyboard after loading the USB host
controller module.  I think.  But what do I look for, exactly, to tell
when hid.o has hooked itself up to the keyboard?

 - Pat

Re: Load hid.o module synchronously?

[Chris Friesen]

Patrick J. LoPresti wrote:

> You mean under sysfs or usbfs?  Or both?

Somewhere in there...

> I see how I can scan for a USB keyboard after loading the USB host
> controller module.  I think.  But what do I look for, exactly, to tell
> when hid.o has hooked itself up to the keyboard?

I don't know exactly what you'd look for.  Greg K-H would be the guy to ask, I think.

Chris

Re: Load hid.o module synchronously?

[Greg KH]

On Mon, Apr 26, 2004 at 03:50:52PM -0400, Patrick J. LoPresti wrote:
> 
> I see how I can scan for a USB keyboard after loading the USB host
> controller module.  I think.  But what do I look for, exactly, to tell
> when hid.o has hooked itself up to the keyboard?

I can think of at least 2 different ways (there are probably more):
	- look at the device in /proc/bus/usb/devices and wait until the
	  driver is bound to that device "(hid)" will show up as the
	  driver bound to that interface
	- look at the sysfs directory for the hid driver and wait for
	  the symlink to the device shows up.  This should be at
	  /sys/bus/usb/drivers/hid

Hope this helps,

greg k-h

Re: Load hid.o module synchronously?

[Kim Holviala]

On Monday 26 April 2004 22:10, Patrick J. LoPresti wrote:

> For example, I invoke "modprobe hid" to make my USB keyboard work.
> This loads the module and exits immediately, causing my script to
> proceed, before the USB keyboard is probed and ready.
>
> I want to wait until the driver is finished initializing (i.e., a USB
> keyboard is either found or not found) before my script continues.
> How can I do that?
>
> I seem to be having similar problems loading certain other modules
> (PCMCIA, Ethernet), but hid.o is the only one for which I have not
> found a convenient workaround.

Well, this isn't what you wanted to hear :-) but I use sleep on my 
PCMCIA/nfsroot boot initrds. Sleeping for 3-5 seconds is enough for the 
modules to load properly and it won't slow down the boot too much either...




Kim

Re: Load hid.o module synchronously?

[Bill Davidsen]

Patrick J. LoPresti wrote:
> Chris Friesen <cfriesen@nortelnetworks.com> writes:
> 
> 
>>Patrick J. LoPresti wrote:
>>
>>
>>>For example, I invoke "modprobe hid" to make my USB keyboard work.
>>>This loads the module and exits immediately, causing my script to
>>>proceed, before the USB keyboard is probed and ready.
>>>I want to wait until the driver is finished initializing (i.e., a USB
>>>keyboard is either found or not found) before my script continues.
>>>How can I do that?
>>
>>How about scanning the usb device tree to see if the keyboard is
>>present and properly detected?
> 
> 
> You mean under sysfs or usbfs?  Or both?
> 
> I see how I can scan for a USB keyboard after loading the USB host
> controller module.  I think.  But what do I look for, exactly, to tell
> when hid.o has hooked itself up to the keyboard?

You need to be able to tell "not hooked yet" from "never saw it" for 
reliable operation. I don't know how to do that, sorry.

-- 
    -bill davidsen (davidsen@tmr.com)
"The secret to procrastination is to put things off until the
  last possible moment - but no longer"  -me

Re: Load hid.o module synchronously?

[Patrick J. LoPresti]

Bill Davidsen <davidsen@tmr.com> writes:

> Patrick J. LoPresti wrote:
>
> > I see how I can scan for a USB keyboard after loading the USB host
> > controller module.  I think.  But what do I look for, exactly, to
> > tell when hid.o has hooked itself up to the keyboard?
> 
> You need to be able to tell "not hooked yet" from "never saw it" for
> reliable operation. I don't know how to do that, sorry.

So there is no way to load this hardware driver and wait until it
either binds or fails to bind to its associated hardware?  That seems
like a bad bug in the design...

I suppose I will just use some arbitrary delay.

 - Pat

Re: Load hid.o module synchronously?

[Kevin P. Fleming]

Patrick J. LoPresti wrote:

> So there is no way to load this hardware driver and wait until it
> either binds or fails to bind to its associated hardware?  That seems
> like a bad bug in the design...

You are wanting to load a driver for a completely-hotplug-capable 
subsystem but treat as if it was not? What will your package do if the 
user does not have the keyboard plugged in when the module gets loaded?

IMHO you should use the hotplug infrastructure and do this properly; 
load the module, and then sleep/wait until you get a hotplug event 
telling you that a keyboard has been found.

Re: Load hid.o module synchronously?

[Greg KH]

On Sat, May 01, 2004 at 09:21:31AM -0400, Patrick J. LoPresti wrote:
> Bill Davidsen <davidsen@tmr.com> writes:
> 
> > Patrick J. LoPresti wrote:
> >
> > > I see how I can scan for a USB keyboard after loading the USB host
> > > controller module.  I think.  But what do I look for, exactly, to
> > > tell when hid.o has hooked itself up to the keyboard?
> > 
> > You need to be able to tell "not hooked yet" from "never saw it" for
> > reliable operation. I don't know how to do that, sorry.
> 
> So there is no way to load this hardware driver and wait until it
> either binds or fails to bind to its associated hardware?  That seems
> like a bad bug in the design...

Um, what is wrong with the proposals I made for how you can detect this?

greg k-h

Re: Re: Load hid.o module synchronously?

[Patrick J. LoPresti]

Greg KH <greg@kroah.com> writes:

> On Sat, May 01, 2004 at 09:21:31AM -0400, Patrick J. LoPresti wrote:
>
> > So there is no way to load this hardware driver and wait until it
> > either binds or fails to bind to its associated hardware?  That seems
> > like a bad bug in the design...
> 
> Um, what is wrong with the proposals I made for how you can detect
> this?

Your proposals were:

 - look at the device in /proc/bus/usb/devices and wait until the
   driver is bound to that device "(hid)" will show up as the
   driver bound to that interface

 - look at the sysfs directory for the hid driver and wait for
   the symlink to the device shows up.  This should be at
   /sys/bus/usb/drivers/hid

I see how these let me wait until the hid.o module successfully binds
to the hardware.

But what if it fails to bind?  For example, what if an error occurs?
Or what if the keyboard is on the module's blacklist?  How do I know
when to stop waiting?

Ideally, what I would like is for "modprobe <driver>" to wait until
all hardware handled by that driver is either ready for use or is
never going to be.  That seems simple and natural to me.  But I would
be glad to use any other mechanism to achieve the same effect; I just
have not seen one yet.

 - Pat

Re: Re: Load hid.o module synchronously?

[Greg KH]

On Tue, May 04, 2004 at 05:56:48PM -0400, Patrick J. LoPresti wrote:
> Greg KH <greg@kroah.com> writes:
> 
> > On Sat, May 01, 2004 at 09:21:31AM -0400, Patrick J. LoPresti wrote:
> >
> > > So there is no way to load this hardware driver and wait until it
> > > either binds or fails to bind to its associated hardware?  That seems
> > > like a bad bug in the design...
> > 
> > Um, what is wrong with the proposals I made for how you can detect
> > this?
> 
> Your proposals were:
> 
>  - look at the device in /proc/bus/usb/devices and wait until the
>    driver is bound to that device "(hid)" will show up as the
>    driver bound to that interface
> 
>  - look at the sysfs directory for the hid driver and wait for
>    the symlink to the device shows up.  This should be at
>    /sys/bus/usb/drivers/hid
> 
> I see how these let me wait until the hid.o module successfully binds
> to the hardware.
> 
> But what if it fails to bind?  For example, what if an error occurs?
> Or what if the keyboard is on the module's blacklist?  How do I know
> when to stop waiting?

You do not, sorry.

> Ideally, what I would like is for "modprobe <driver>" to wait until
> all hardware handled by that driver is either ready for use or is
> never going to be.  That seems simple and natural to me.

Sorry, but this is not going to happen.  It does not fit into the way
the kernel handles drivers anymore.  Again, sorry.

greg k-h

Re: Load hid.o module synchronously?

[Patrick J. LoPresti]

Greg KH <greg@kroah.com> writes:

> On Tue, May 04, 2004 at 05:56:48PM -0400, Patrick J. LoPresti wrote:
>
> > But what if it fails to bind?  For example, what if an error occurs?
> > Or what if the keyboard is on the module's blacklist?  How do I know
> > when to stop waiting?
> 
> You do not, sorry.

That is disappointing.  I mean, I deal with Microsoft products a lot,
where "unreliable by design" is normal.  But I expected better from
Linux.

> > Ideally, what I would like is for "modprobe <driver>" to wait
> > until all hardware handled by that driver is either ready for use
> > or is never going to be.  That seems simple and natural to me.
> 
> Sorry, but this is not going to happen.  It does not fit into the
> way the kernel handles drivers anymore.  Again, sorry.

OK, an arbitrary flaky delay it is.  Thanks!

 - Pat

Re: Load hid.o module synchronously?

[Greg KH]

On Tue, May 04, 2004 at 10:49:56PM -0400, Patrick J. LoPresti wrote:
> Greg KH <greg@kroah.com> writes:
> 
> > On Tue, May 04, 2004 at 05:56:48PM -0400, Patrick J. LoPresti wrote:
> >
> > > But what if it fails to bind?  For example, what if an error occurs?
> > > Or what if the keyboard is on the module's blacklist?  How do I know
> > > when to stop waiting?
> > 
> > You do not, sorry.
> 
> That is disappointing.  I mean, I deal with Microsoft products a lot,
> where "unreliable by design" is normal.  But I expected better from
> Linux.

That is such an obvious troll and flame bait, I really do not know why I
am responding.  Please, try to be civil here.  The point of Linux isis,
if you don't like the way things are today, you can change them.  Try
that with Microsoft products (for that manner, please show me how you
can do what you are trying to do on Windows 2000, driver stuff there is
_so_ much more complex...)

But before you try to do that (which basically is moving things back to
the way things used to be years ago in 2.2), why don't you try to state
the problem you are having.  Perhaps it can be solved in a different
manner than what you are trying to do.

So, what are you trying to fix/solve/monitor/do here?

thanks,

greg k-h

Re: Load hid.o module synchronously?

[Randy.Dunlap]

On 04 May 2004 22:49:56 -0400 "Patrick J. LoPresti" <patl@users.sourceforge.net> wrote:

| Greg KH <greg@kroah.com> writes:
| 
| > On Tue, May 04, 2004 at 05:56:48PM -0400, Patrick J. LoPresti wrote:
| >
| > > But what if it fails to bind?  For example, what if an error occurs?
| > > Or what if the keyboard is on the module's blacklist?  How do I know
| > > when to stop waiting?
| > 
| > You do not, sorry.
| 
| That is disappointing.  I mean, I deal with Microsoft products a lot,
| where "unreliable by design" is normal.  But I expected better from
| Linux.

It's just a different model than what you are looking for.

The hid (or whatever) driver supports a hotplug environment.
It cannot know what device(s) are expected to be present
or just which ones you are looking for.

If it's a huge problem, you have the source code, modify the
driver to do what you want it to do.

| > > Ideally, what I would like is for "modprobe <driver>" to wait
| > > until all hardware handled by that driver is either ready for use
| > > or is never going to be.  That seems simple and natural to me.
| > 
| > Sorry, but this is not going to happen.  It does not fit into the
| > way the kernel handles drivers anymore.  Again, sorry.
| 
| OK, an arbitrary flaky delay it is.  Thanks!


--
~Randy

Re: Load hid.o module synchronously?

[Patrick J. LoPresti]

Greg KH <greg@kroah.com> writes:

> That is such an obvious troll and flame bait, I really do not know
> why I am responding.  Please, try to be civil here.

I was out of line, and I apologize.

I do not mean to be uncivil.  I do think this is a design flaw in
Linux, but I do not intend any personal attack.

> But before you try to do that (which basically is moving things back
> to the way things used to be years ago in 2.2), why don't you try to
> state the problem you are having.  Perhaps it can be solved in a
> different manner than what you are trying to do.

What I want is to load a driver and not proceed until it has finished
loading, which I am told "does not fit into the way the kernel handles
drivers anymore".  This strikes me as a clear misdesign.

> So, what are you trying to fix/solve/monitor/do here?

I have a custom Linux boot disk for my project
(http://unattended.sourceforge.net/).  I want it to work unaltered on
as many different systems as possible.  The boot disk can be
interactive or non-interactive, depending on how the system is
configured.  Early on, it issues a prompt "Override boot disk
defaults?", which defaults to "no" after a ten-second timeout.

So, first, I want to load the driver for the keyboard, if any.  I want
to wait until the keyboard is ready before I emit any prompts.  Under
no circumstances do I want to wait forever.

This is just one example.  I have now had essentially the same problem
three different times:

  1) Loading hid.o to talk to the keyboard, as described.

  2) Running cardmgr to probe for PCMCIA devices.  Unless I delay a
     few seconds, sometimes cardmgr finds zero PCMCIA sockets,
     presumably because the yenta_socket.o driver takes a while to get
     ready.  I say "sometimes" because this behavior, and the delay
     required, varies from system to system and from boot to boot.

  3) When I load the network driver, I want to wait until it is ready
     to use.  Otherwise, when I try to obtain a DHCP lease, sometimes
     it fails.

Right now, I deal with (2) by sleeping for a bit before running
cardmgr.  I have increased my sleep time in response to bug reports
from my users.  (Obviously, I want the delay to be as short as
possible.)

I deal with (3) by re-trying DHCP for fifteen seconds or so.  I can
tell when it failed to get a lease, but I cannot easily tell why it
failed.  So I just retry for a while before moving on to the next
interface.

In all of these cases, I am hacking around an apparent design flaw in
the kernel's device loading architecture.  Obviously, random delays
are inherently unreliable; hence my comment about "unreliable by
design".

 - Pat

Re: Load hid.o module synchronously?

[Oliver Neukum]

Am Dienstag, 4. Mai 2004 23:56 schrieb Patrick J. LoPresti:
> Ideally, what I would like is for "modprobe <driver>" to wait until
> all hardware handled by that driver is either ready for use or is
> never going to be.  That seems simple and natural to me.  But I would

The set of devices connected to the machine is not static. Waiting until
all hardware is ready is very hard to even define.

> be glad to use any other mechanism to achieve the same effect; I just
> have not seen one yet.

Issue ioctl() USBDEVFS_CONNECT through usbfs. It does a synchronous
probe for a specific device.

	Regards
		Oliver

Re: Load hid.o module synchronously?

[Greg KH]

On Wed, May 05, 2004 at 11:19:56AM -0400, Patrick J. LoPresti wrote:
> What I want is to load a driver and not proceed until it has finished
> loading, which I am told "does not fit into the way the kernel handles
> drivers anymore".  This strikes me as a clear misdesign.

No, it is designed this way on purpose.  Think about devices that can be
added or removed at any point in time.  Failing a module load if a
device isn't present at this point in time is not good if the device is
plugged in a while later.

It also would not allow you to bind a driver to a device while the
kernel is running that the driver doesn't originally know about.  See
the pci sysfs file "new_id" for how you can do this today.  If we didn't
allow the driver to load that would not be possible at all.

> > So, what are you trying to fix/solve/monitor/do here?
> 
> I have a custom Linux boot disk for my project
> (http://unattended.sourceforge.net/).  I want it to work unaltered on
> as many different systems as possible.  The boot disk can be
> interactive or non-interactive, depending on how the system is
> configured.  Early on, it issues a prompt "Override boot disk
> defaults?", which defaults to "no" after a ten-second timeout.
> 
> So, first, I want to load the driver for the keyboard, if any.  I want
> to wait until the keyboard is ready before I emit any prompts.  Under
> no circumstances do I want to wait forever.
> 
> This is just one example.  I have now had essentially the same problem
> three different times:
> 
>   1) Loading hid.o to talk to the keyboard, as described.

Why not just build this in the kernel?  Once the driver is bound to the
device, the user can eventually press a key.  Perhaps make your timeout
longer (1 minute)?

>   3) When I load the network driver, I want to wait until it is ready
>      to use.  Otherwise, when I try to obtain a DHCP lease, sometimes
>      it fails.

Run your dhcp connect script after the device is bound to the driver
through the hotplug interface (the default hotplug scripts do this
today.)  No waiting, no guessing, no additional scripting, it just works
exactly when the device is ready for it to work.

> In all of these cases, I am hacking around an apparent design flaw in
> the kernel's device loading architecture.  Obviously, random delays
> are inherently unreliable; hence my comment about "unreliable by
> design".

Sorry, but your situation is very unusual, and based on my suggestions,
I don't think it is needed.

But hey, you have the source, if you don't like it, feel free to change
the code :)

thanks,

greg k-h

Re: Load hid.o module synchronously?

[Patrick J. LoPresti]

Greg KH <greg@kroah.com> writes:

> No, it is designed this way on purpose.  Think about devices that
> can be added or removed at any point in time.  Failing a module load
> if a device isn't present at this point in time is not good if the
> device is plugged in a while later.

I am starting to see the benefits of the design.  But I do not think
that it properly addresses every common usage scenario, yet.

> It also would not allow you to bind a driver to a device while the
> kernel is running that the driver doesn't originally know about.
> See the pci sysfs file "new_id" for how you can do this today.  If
> we didn't allow the driver to load that would not be possible at
> all.

I am not suggesting preventing the module from loading.  I am
suggesting that "cold plugging" is a little different from hot
plugging, and that it would be nice to be able to tell when a module
fails to bind to any hardware at initial load.

> >   1) Loading hid.o to talk to the keyboard, as described.
> 
> Why not just build this in the kernel?

No particular reason beyond general principles.  I ultimately plan to
load hid.o only when a USB keyboard is actually present.

> Once the driver is bound to the device, the user can eventually
> press a key.  Perhaps make your timeout longer (1 minute)?

Aside from being theoretically inelegant and unreliable (strictly
speaking, no finite time bound is ever guaranteed to work), it just
feels wrong to make someone wait 1 minute when "the system" should
usually only need a few seconds to tell whether a keyboard is
available.

> >   3) When I load the network driver, I want to wait until it is ready
> >      to use.  Otherwise, when I try to obtain a DHCP lease, sometimes
> >      it fails.
> 
> Run your dhcp connect script after the device is bound to the driver
> through the hotplug interface (the default hotplug scripts do this
> today.)  No waiting, no guessing, no additional scripting, it just works
> exactly when the device is ready for it to work.

OK, I admit that is nice.

However...  It really just pushes the problem back a step.  Once the
network is running, I want to invoke "smbmount".  That is, I want to
*wait* for the DHCP lease to be acquired and then do something else.

I could continue with the event-driven model and have the acquisition
of the lease trigger the mount.  But what if that first event ("device
bound") never comes?  If no network hardware is initially found, I
just want to print a sane diagnostic and halt.  Which brings me back
to using some arbitrary timeout.

> Sorry, but your situation is very unusual, and based on my
> suggestions, I don't think it is needed.

Is it really that unusual?  I thought it happened every time any Linux
system booted.

On my desktop, for instance, a bunch of init.d scripts run in a
certain order and print things like:

    starting network  [OK]
    setting time      [OK]
    etc.

That "setting time" step is not supposed to begin until the "starting
network" step finishes.  And by finishes, I mean succeeds *or fails*.
How does a normal distribution avoid blocking forever when starting
the network, or loading the keyboard driver?  I suspect they use an
arbitrary timeout, which is just fundamentally unreliable.

Sure, there are arbitrary timeouts when fetching a DHCP lease.  But
those are inherent to the network.  Using an arbitrary timeout for
something which should be 100% certain (like "is there a keyboard?")
is poor design.

> But hey, you have the source, if you don't like it, feel free to
> change the code :)

Maintaining my own kernel fork would be even more expensive than
arbitrary timeouts :-).

However, if you agree that this is a problem worth solving, I am
interested in working on patches until you find them acceptable.

Fundamentally, here is what I am thinking.  (I have not yet tried to
understand the source code, so please forgive me if this is way
off-base.)  I presume that when a device driver is loaded, there is a
loop somewhere which offers hardware to the driver.  Each time the
driver binds to a piece of hardware, a hotplug event is generated (?).

All we need is a synthetic event which is generated when NO "device
bound" events are triggered by that loop.  Because really the only
problem, in the cold plugging case, is detecting when the device
driver *fails* to bind to anything.

So I guess I have two questions:

  1) Would you be willing to consider patches which address this
     issue?  Or do you just consider it irrelevant?

  2) As I said, I have not dived into the source code yet.  Any
     suggestions for where to start?

 - Pat

Re: Load hid.o module synchronously?

[Patrick J. LoPresti]

Oliver Neukum <oliver@neukum.org> writes:

> The set of devices connected to the machine is not static. Waiting
> until all hardware is ready is very hard to even define.

It is very easy to define for 99.999% of all keyboards, which start
off connected and stay connected.

This should be simple.  I want to load a driver at boot time and wait
until it either binds to something or fails to do so.  If the user is
adding or removing hardware while the module is loading, I simply do
not care what the system does.  But if the hardware is not changing, I
care a great deal...  And the latter case is perfectly well-defined.

> > be glad to use any other mechanism to achieve the same effect; I just
> > have not seen one yet.
> 
> Issue ioctl() USBDEVFS_CONNECT through usbfs. It does a synchronous
> probe for a specific device.

I suppose this would solve my USB keyboard problem.  But a) it seems
very complex for such a simple need; and b) it does not work for
non-USB devices, which are also causing me grief.

 - Pat

Re: Load hid.o module synchronously?

[Stefan Smietanowski]

Hi Patrick.

>>The set of devices connected to the machine is not static. Waiting
>>until all hardware is ready is very hard to even define.
> 
> It is very easy to define for 99.999% of all keyboards, which start
> off connected and stay connected.
> 
> This should be simple.  I want to load a driver at boot time and wait
> until it either binds to something or fails to do so.  If the user is

But that means that the driver must include some sort of arbitrary
timelimit. Why push that from userspace to the driver?

// Stefan

Re: Load hid.o module synchronously?

[Oliver Neukum]

Am Freitag, 7. Mai 2004 18:19 schrieb Stefan Smietanowski:
> Hi Patrick.
> 
> >>The set of devices connected to the machine is not static. Waiting
> >>until all hardware is ready is very hard to even define.
> > 
> > It is very easy to define for 99.999% of all keyboards, which start
> > off connected and stay connected.
> > 
> > This should be simple.  I want to load a driver at boot time and wait
> > until it either binds to something or fails to do so.  If the user is
> 
> But that means that the driver must include some sort of arbitrary
> timelimit. Why push that from userspace to the driver?

No, upon module load the device tree could be locked and the module
insertion could wait for all matching devices in the tree to be probed.
It definitely can be done and that solution cannot be achieved from
userspace because exporting such locks would be a disaster.

However, it is probably not wise to provide for this special case.
It would probably be best to provide a generic probe method for
devices, which could run synchronously.

	Regards
		Oliver

Re: Load hid.o module synchronously?

[Greg KH]

On Thu, May 06, 2004 at 09:54:04AM -0400, Patrick J. LoPresti wrote:
> So I guess I have two questions:
> 
>   1) Would you be willing to consider patches which address this
>      issue?  Or do you just consider it irrelevant?

I do consider it irrelevant, but let's see the patches anyway.  I can
usually be persuaded to change my mind with a good, clean,
implementation...

>   2) As I said, I have not dived into the source code yet.  Any
>      suggestions for where to start?

drivers/base/*

Good luck...

greg k-h