DragonFly kernel List (threaded) for 2005-05
Re: mtd_cpl question
: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
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.
I think the existing API is the ticket.