pc386 IRQs not from i8259

[Joel Sherrill]

On 04/19/2010 03:52 PM, Till Straumann wrote:
> Maybe it's the appropriate time to implement apic support.
> That might be better than kludging something onto the
> legacy i8259 stuff.
>
>    
While this is a better solution long term,
I am trying to avoid the wide variety of deep deep
holes that could distract me.  My focus is on
the OS proper and its interface to the BSPs.
I want to get to a working baseline implementation
without spending years on tasks that can be left
as improvements.

This is really the first ugly thing I have encountered.
I already have a test program which can take from 1-32
core systems (according to qemu) from reset up to
a somewhat useful state and print their local CPU number.
Once I can generate an interprocessor interrupt, I can
return my focus to the OS issues proper.

I hope this makes sense. I would rather spend the time
right now on understanding SMP issues on multiple
architectures, the refactoring required, OS critical
sections, scheduling algorithms, etc.

--joel
> T.
>
>
> On 19/04/10 15:40, Joel Sherrill wrote:
>    
>> Hi,
>>
>> I am doing the groundwork for SMP support in RTEMS.
>> On the x86, an OS can generate Interprocessor Interrupts
>> (IPIs) to request that another CPU do something.
>> Unfortunately, it appears that the current IRQ
>> code is assuming that all interrupts are generated
>> from the i8259's.
>>
>> The IPI can have any vector number.
>>
>> My first thought is to use the first interrupt vector
>> after all the ones from the PICs and make things
>> work.
>>
>> Any suggestions?
>>
>>      
> _______________________________________________
> rtems-users mailing list
> rtems-users at rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-users
>    


-- 
Joel Sherrill, Ph.D.             Director of Research&  Development
joel.sherrill at OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
    Support Available             (256) 722-9985