Hey All, 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. 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. ( I think this is currently my preferred method) thus forcing all framework instances to talk to a single UserClient. based upon the matching against the entries in the plist. ( i know it's possible, I'm just unsure if this is a good idea or not.) Also I'm not sure if this contradicts this statement (bottom of page) 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 (Darwin-kernel@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.... This email sent to site_archiver@lists.apple.com I am a bit of a newby to this level of OSX programming and would love some hints/tips regarding what i am doing. 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. 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. 2. Should I just expand the existing UserClient class to support Both/multiple interrupt channels? 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 4. Is there inherently wrong about having multiple IOUserClients (of the same type, but attached to different interrupts) connected to a kext driver? 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 "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... 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.