Re: In kernel PIC support: kernel patch

On Thu, 2007-06-21 at 15:17 +0000, Gregory Haskins wrote:

On Thu, 2007-06-21 at 22:28 +0800, Dong, Eddie wrote:

quoted

quoted

I suppose, but it somewhat defeats the purpose IMO.  Every pin in the
8259 that gets tickled implicitly means an IOAPIC pin was tickled
also. Do we really want to go to userspace for that?  Essentially

User space can handle this, go to IOAPIC first and then decide to go to 
in kernel PIC or not. Here the assumption is that an irq line is either
serviced
by PIC or IOAPIC, it will never be serviced by both.

So no back to user space.

Thinking about it some more, I see some conditions where this
optimization doesn't work (and was one of the reasons driving my
redesign of the subsystem).  For instance, when linux routes the PIT as
an NMI and an IOAPIC based event.  In this case, the PIT raises an
interrupt which tickles an isa interrupt line that should be routed to
both the PIC and the IOAPIC #IRQ0.  Both devices should have IRQ0
unmasked.  The former will get routed to the APIC via tickling the LINT0
line.  The latter will get routed as an APIC-MSG based on the
programming of the IOAPICs IRQ0 line.

I believe this is a scenario which is mis-emulated today at least
partially due to the assumption that only one device is in use at a
time.

All is not lost, however.  This just helps drive the decision to move
the IOAPIC with the PIC ;)

-Greg 


-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/