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

Re: IORegistry crash (was: Two IOService in the same kext ? )
by Shawn Erickson 31 May '02

31 May '02

On Thursday, May 30, 2002, at 03:27 PM, Francis bouchard wrote: On 30/05/02 17:00, "Shawn Erickson" <shawn(a)freetimesw.com> wrote: When your frame buffer driver attaches to your effect driver... how do things operate? It sounds like the frame buffer it still assuming it is matching against your hardware. Basically your frame buffer is not attached to your hardware at this point but to your effect driver. I'm not sure about this one! How should it be. I've put the pci device id but what should I put there if I want it to match to the effectDriver ? The class name ? Do I still use IOPCIMatch or another obscure (for me at least) tag. You only need to use IOPCIMatch if your diver needs to match against hardware... so effect driver: yes, frame buffer: no. To get your frame buffer to match against your effect driver then you must specific the effect drivers class name in IOProviderClass. Your prior emailed plists looks correct with the one exception you still have IOPCIMatch listed in you frame buffers plist. [What is com.matrox.driver.MatroxBoard listed in your effect driver plist? This may be a typo.] Anyway my question was more along the lines of how do expect/want your two drivers to work with one another once they have been matched, which leads to... [Or does only your effect driver need interact with your hardware and your frame buffer ask it do things when needed?] This is exactly how I would like it to be. It's gonna be much simpler since the effect driver already handles synchronisation between requests. So matching gets your frame buffer to know about your effects driver... after this point it is up to you to define and implement the way they will interact with each other. I would consider using the open/close semantics provided by IOService so that the connection between your frame buffer and effects driver is tracked (lookup open & close on IOService). Basically define methods on your effects driver class that expose the functionality needed by your frame buffer class. Then all your frame buffer need do is call methods on the effect driver class as needed. I would still use the workloop that your effect driver uses to sync your frame buffer functionality as it cuts down on the number of workloops (fewer threads). In your frame buffer start method retain and save a reference to your effect driver, open the effect driver, do what preparation is needed, and return true. Then as your frame buffer is asked to do things internally you call your effect driver as needed. Also have your getWorkloop method call the effects driver getWorkloop method (unless IOFrameBuffer is design to have it own... I don't know?). When stopping your frame buffer should cleanup, close the effect driver and release its reference. -Shawn _______________________________________________ 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: IORegistry crash (was: Two IOService in the same kext ? )
by Francis bouchard 30 May '02

30 May '02

On 30/05/02 17:00, "Shawn Erickson" <shawn(a)freetimesw.com> wrote: > When your frame buffer driver attaches to your effect driver... how do > things operate? It sounds like the frame buffer it still assuming it is > matching against your hardware. Basically your frame buffer is not > attached to your hardware at this point but to your effect driver. I'm not sure about this one! How should it be. I've put the pci device id but what should I put there if I want it to match to the effectDriver ? The class name ? Do I still use IOPCIMatch or another obscure (for me at least) tag. > > [Or does only your effect driver need interact with your hardware and > your frame buffer ask it do things when needed?] This is exactly how I would like it to be. It's gonna be much simpler since the effect driver already handles synchronisation between requests. Francis _______________________________________________ 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: IORegistry crash (was: Two IOService in the same kext ? )
by Shawn Erickson 30 May '02

30 May '02

On Thursday, May 30, 2002, at 12:27 PM, Francis bouchard wrote: If it can help you, this is where ioreg stops dumping info ... | | +-o pci-bridge@3 <class IOPCIDevice> | | | +-o IOPCI2PCIBridge <class IOPCI2PCIBridge> | | | +-o MTRX,Toucan@0 <class IOPCIDevice> | | | | +-o com_matrox_driver_MatroxMmgdG400 <class com_matrox_driver_MatroxMmgdG400> I've found now that my FrameBuffer loads and start (but still won't recognize it as a display). I still have the IORegistry crashing (or ioreg stop from dumping info) Not sure about the ioreg issue... Other investigations I've made: Detach the FrameBuffer from EffectDriver and use IOPCIDevice and everything works fine! ioreg not crashing and a display. But this is not the correct way to go since it will create problems when I will do effects... When your frame buffer driver attaches to your effect driver... how do things operate? It sounds like the frame buffer it still assuming it is matching against your hardware. Basically your frame buffer is not attached to your hardware at this point but to your effect driver. How do they interact with each other or how do you expect them to interact? I believe you need to define and implement how your frame buffer will interact with your effect driver to carry out operations on your hardware. Many ways exist... One way would be to get the PCI nub (instance of IOPCIDevice) from your effect driver and share your effect driver workloop when accessing your hardware (assuming you need to synchronize access to your hardware). Also remember your effect driver would most likely be the one setup to respond to interrupts from your adapter (unless it doesn't add an interrupt event source to workloop). [Or does only your effect driver need interact with your hardware and your frame buffer ask it do things when needed?] -Shawn _______________________________________________ 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: IORegistry crash (was: Two IOService in the same kext ? )
by Francis bouchard 30 May '02

30 May '02

Sorry for the confusion, super is actially a custom MatroxIOService that does housekeeping for all our driver. This class does it. MatroxIOService public IOService com_matrox_driver_Effects public MatroxIOService On 30/05/02 15:33, "Godfrey van der Linden" <gvdl(a)apple.com> wrote: > Is IOService the parent of 'com_matrox_driver_Effects'? If so then > registerService() is NOT done by IOService. > > Godfrey > > At 14:38 -0400 02-5-30, Francis bouchard wrote: >> On 30/05/02 14:33, "Godfrey van der Linden" <gvdl(a)apple.com> wrote: >> >>> Then call >>> at starttime have com_matrox_driver_Effects::start(provider) call >>> registerService() just before returning. >> Does the fact that calling this function not at the end of the start could >> change things ? It is actually done in a base class (derived from IOService) >> for our dirvers. So: >> >> com_matrox_driver_Effects::start(provider) >> { >> super::start(); // registerService() is done here >> >> // more stuff >> } >> >> Francis _______________________________________________ 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: IORegistry crash (was: Two IOService in the same kext ? )
by Godfrey van der Linden 30 May '02

30 May '02

Is IOService the parent of 'com_matrox_driver_Effects'? If so then registerService() is NOT done by IOService. Godfrey At 14:38 -0400 02-5-30, Francis bouchard wrote: On 30/05/02 14:33, "Godfrey van der Linden" <gvdl(a)apple.com> wrote: Then call at starttime have com_matrox_driver_Effects::start(provider) call registerService() just before returning. Does the fact that calling this function not at the end of the start could change things ? It is actually done in a base class (derived from IOService) for our dirvers. So: com_matrox_driver_Effects::start(provider) { super::start(); // registerService() is done here // more stuff } Francis _______________________________________________ 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: IORegistry crash (was: Two IOService in the same kext ? )
by Francis bouchard 30 May '02

30 May '02

If it can help you, this is where ioreg stops dumping info ... | | +-o pci-bridge@3 <class IOPCIDevice> | | | +-o IOPCI2PCIBridge <class IOPCI2PCIBridge> | | | +-o MTRX,Toucan@0 <class IOPCIDevice> | | | | +-o com_matrox_driver_MatroxMmgdG400 <class com_matrox_driver_MatroxMmgdG400> I've found now that my FrameBuffer loads and start (but still won't recognize it as a display). I still have the IORegistry crashing (or ioreg stop from dumping info) Other investigations I've made: Detach the FrameBuffer from EffectDriver and use IOPCIDevice and everything works fine! ioreg not crashing and a display. But this is not the correct way to go since it will create problems when I will do effects... A crash log of ioreg help ? Impossible... It's not generating one. But here is in the console: Rexplorer.m:109 failed assertion 'status == KERN_SUCCESS' Francis _______________________________________________ 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: IORegistry crash (was: Two IOService in the same kext ? )
by Shawn Erickson 30 May '02

30 May '02

You shouldn't call registerService until you are ready to service requests from others. Shortly after the registerService call drivers could match against your driver. Mac OS X is multi-threaded so this could happen concurrently while you are still in your start method. So don't register until you are ready. /*! @function registerService @abstract Start the registration process for a newly discovered IOService. @discussion This function allows an IOService subclass to be published and made available to possible clients, by starting the registration process and delivering notifications to registered clients. The object should be completely setup and ready to field requests from clients before registerService is called. @param options The default zero options mask is recommended & should be used in most cases. The registration process is usually asynchronous, with possible driver probing & notification occurring some time later. kIOServiceSynchronous may be passed to carry out the matching and notification process for currently registered clients before returning to the caller. */ -Shawn On Thursday, May 30, 2002, at 11:38 AM, Francis bouchard wrote: On 30/05/02 14:33, "Godfrey van der Linden" <gvdl(a)apple.com> wrote: Then call at starttime have com_matrox_driver_Effects::start(provider) call registerService() just before returning. Does the fact that calling this function not at the end of the start could change things ? It is actually done in a base class (derived from IOService) for our dirvers. So: com_matrox_driver_Effects::start(provider) { super::start(); // registerService() is done here // more stuff } Francis _______________________________________________ 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: IORegistry crash (was: Two IOService in the same kext ? )
by Francis bouchard 30 May '02

30 May '02

Everything you said is right. On 30/05/02 14:40, "Shawn Erickson" <shawn(a)freetimesw.com> wrote: > At this point your effect driver can register itself (registerService) > as being ready for others to use. (It could also publish nubs, which > themselves would register for others to utilize.) We actually also do publishResource(m_fnEntryPoint, this); after the registerService(); All my classes and IOProviderClass seems right so here is my 2 plists: IOFrameBuffer Driver: ------------------------------------------------------ <dict> <key>CFBundleDevelopmentRegion</key> <string>English</string> <key>CFBundleExecutable</key> <string>MatroxDisplayG400</string> <key>CFBundleIdentifier</key> <string>com.matrox.driver.MatroxDisplayG400</string> <key>CFBundleInfoDictionaryVersion</key> <string>6.0</string> <key>CFBundlePackageType</key> <string>KEXT</string> <key>CFBundleVersion</key> <string>1.0.0</string> <key>IOKitPersonalities</key> <dict> <key>FirstPersonality</key> <dict> <key>CFBundleIdentifier</key> <string>com.matrox.driver.MatroxDisplayG400</string> <key>IOClass</key> <string>com_matrox_driver_MatroxDisplayG400</string> <key>IOMatchCategory</key> <string>IOFramebuffer</string> <key>IOPCIMatch</key> <string>0x0525102b</string> <key>IOProviderClass</key> <string>com_matrox_driver_MatroxMmgdG400</string> </dict> </dict> <key>OSBundleLibraries</key> <dict> <key>com.apple.iokit.IOGraphicsFamily</key> <string>1.1</string> <key>com.apple.kernel.iokit</key> <string>1.1</string> <key>com.matrox.driver.MatroxMmgdG400</key> <string>1.0.0d1</string> </dict> </dict> </plist> ------------------------------------------------------ Effet driver ------------------------------------------------------ <dict> <key>CFBundleDevelopmentRegion</key> <string>English</string> <key>CFBundleExecutable</key> <string>MatroxMmgdG400</string> <key>CFBundleIdentifier</key> <string>com.matrox.driver.MatroxMmgdG400</string> <key>CFBundleInfoDictionaryVersion</key> <string>6.0</string> <key>CFBundlePackageType</key> <string>KEXT</string> <key>CFBundleVersion</key> <string>1.0.0</string> <key>IOKitPersonalities</key> <dict> <key>FirstPersonality</key> <dict> <key>CFBundleIdentifier</key> <string>com.matrox.driver.MatroxMmgdG400</string> <key>IOClass</key> <string>com_matrox_driver_MatroxMmgdG400</string> <key>IOMatchCategory</key> <string>RTMac</string> <key>IOPCIMatch</key> <string>0x0525102b</string> <key>IOProviderClass</key> <string>IOPCIDevice</string> <key>IOUserClientClass</key> <string>com_matrox_driver_MatroxMmgdG400UserClient</string> </dict> </dict> <key>OSBundleCompatibleVersion</key> <string>1.0.0d1</string> <key>OSBundleLibraries</key> <dict> <key>com.apple.iokit.IOPCIFamily</key> <string>1.1</string> <key>com.apple.kernel.iokit</key> <string>1.1</string> <key>com.matrox.driver.MatroxBoard</key> <string>1.0.0d1</string> </dict> </dict> </plist> _______________________________________________ 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: IORegistry crash (was: Two IOService in the same kext ? )
by Shawn Erickson 30 May '02

30 May '02

Yeah, plist samples would help. As you seem to be doing but just to restate... Basically your effect driver should match against your hardware using the normal PCI match methods (it is PCI based correct?). Your effect driver then will get matched, probed, and things go correctly started. At this point your effect driver can register itself (registerService) as being ready for others to use. (It could also publish nubs, which themselves would register for others to utilize.) So your frame buffer driver should be setup to match against your effect driver (using the full class name of the effect driver in IOProviderClass). This will get your frame buffer driver loaded shortly affect your effect driver registers itself. In the probe and start method calls you will get a pointer to your effect driver (the provider pointer). Your frame buffer should cache this reference and use it to interact with the effect driver, etc. (You could consider using the open/close methods to build a "strong" relationship between your two drivers.) The important thing is that your effect driver shouldn't register itself until it is ready to be used by others. Also your frame buffer kext bundle will need to be in the /System/Library/Extensions directory for matching to work correctly (it doesn't scan outside of that directory). Of course you most likely could load the kexts manually, load the frame buffer kext and soon afterwards load the efffect driver kext. This gets the frame buffer into the kernel so it will match against the effect driver once it regs itself. -Shawn On Thursday, May 30, 2002, at 11:06 AM, Godfrey van der Linden wrote: It depends on how you publish your com_matrox_EffectDriver (Note the prefix, this is really important quite a few drivers are going to have effects right?) How does the 'Effect Driver' get created? How does your FrameBuffer get created? can we see the IOKitPersonalties? Godfrey At 13:24 -0400 02-5-30, Francis bouchard wrote: Sorry for cross posting but I am really desperate. For the one who followed this thread, here is the status. I would like my driver model to look like the drawing. My IOFrameBuffer declares an IOProvicerClass of EffectDriver (which its provider is an IOPCIDevice). This way My effectDriver which is a service provider for my FrameBuffer gets loaded before the IOFrameBuffer and the FrameBuffer gets the pointer to the EffectDriver (its provider through the parameter in the start routine. But it doesn't work! HELP!!!! How do I make a driver a provider for another class ??? If I put the IOProviderClass in the bundle settings, my driver won load (kmod but no init called). A hint is that ioreg or IORegistry crashes! for some reason, as soos as I try to connect my IOFrameBuffer ot the effect dirver I seem to break everything up. If I put IOPCIDevice in the IOProviderClass and "slmost stub my frame buffer" everything is OK. Francis On 28/05/02 12:52, "Francis bouchard" <francis.bouchard(a)matrox.com> wrote: I agree that I'm more fighting with IOKit than using it. Let's see how my drivers works. Let's try ou my _talent_ for drawing. ------ ------------------ | OS | | our effects | User Land ------ ------------------ ________________|____________________________|_________ KernelLand | | ------------------- ------------------ | IOFBUserClient | | EffectDriver | | IOFrameBuffer | | UserClient | ------------------- ------------------ | | | ------------------ |_______________________| EffectDriver | | (IOService) | ------------------ _______________________________________________ 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: IORegistry crash (was: Two IOService in the same kext ? )
by Francis bouchard 30 May '02

30 May '02

On 30/05/02 14:33, "Godfrey van der Linden" <gvdl(a)apple.com> wrote: > Then call > at starttime have com_matrox_driver_Effects::start(provider) call > registerService() just before returning. Does the fact that calling this function not at the end of the start could change things ? It is actually done in a base class (derived from IOService) for our dirvers. So: com_matrox_driver_Effects::start(provider) { super::start(); // registerService() is done here // more stuff } Francis _______________________________________________ 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