[lkml]   [2004]   [Jan]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: timing code in 2.6.1
    On Fri, 16 Jan 2004, Andrew Morton wrote:

    > "Richard B. Johnson" <> wrote:
    > >
    > >
    > > Some drivers are being re-written for 2.6++. The following
    > > construct seems to work for "waiting for an event" in
    > > the kernel modules.
    > >
    > > // No locks are being held
    > > tim = jiffies + EVENT_TIMEOUT;
    > > while(!event() && time_before(jiffies, tim))
    > > schedule_timeout(0);
    > >
    > > Is there anything wrong?
    > This is not a good thing to be doing. You should add this task to a
    > waitqueue and then sleep. Make the code which causes event() to come true
    > deliver a wake_up to that waitqueue. There are many examples of this in
    > the kernel.

    Huh? The code that causes "event()" needs to get the CPU occasionally
    to check for the event. The hardware doesn't produce an interrupt
    upon that event.

    > If the hardware only supports polling then gee, you'd be best off spinning
    > for a few microseconds then fall into a schedule_timeout(1) polling loop.
    > Or something like that. Or make the hardware designer write the damn
    > driver.

    The poll will almost never be true when first called. Spinning and
    wasting CPU cycles that can be used by another task isn't a good

    The hardware designer has designed the hardware according to
    the requirements dictated by a government agency (the FDA).
    There was no requirement to make interface code simple. The
    interface code must check for multiple failure modes during
    every specific operation. Both the hardware and software
    check for these modes so that no single failure can cause
    injury to a patient. This is SOP for medical equipment.

    In the specific case, we operate a patient table. The operator
    presses an UP and DOWN button. These will produce interrupts.

    When an UP button is hit, thousands of interrupts are generated.
    This is because it is a mechanical operation. The same is true
    for the DOWN button. These events are filtered to determine
    the true intervals for "UP", "NOTHING", and "DOWN". When the
    "UP" button is pressed, the CPU servos position information
    from another driver and motor speed to to move the table to
    the commanded position. If the button is pressed for a short
    period of time, the table moves slowly. If it is pressed for
    a longer period, it moves quickly. It must accellerate according
    to a schedule and decellerate according to a schedule so that
    patients that weigh 350 lbs and patients that weigh 45 lbs are
    accellerated and decellerated at the same rate.

    When the table is being moved, 12 different parameters are
    monitored. At least two parameters are actually calculated
    and filtered to predict where the patient will be if the
    button is released.

    So, this cannot be dismissed as "get the hardware designer
    to write the same driver..."

    Writing software often requires knowing about the whole sustem.

    Dick Johnson
    Penguin : Linux version 2.4.24 on an i686 machine (797.90 BogoMips).
    Note 96.31% of all statistics are fiction.

    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:00    [W:0.029 / U:38.232 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site