Re: Threading in IOKit (was: Protection Questions)
Re: Threading in IOKit (was: Protection Questions)
- Subject: Re: Threading in IOKit (was: Protection Questions)
- From: Shawn Erickson <email@hidden>
- Date: Mon, 3 Jun 2002 17:55:13 -0700
On Monday, June 3, 2002, at 04:27 PM, Scott Taggart wrote:
(The inflictor of IOWorkLoop on a poor unsuspecting world)
The workloop is a nice concept. As you can see, however, there are
natural
questions that arise as to the "rules". All I can say is the more
documentation and samples, the better ;)
And one final question (for now!). I am sure that if I had enough time
(which I don't), I could figure this out. And, the question itself is
tricky: I don't understand *how* registering an event (interrupt, etc.)
causes it to get gated (I would like the actual mechanism explained
because
I am curious). For example, I see one of the EN drivers registering an
interrupt function as a workloop "task". When I look at the interrupt
function itself, it just looks "normal" - that is it itself does nothing
workloop/gate related. So, suppose we have a registered interrupt
function
named "InterruptFunc()". Obviously, the hardware does not generate an
interrupt that directly calls this function - somehow, the gate code
gets
"in front" of this function, does the gate "thing" and then calls the
function when it owns the gate. Would you mind explaining how the gate
code gets put in "front" of a registered function (what is the "glue"
that
welds the source of the event (interrupt, timer, etc.) to the gate and
then
to the function being gated?
Have you read over the following?
<
http://developer.apple.com/techpubs/macosx/Darwin/IOKit/IOKitFundamentals/
HandlingEvents/index.html>
and
<
http://developer.apple.com/techpubs/macosx/Darwin/Reference/Kernel/IOWorkLoop/
Classes/IOWorkLoop/index.html>
and
<
http://developer.apple.com/techpubs/macosx/Darwin/Reference/Kernel/IOEventSource/
Classes/IOEventSource/index.html>
It is my understanding that workloop maintains a list of event sources.
Each workloop has a single thread, the workloops thread, that an event
source can signal (the trigger of event need not wait but can go on),
causing the thread to wake up. This thread will check the list of event
sources looking for ones that want have an event to deliver. If one is
found the thread lowers the gate (or sleeps waiting for it to be raised,
can happen because of IOCommandGates...) and calls the function
registered for a particular event source. Basically the function related
to the event source is called in the workloops thread not in that of the
events source. The workloop thread sleeps when no more events need to be
delivered.
Now IOCommandGates work with workloop differently then event sources.
They lower the workloop gate, if it is currently raised, and then calls
the related command gate function in the thread of the command gates
caller (humm... sorry for the poor wording). In other words it uses the
gate to sync with all other command gate and event sources on the given
workloop but it runs in the thread of caller. Now if the gate is
currently closed I think it either triggers the workloop thread to come
around when it get a chance or it sleep the calling thread waiting on
the gate to raise... (need to look this up).
For example in the case of an interrupt source when you init the
IOInterruptEventSource you tell it what object provides the interrupts
(for example a pci nub). This causes the interrupt event instance to
hook itself up with the real interrupt. You also tell the event source
about your driver object (usually) and what function(s) you want called
when the event is fired. You then tell the workloop about this event
source by using addEventSource (adds it to the list of event source),
this also informs the interrupt event source about the workloop (mostly
the way to signal the workloop it has an interrupt to report).
Now I could be wrong but this is how I currently understand things.
-Shawn
p.s. The source for all of this is available via Darwin.
_______________________________________________
darwin-kernel mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/darwin-kernel
Do not post admin requests to the list. They will be ignored.