June 2002 - Darwin-kernel - lists.apple.com

Re: Undefined "atexit" in kext driver
by Godfrey van der Linden 04 Jun '02

04 Jun '02

Do you write your own makefiles or do you use PB files? Which compiler are you using. Can I see the make line for a C++ file? Godfrey At 17:46 -0700 02-6-3, Scott Taggart wrote: Hi, I get an undefined "atexit" symbol when I load my kext. I have seen this before but it was very hard to track down (I have dozens of files and none explicitly reference atexit()). I presume this is my code referencing some library function that is referencing atexit. I searched the archives and could find no mention of this. Any ideas on how to find where this is referenced? _______________________________________________ darwin-kernel mailing list | darwin-kernel(a)lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-kernel Do not post admin requests to the list. They will be ignored.

1 0

Re: Undefined "atexit" in kext driver
by Justin C. Walker 04 Jun '02

04 Jun '02

On Monday, June 3, 2002, at 08:46 , Scott Taggart wrote: Hi, I get an undefined "atexit" symbol when I load my kext. I have seen this before but it was very hard to track down (I have dozens of files and none explicitly reference atexit()). I presume this is my code referencing some library function that is referencing atexit. I searched the archives and could find no mention of this. Any ideas on how to find where this is referenced? Have you tried 'nm' on your various objects? Note that you can't use the system's normal "C Library" in kernel extensions (don't know if you know this; just thought I'd point it out, since the appearance of 'atexit' is pretty weird). Regards, Justin -- Justin C. Walker, Curmudgeon-At-Large * Institute for General Semantics | When LuteFisk is outlawed | Only outlaws will have | LuteFisk *--------------------------------------*-------------------------------*-- _______________________________________________ darwin-kernel mailing list | darwin-kernel(a)lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-kernel Do not post admin requests to the list. They will be ignored.

1 0

Re: Threading in IOKit (was: Protection Questions)
by Shawn Erickson 04 Jun '02

04 Jun '02

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/IOWorkLo… Classes/IOWorkLoop/index.html> and <http://developer.apple.com/techpubs/macosx/Darwin/Reference/Kernel/IOEventS… 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 | darwin-kernel(a)lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-kernel Do not post admin requests to the list. They will be ignored.

1 0

Undefined "atexit" in kext driver
by Scott Taggart 04 Jun '02

04 Jun '02

Hi, I get an undefined "atexit" symbol when I load my kext. I have seen this before but it was very hard to track down (I have dozens of files and none explicitly reference atexit()). I presume this is my code referencing some library function that is referencing atexit. I searched the archives and could find no mention of this. Any ideas on how to find where this is referenced? Thanks, Scott _______________________________________________ darwin-kernel mailing list | darwin-kernel(a)lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-kernel Do not post admin requests to the list. They will be ignored.

1 0

Re: Threading in IOKit (was: Protection Questions)
by Fernando Urbina 04 Jun '02

04 Jun '02

Scott Taggart said: > How do you "defer" the shutdown of the driver when you get a "terminate()" > call to wait for the timer completion? Are there any samples of how to do > this? Look at the IOUSBFamily and any of the drivers (check IOUSBHIDDriver, for example). Look at the willTerminate() routine and the Increment/DecrementOutstandingIO(). You can essentially defer the closing of your provider until your timeout expires. That will prevent your driver from being torn down all the way. -- Fernando Urbina mailto:nano@apple.com USB Technology Team work: 719.534.9387 Apple Computer, Inc. fax: 719.532.0981 _______________________________________________ darwin-kernel mailing list | darwin-kernel(a)lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-kernel Do not post admin requests to the list. They will be ignored.

1 0

Re: Threading in IOKit (was: Protection Questions)
by Scott Taggart 03 Jun '02

03 Jun '02

