Re: IORegistry crash (was: Two IOService in the same kext ? )
Re: IORegistry crash (was: Two IOService in the same kext ? )
- Subject: Re: IORegistry crash (was: Two IOService in the same kext ? )
- From: Shawn Erickson <email@hidden>
- Date: Thu, 30 May 2002 19:26:26 -0700
On Thursday, May 30, 2002, at 03:27 PM, Francis bouchard wrote:
On 30/05/02 17:00, "Shawn Erickson" <email@hidden> 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 | 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.