Re: mtd_cpl question

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

:Ok, I will start with the em driver. Are you suggesting a network driver 
:because the network stack does not depend on the BGL (I think that's 
:what you meant above wrt SPL)?

    Well, we are still running mostly under the BGL.  The main issue is
    that we don't want to blow up the disk I/O path testing the stuff.
    The network path is a much safer thing to blow up.

:>     Are MSI interrupts edge triggered or level triggered?  There's more
:>     work involved if they are edge triggered.
:
:PCIe defines them to be edge, but I'd have to look at the base spec to 
:know what happens on PCI.

    I'm not sure if its possible to make it level triggered.  MSI works
    by having the PCI device write a completion code directly into the 
    I/O APIC.  I don't think it writes a second code to 'clear' the
    interrupt.  But I haven't researched it.

    Ok, this will require a bit of work then.  We need a mechanism to
    support delaying the interrupt dispatch in order to support critical
    sections.  Also, some drivers (the EM being one of them) disable and
    enable the interrupt at a whim and expect it to re-dispatch as necessary.
    That obviously won't work.  The last part, anyhow, should be easy...
    the driver can just poll for pending work every time it reenables
    the interrupt.

    Dealing with delaying the interrupt dispatch is harder.  Right now
    we use the CPL mechanism for that.  The assembly code is either
    going to have to be modified to operate on 256 bits instead of 32,
    or we have to come up with another way to keep track of delayed 
    interrupts.  I don't think it's a huge deal to modify the assembly,
    it's just a pain because, well, it's assembly.

    You will want to use something very similar to the existing 
    interrupt vector assembly macros for your new vectors.  Those at 
    least should be trivial to expand to support 256 bits because they
    are generated one vector at a time and can simply calculate the correct
    offset into the bitmap.

:>     You should be able to write IDT entries within the bounds of the IDT
:>     table, as long as they do not interfere with existing IDT entries for
:>     slow and fast interrupt vectors.  I'm presuming that you will use the
:>     same API that the interrupt code uses to access those entries, right ?
:
:I'd rather use the existing API unless there is something that prevents it.
:
:-- 
:Chuck Tuffli
:Agilent Technologies

    I think the existing API is the ticket.

					-Matt
					Matthew Dillon 
					<dillon@xxxxxxxxxxxxx>