> On Sun, 20 Sep 1998, Gerard Roudier wrote:
[ ... ]
> > > We have busses with shared interrupt lines and multifuction boards.
> > > Masking and priority are no longer viable design assumptions.
> >
> > The spl mechanism encourages to access data structures, assumed to belong
> > to a given level (or subsystem), directly across layers, without using
> > opaque interfaces. It also encourages to do more work than needed under
> > interrupt since not all interrupts are masked. I want to write that it
>
> Yes, the BSD structure encourages doing at lot of interrupt time.
> Example: the BSD networking stack is great for ping and ARP latency when you
> have a single network interface. It can do everything, including
> sending the response packet(!), during the receive interrupt. As someone
> concerned about network performance that sounds really great to me! Until
> some other subsystem thinks it can have the same luxury ;->. Or when a few
> 1500 byte ping packets on an ISA NE2000 blocks my 100mbps card's receive
> interrupts until the end of time.
BTW, I did'nt think I was so right. ;-)
> > > This leads to a great example of my previous point. AMD and Symbios have
> > > multifunction SCSI+Ethernet PCI chips. 3Com has Ethernet+Modem cards.
> > > Both functions share a single interrupt pin. It's no longer possible to
> >
> > It you are right here, these dual function boards are _not_ PCI compliant.
> > Function 1 shall use INTA line and function 2 shall use INTB line.
> > You may configure IRQ routing to share a single IRQ for the 2 functions of
> > a dual-function PCI device, but this is not required.
>
> A few reasons why that's not a usable design assumption for a portable OS:
> BIOS assignment of INT->IRQ mapping.
> PCI bus bridges.
> CardBus devices.
Donnot know of CardBus, but a portable O/S must have fast interrupt
handling, since it has to cope with all possible hardware interrupt
mechanisms.
You will not learn anything reading the below bad english, but I want to
write it. :)
For example, PCI, on PCs at least, requires PCI interrupt handling code to
be extremely fast since:
1 - Interrupt signalling is 'level sensitive'. That means that the IRQ has
to be masked at hardware level until all interrupt service routines
has been called and hopefully cleared the interrupt condition(s).
2 - It is not always possible to control the way the IRQ lines are shared
among devices, and a driver has no handle and no information about.
When an IRQ is shared by several subsystems, any interrupt handling by a
subsystem may break other ones if it is too slow. As a result, driver
writers must not assume that they can be slow servicing a PCI device
interrupt because they allows other interrupts to be delivered.
What about a sub-system that shares an IRQ with some slow interrupt
handler of another subsystem?
What about a fast and fine interrupt routine which is interrupted by a
slow one?
Any PCI interrupt handling must be _fast_ since any PCI device may share
the same IRQ with any other PCI device. Any not fast PCI originated
interrupt handling is a potential severe misfeature for the whole system.
As a joke, I claim that, as any PCI interrupt handler is required to be
extremely fast, regardless the actual response time needed by the device,
allowing or disallowing interrupt while servicing a PCI originated
interrupt should not make significant difference. :-)
(BTW, I know that allowing RT interrupts to be serviced is far better).
To be serious, if we want all Linux sub-system to be happy sharing IRQs,
we must ensure that PCI IRQ handling is fast in all situations in all
sub-systems that may use PCI devices.
I wrote 'PCI', but you can change 'PCI' by any other kind of bus on system
where there is no interrupt/execution levels that matches exactly O/S
priorities assumptions and/or needs. That' the case of portable O/Ses.
As a strangeness, UNIX systems that have been the first serious portable
O/Ses are known to do too much work under interrupt and to mask interrupt
longer than reasonnable.
Regards,
Gerard.
PS:
If a PCI keyboard or mouse ever exists, it also will be required to be
very fast for interrupt. :-)
-
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/