Godfrey, Thanks for the extended response. And, fine by me if this becomes the starting place for documenting how all this works (I'm sure others will agree). I have a few follow-ups. At 02:51 PM 6/3/2002, Godfrey van der Linden wrote: >Basically there are two locking mechansims you will need to worry about. > >One is the IOWorkLoop you are slaved against, that is the workloop of the >USB controller. The second lock is the network funnel. In general you >will not have to worry about the funnel as the IONetworkingFamily will >handle most of that for you. OK, so the USB stuff is self-gated, so to speak so one USB completion will not preempt another USB completion. I am unclear exactly what you mean by not worrying about network funnel other than are you saying that the same applies to it as the USB completions - that is that all network calls will be self-protected (from themselves that is). Is this correct (but USB callbacks are not protected against network calls and vice-versa?- see my questions below)? >Now to address some of your questions. > >In X you don't get anything at Primary interrupt time, so that is easy >(Note PCI device do have access to the primary interrupt through the >IOFilterInterruptEventSource but you are a USB device so you don't have to >worry about that. > >All USB completions come on the USBs IOWorkLoop and thus holds the >gate. If you wish to synchronise a 'down' call against your completions >you can do this by creating your on IOCommandGate and registering it >against your work loop. You get the correct work loop to use by call >IOService::getWorkLoop() on yourself so that is pretty >easy. getWorkLoop() automatically walks down your provider chain looking >for a driver that exports the completion context, the USB controller in >your example. By "down", I assume you mean a call from the network stack into my USB driver? (again, I am new to this, so I will butcher the assumptions I make and the terminology I use). If I understand this correctly, you are saying that the network calls (could/might) preempt the USB callbacks (and vice-versa) and thus need to be gated against the same gate as the USB callbacks, correct? Can you point me to code that manually creates its own IOCommandGate() (I am sure I can find this but if you can just give me a file name, that would be great). >Timers also synchronise against the work loop when you use the >IOTimerEventSource. However there is a long outstanding bug against the >IOTES where it doesn't have a deterministic way of cancelling at the >moment. If you wish to shut down a driver and still have a timer >outstanding it is usually better to just wait for the last timeout to >occur rather than attempting to cancel it. (yes I have had this bug for a >long time and the fix is pretty easy but I have a long list of other very >high priority problems to fix first). How do you "defer" the shutdown of the driver when you get a "terminate()" call to wait for the timer completion? Are there any samples of how to do this? >Now there are a couple of X subtleties that 9 didn't have. > >Provided you use the work loop paradigm then it is easy to synchronise >against all callouts and also easy to keep down calls correct by using >your own command gate. But you do have to watch out for blocking >calls. It is probably never correct to issue a call that can block >indefinitely while in a gated context. However short, (how short is >undefined?) delays acceptable, hence it is ok to use locks on a work loop >context but it is better if you don't need to. Seems reasonable to not "block". So, this leads me to the natural questions: What calls can and can't be blocked? How long is "too" long? I think in my case, I just queue most requests and return, which, I presume is the "right" way to handle things. >(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? Many thanks, Scott _______________________________________________ darwin-kernel mailing list | darwin-kernel(a)lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-kernel Do not post admin requests to the list. They will be ignored.

1 0

Threading in IOKit (was: Protection Questions)
by Godfrey van der Linden 03 Jun '02

03 Jun '02

Basically there are two locking mechansims you will need to worry about. One is the IOWorkLoop you are slaved against, that is the workloop of the USB controller. The second lock is the network funnel. In general you will not have to worry about the funnel as the IONetworkingFamily will handle most of that for you. Now to address some of your questions. In X you don't get anything at Primary interrupt time, so that is easy (Note PCI device do have access to the primary interrupt through the IOFilterInterruptEventSource but you are a USB device so you don't have to worry about that. All USB completions come on the USBs IOWorkLoop and thus holds the gate. If you wish to synchronise a 'down' call against your completions you can do this by creating your on IOCommandGate and registering it against your work loop. You get the correct work loop to use by call IOService::getWorkLoop() on yourself so that is pretty easy. getWorkLoop() automatically walks down your provider chain looking for a driver that exports the completion context, the USB controller in your example. Timers also synchronise against the work loop when you use the IOTimerEventSource. However there is a long outstanding bug against the IOTES where it doesn't have a deterministic way of cancelling at the moment. If you wish to shut down a driver and still have a timer outstanding it is usually better to just wait for the last timeout to occur rather than attempting to cancel it. (yes I have had this bug for a long time and the fix is pretty easy but I have a long list of other very high priority problems to fix first). Now there are a couple of X subtleties that 9 didn't have. Provided you use the work loop paradigm then it is easy to synchronise against all callouts and also easy to keep down calls correct by using your own command gate. But you do have to watch out for blocking calls. It is probably never correct to issue a call that can block indefinitely while in a gated context. However short, (how short is undefined?) delays acceptable, hence it is ok to use locks on a work loop context but it is better if you don't need to. Also you have to watch out for various scheduling priorities. Broadly we have 1> Primary Interrupts 2> Real Time Threads (user land only) 3> Timer threads (Thread Call threads, kernel only) 4> Kernel threads (IOWorkLoop aka 'secondary interrupts') 5> Window Manager Threads 6> The rest of user land threads. Sometimes the priorites seems a bit screwed up, for instance a timeout will schedule before a secondary interrupt, but provided you know this can occur it is pretty easy to write a timeout routine that checks to see if the hardware has completed or not. Finally Scott I have been meaning to write up this stuff for a while. In fact I have twice unsucessfully asked for a WWDC session to cover it in detail (I failed in both cases 'cause I was too late and there was no time left). Anyway why don't we use this email conversation as a way of getting on the record? Godfrey van der Linden (The inflictor of IOWorkLoop on a poor unsuspecting world) _______________________________________________ darwin-kernel mailing list | darwin-kernel(a)lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-kernel Do not post admin requests to the list. They will be ignored.

1 0

Protection Questions
by Scott Taggart 03 Jun '02

03 Jun '02

[sorry for the cross-post - I got no response when posted to the darwin-drivers list] I am writing a kernel USB driver (kext) that talks at its upper-edge to the Ethernet stack and to the USB stack at its lower edge (pardon the butchering of terminology here). I have a version of this driver running on 8/9. In the 8/9 version there are the following sources of interrupts (asynchronous events, if you will): * Timer * Network stack outbound data * Network stack polls for inbound data (on 8/9 the net stack polls and I think on X I call "up" with received data). * USB Read completions * USB write completions * USB control pipe completions * USB Interrupt pipe completions Without going into great detail, assume that each of these events must access some or all of the data structures within the driver that the other events access (i.e, a read completion access something that a timer completion also accesses). On my 8/9 driver, the only practical way to protect shared data structures is by selectively disabling interrupts at the appropriate places in the code where multiple events might touch shared data (since there is virtually no support for any other critical-section mechanisms on 8/9). Fast-forward to X. There seem to be a plethora of different ways to serialize, lock, etc. (work loops, IOLocks, semaphores, gates, mutexes, ) in drivers, with not a lot of documentation as to when or how or why you would choose one over another, when one will work or wont work, what you can and cant do from where (for example, what O/S calls are legal or illegal to make from a USB read-pipe completion?). My question is this: Given all the possible sources of asynchronous events I describe above (some of which are interrupt-level, others maybe not (not well documented either)), what mechanism should I use to protect my data structures? Is there one that will work for all (e.g., can I use an IOLock to protect everything from all sources?)? Do I have to use different methods? What works where (e.g., from a timer, you may use but you may not use "..."). What does not work and where? What I'd really like to do is that from any place in my code that needs to protect itself from one of the "other" sources of interrupts/entry I do a simple "lock()/unlock()" mechanism. Admittedly, I don't understand the workloop/gate mechanism (I understand some of the principals but not the mechanics). Can I register the USB callbacks with the workloop mechanism (do I even have to - are they already routed through the workloop?)? I see sample code in the Ethernet driver to register an interrupt function. Could someone explain to be how the underlying mechanism actually works? I see an interrupt function get registered but I don't see the "magic" behind preventing that function from getting called directly by the source of the interrupt - there's something behind the scenes going on that I don't understand. Your help is greatly appreciated. Scott _______________________________________________ darwin-kernel mailing list | darwin-kernel(a)lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-kernel Do not post admin requests to the list. They will be ignored.

1 0