This is the mail archive of the ecos-discuss@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

kernel Interrupt handling


Hello everybody,

I'm working on my master thesis in computer science, and the target of my
master thesis is eCos. The intention is to achieve the configurability
implemented with the help of the c-preprocessor at present by aspect
oriented programming with aspect c++ (see www.aspectc.org), of course some
parts of the eCos System are not reachable by this approach (I mean those
written in assembly), but this is not that bad, the kernel itself offers
enough opportunities, to give aspect c++ a chance. But, nevertheless, I want
to make some parts of the kernel become configurable, that are not
configurable now. At the moment I'm working on the interrupt handling of the
eCos kernel (maybe someone prefers a Cat. 1/Cat. 2 ISR handling scheme like
in the OSEK OS (see www.osek-vdx.org) to the ISR/DSR scheme implemented in
eCos).

My problem: 

I try to undestand the interrupt handling implemented in eCos and it appears
very similar to the concept I know as prologue/epilogue interrupt
synchronization, but I think there's one difference (maybe a big one).

In the prologue/epilogue style the prologue propagates an epilogue at
interrupt level then the prologue returns, maybe back to the task level.
After returning to the task level epilogues are executed provided that the
kernel is not locked at this time. If the kernel is currently locked,
epilogues will be executed, when kernel is unlocked.

The concept I encountered in eCos by reading the source code is the
following (assumed the scheduler is not locked at the time an interrupt
arives):

1. default vsr safes context
2. default vsr locks scheduler (why ???)
3. default vsr executes isr
4. default vsr calls interrupt_end
5. interrupt_end posts dsr (if necessary)
6. interrupt_end calls unlock
7. unlock executes dsrs (if necessary, these dsrs are executed on interrupt
level!!)
8. unlock returns, kernel is not locked any longer
9. interrupt_end returns
10. default vsr returns to task level.

My question: 
Did I understand the implementation? Is this the way the implementation is
intended to work?

My opinion:
 - default vsr should not lock the scheduler
 - after the dsr has been posted interrupt_end and the default vsr shall
finish
 - when returning to task level (t.m. we do not return from a nested
interrupt) we must check if there are any pending dsrs. If there are any and
the scheduler is not locked the dsrs are executed, if the scheduler is
locked the dsrs are stalled until the next unlock-operation.

When an interrupt arives while the scheduler is locked everything should
work fine, because inside the unlock that is called from interrupt_end, no
dsrs will be executed.

OK, I hope someone can help me. Either I missunterstood the implementation
of the interrupt handling inside the kernel or this is really the way the
kernel should deal with interrupts or neither the first nor the second.

Ciao, Fabian Scheler

-- 
+++ GMX - die erste Adresse für Mail, Message, More +++
1 GB Mailbox bereits in GMX FreeMail http://www.gmx.net/de/go/mail

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]