[lkml]   [2004]   [May]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Load hid.o module synchronously?
    Greg KH <> 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
    ( 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

    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

    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

    - Pat
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 14:02    [W:0.022 / U:6.012 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site