Messages in this thread | | | Subject | Re: [Q]: Linux and real device drivers | Date | Tue, 21 Sep 1999 22:58:06 +0100 (BST) | From | Alan Cox <> |
| |
> 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.
There are very good reasons for not doing this in a typical real world OS environment. If I take an interrupt and schedule a task, then the following sequence occurs
irq copy data clear irq end of irq
<-- Things pass --> at some point schedule task run stuff
which means you are blowing the live data out of cache. You can't do this with a PC class machine and high speed networking. You want to take the irq and do everything you can in a short time frame while the data is live in registers and L1.
> Excessive interrupt latency can have a bad effect on kernel performance, and
Correct. Thats why the really hard stuff is pushed into bottom half handling or used via timer polls to aggregate processing (which sometimes as with serial gives you better cache footprint and lower per character overhead)
> 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?
Why not. It costs me less to handle the serial IRQ than it does to disable the irq and schedule a task.
> 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
Linux isn't a real time OS. Its a general purpose OS. Its job is to do a lot, do it roughly fairly and on the whole give good latency. Priority inversions, fancy task switching for interrupts and the like are pure overhead to almost all users.
RT-Linux provides real time, it runs the linux kernel as a task in fact.
> protection as well, I am not familiar with any systems that implement memory > protection on device drivers.
Mach does. It significantly increases overhead. That Mach type setup is regarded as failed. OSF Mach runs in a single address space nowdays. It is useful for one thing - delivering relatively provable military grade compartmentalisation. A useful facility thats also dying because its cheaper to provide two PCs
> 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.
Yep. Thats why Sun refused to fix a serious security hole for us for over a year, why Windows 95 still supports a ton of BIOS interfaces and 16bit drivers ... need I go on.
In the open source world a recompile is a near _zero_cost_ event. Its a new world, new rules.
> That doesn't mean that there is no reason to provide an opaque and stable > interface between the device driver and the operating system.
There is a very good reason for not doing that. The kernel interface is not opaque and stable. Trying to believe so is a delusion. You can heap piles of compatibility cruft in and every so often have a grand breakage and total rewrite or you can gradually shift over time, updating the drivers as you break things.
We try to avoid breaking source level interfaces in a stable kernel - that would be bad, but binary interfaces - what binary interface. The structure sizes depends on what compiler version you use for example.
Alan
- 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/
| |