Yes. But it was not obvious to me what to do when it was illegal so
I left it there.
> make the no_irq_type controller truly architecture-dependent.) Another
> more generic thing i'm thinking about (not done yet), to move the vector
> building defines near to every controller's source code section. This
> makes the thing a little bit more modular. Not all controllers are truly
> independent (there are obvious interactions between 8259A and the first
> IOAPIC in the system), but this is not a problem. The APIC/IOAPIC code
> OTOH has major modifications/fixes.
>
> what labels do you mean?
If you look at the build irq macros, you will see that common irq
has a label on the line of code that does "call do_IRQ" (unless linus
removed that later) and the other low level routines are similarly
labled. RTLinux is going to be nearly totally moduler and the init
code in the rtl module will patch that code to call rtl_intercept
instead of do_IRQ. What's missing for me now is an ifdefed code
section that will fill in a data structure with the pointers
#ifdef RTL_CONFIG
struct rtl_code {
void * call_common,do_irq,call_smpx,do_smpx ...
irq_desc, ... }
= initialize
#endif
Then there is a similar size ifdefed parts in system.h
#ifdef RTL_CONFIG
struct irq_control { do_cli,do_sti .... }
#define __cli() irq_control.do_cli()
...
and the export in ksysms
On insert the rtl module will patch the code, make a copy
of irq_desc handler list, replace irq_desc.handler in eah irq
with a soft handler pointer and change the irq_control structure
to point to soft cli and soft sti etc.
Anyway, that's the theory.
On module cleanup, the rtl module will unpatch and restore everything
to original. Interstingly enough, lmbench shows no performance
consequences of replacing cli/sti with indirect function calls.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/