Ingo Molnar <[EMAIL PROTECTED]> wrote: > we'll get rid of that pt_regs thing centrally, from all drivers at once > - there's upstream buy-in for that already, and Thomas already generated > a test-patch for that a few months ago. But it's not a big issue right > now.
Yay! Can you give me a pointer to the patch? > this shouldnt be a big issue either - we use indirect jumps all around > the kernel. Yes, I know. I'm sometimes concerned at just how fast indirect jumps (and even direct calls) are proliferating. Look at the read syscall path for something like ext3 these days: it's like a pile of spaghetti. That seems particularly true of direct-IO where it seems to weave in and out of core code and the filesystem as it goes down. I'm also concerned about stack usage. > CPUs are either smart enough to predict it I was told a while back (2002?) not to use indirect pointers for some stuff because CPUs _couldn't_ predict it. Maybe this has changed in modern CPUs. > > (3) ACK'ing and controlling interrupts has to be done by groups. > > please be more specific, Under some circumstances I can work out which sources have triggered which interrupts (there are various off-CPU FPGAs which implement auxiliary PICs that do announce their sources), but the aux-PIC channels are grouped together upon delivery to the CPU PIC, so some of the ACK'ing has to be done at the group level. > how is this not possible via genirq? How is it possible with genirq? Unless I tie all the grouped sources together into one virtual IRQ line, this doesn't appear to be possible. But doing that I might then also have a mixed set of "flow" types in any particular IRQ. > > (4) No account is taken of interrupt priority. > > hm, i'm not sure what you mean - could you be more specific? The FRV CPU, like many others, supports interrupt prioritisation. A particular interrupt level is set in the PSR, and any interrupt of a higher priority can interrupt. do_IRQ() can then do the interrupt processing in the interrupt level of the interrupt that invoked it, thus permitting higher priority interrupts to still happen. > but ... somehow the current FRV code does figure out which IRQ source > fired, right? Not always; sometimes it has to fall back to polling the drivers unfortunately. Btw why are we using IRQ_INPROGRESS, IRQ_DISABLED, IRQ_PENDING and friends? They would appear unnecessary. David - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
