lkml.org 
[lkml]   [1999]   [Sep]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRE: [Q]: Linux and real device drivers
    Date
    > > I don't say they have to be shipped seperately, but if they 
    > are separated,
    > > they can be handled like normal high-priority tasks, swapped out if
    >
    > They can't because they need to handle interrupts and get
    > high performance

    Actually, drivers should be structured as high priority tasks, at least from
    the scheduling point of view. The interrupt handler itself should only do
    enough to stop the card from interrupting and then pass control to a
    software handler.

    Excessive interrupt latency can have a bad effect on kernel performance, and
    so can priority inversions. Provided that no characters are lost, are you
    sure you want that serial interrupt to prevent your SCSI manager from
    running?

    Most real time systems already do this sort of stuff, but only from the
    schedulers point of view. Although it would be possible to implement memory
    protection as well, I am not familiar with any systems that implement memory
    protection on device drivers.

    > > unused, delivered by manufacturers seperately of the kernel
    > and kernel
    > > version independent (more or less at least). Besides, by treating
    >
    > Unlikely. They would stil be very tied to the kernel.

    Tied to the kernel is a lot different than requiring a recompile for every
    kernel patch. It is possible (as in most manufacturers do it) to have a
    kernel interface to handle the normal functions required of a device driver.

    Putting in a patch on Solaris doesn't require that you then go out and
    recompile every device driver on the system. Same goes for HP-UX or AIX.

    > > drivers as tasks, it is sometimes possible to keep a system
    > alive if a
    > > driver crashes. (Though a real crash is still a real crash...),
    >
    > If a driver crashes it doesnt really matter what state it was
    > in unless
    > you start auditing every I/O access via some kind of I/O
    > manager. In which
    > case it'll take you a week or two to finish booting

    I agree that the idea of recovering from a driver crash is probably more
    than you want to attempt. The type of error would largely determine if the
    system even could recover.

    That doesn't mean that there is no reason to provide an opaque and stable
    interface between the device driver and the operating system.

    -Bret

    -------------------------------------------------------------
    SBS Technologies, Connectivity Products
    ... solutions for real-time connectivity

    Bret Indrelee, Engineer
    SBS Technologies, Inc., Connectivity Products
    1284 Corporate Center Drive, St. Paul MN 55121
    Direct: (651) 905-4731
    Main: (651) 905-4700 Fax: (651) 905-4701
    E-mail: bindrelee@sbs-cp.com http://www.sbs.com
    -------------------------------------------------------------

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

    \
     
     \ /
      Last update: 2005-03-22 13:54    [W:0.030 / U:91.980 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site