lkml.org 
[lkml]   [1999]   [Sep]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [Q]: Linux and real device drivers
Date
From
> 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/

\
 
 \ /
  Last update: 2005-03-22 13:54    [W:0.051 / U:0.452 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site