Best way to implement multiple UserClient connections?
Best way to implement multiple UserClient connections?
- Subject: Best way to implement multiple UserClient connections?
- From: James Wise <email@hidden>
- Date: Mon, 17 Sep 2012 17:39:42 +1000
Hey All,
I am a bit of a newby to this level of OSX programming and would love
some hints/tips regarding what i am doing.
Please excuse me if i have made any horrible mistakes.
So currently I maintain the software stack for a PCI-e add-In card.
Eg. Kext, + UserClients, Frameworks, + public API.
Currently I have multiple UserClients connecting to the kext, all based
IOUserClient, but the most used connections are an InputUserClient, and
an OutputUserClient.
In turn these two user clients, attach/listen to the input interrupts or
the output interrupts that are generated on the card itself.
Now the card in question contains not 1, but 2 pairs of interrupts, that
is, a total of 4 ( 2 in, 2 out)
I am currently trying to add support so that the user space framework
may access/connect to a UserClient that makes use of the second interrupts,
and enable multiple independent framework instances control of different
parts of the card.
However I am a bit confused on the best method to implement this process.
There is very little different between the input and output UserClients.
Basically the only difference is when we request a user Client the name
requested is different input vs ouput,
ie. the kext lists different names in it's plist, which then determines
which UserClient we connect to.
and this then dictates which interrupts on the card we listen to for
that UserClient.
(they actually instance exactly the same IOUserClient derived class,
just with slight different options.)
As much as anything i am really after information regarding best
practice, not just what will work, but the BEST way to make things work
1. Should I create a different instance of my UserClient that is the
same in all manner except which interrupts is listens to?
thus allowing multiple instances of my UserClient concurrently connected
to the kext.
( I think this is currently my preferred method)
2. Should I just expand the existing UserClient class to support
Both/multiple interrupt channels?
thus forcing all framework instances to talk to a single UserClient.
3. Is it possible to pass an argument during the UserClient
selection/init process?
(ie. this would allow me to Specify a video output userClient, with
Interrupt 1, instead of the default interrupt value?)
OR do I need to create an additional entry in my kext's list of devices
in it's plist - so that i can specify which interrupts i want to attach to
based upon the matching against the entries in the plist.
4. Is there inherently wrong about having multiple IOUserClients (of the
same type, but attached to different interrupts) connected to a kext driver?
( i know it's possible, I'm just unsure if this is a good idea or not.)
Currently I think that the best option is #1. ie. to have Multiple
IOUserClients that connect to my kext, where Each UserClient listens to
1 of the interrupts,
However i'm unsure if this can be done using a single "name" to connect
to the UserClient, or if i will need to specify a different service
"name" during matching in order to indicate which UserClient should
attach to which interrupt
Also I'm not sure if this contradicts this statement
"It is usually a good idea to limit access to your device to one user
space process at a time."
From….
http://developer.apple.com/library/mac/#samplecode/SimpleUserClient/Listings/User_Client_Info_txt.html#//apple_ref/doc/uid/DTS10000450-User_Client_Info_txt-DontLinkElementID_12
(bottom of page)
Anyway I know my Questions probably seem a bit all over the place, but i
am struggling to find good examples of more complex
kext/UserClient setups and examples, the docs and examples on Apple's
website are helpful and useful,
but are also simple and provide more technical guidance than a higher
level architectural guidance for more complex situations.
I also have Amit Sings OSX fundamentals book, which is good, but sort of
out of date now, and again doesn't really cover more complex examples
such as this.
Thanks for any help/pointers/links or conversation,
James
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden