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/