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