Lennert Buytenhek <[EMAIL PROTECTED]> writes: > See for example arch/arm/mach-ep93xx/core.c, handling of the A/B/F > port GPIO interrupts. > > In a nutshell, it goes like this.
Thanks, I will investigate. >> There may be up to 6 Ethernet ports (not sure about hardware >> status, not yet supported even by Intel) - 7 queues * 128 entries >> each = ~ 3.5 KB. Add 2 long queues (RX) for HSS and something >> for TX, and then crypto, and maybe other things. > > You're unlikely to be using all of those at the same time, though. That's the point. > And what do you do if the user does compile all of these features into > his kernel and then tries to use them all at the same time? Return > -ENOMEM? If he is able to do so, yes - there is nothing we can do. But I suspect a single machine would not have all possible hardware. The problem is, we don't know what would it have, so it must be dynamic. > Shouldn't we make sure that at least the features that are compiled in > can be used at the same time? We can't - hardware capabilities limit that. A general purpose distribution would probably want to compile in everything (perhaps as modules). > If you want that guarantee, then you > might as well determine the SRAM map at compile time. That would be most limiting with IMHO no visible advantage. -- Krzysztof Halasa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
