While a socket is a fine way to bridge user-to-kernel space, IOUserClient will be a better impedance match to an IOKit driver.
Have a look at: • Simple User Client example: <https://developer.apple.com/library/Mac/samplecode/SimpleUserClient/Introduction/Intro.html <https://developer.apple.com/library/Mac/samplecode/SimpleUserClient/Introduction/Intro.html>> • Sample Signed PCI Driver: <https://developer.apple.com/library/mac/samplecode/AppleSamplePCI/Introduction/Intro.html <https://developer.apple.com/library/mac/samplecode/AppleSamplePCI/Introduction/Intro.html>> • IOUserClient Class Reference: <https://developer.apple.com/library/mac/documentation/Kernel/Reference/IOUserClient_reference <https://developer.apple.com/library/mac/documentation/Kernel/Reference/IOUserClient_reference>> • I/O Kit Framework Reference (IOKitLib): <https://developer.apple.com/library/Mac/documentation/IOKit/Reference/IOKitLib_header_reference/index.html#//apple_ref/doc/uid/TP40012419 <https://developer.apple.com/library/Mac/documentation/Darwin/Reference/IOKit/_index.html>> That being said, I think you should reconsider porting your in-kernel code to a user-space process. You will need to have a user-space process anyway to manage the device and produce/consume the data. If you port the USB driver portion of your code to that process, then you can eliminate the in-kernel portion entirely. I suspect in the end, it will be less work to port to user space than to construct a user-kernel bridge — keep in mind that you have to debug your whole stack across the user-kernel boundary which is much more complicated and time consuming than debugging a user-space-only design. Cheers, - Dean On Oct 22, 2014, at 3:40 AM, Peter Sichel <[email protected]> wrote: > > The canonical way to communicate between an application in user space and a > kernel-space driver is through a socket. > > Enjoy! > > Sent from my iPad > > On Oct 21, 2014, at 10:15 PM, nick <[email protected] > <mailto:[email protected]>> wrote: > >> Dean, >> >> I have already done lots of work on kernel-space driver, and it’s almost get >> there. >> besides, It takes much time on my schedule. so I can not give up like this >> right now. >> All I need to know is the upper interface that applications talk to device >> driver. >> >> Thanks >> >> Nick >> >> >> >>> On Oct 22, 2014, at 2:58 AM, Dean Reece <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> Nick, >>> >>> Some devices need in-kernel drivers, but in your case it sounds like you >>> would do better with a purely user-space solution. >>> >>> Have a look at these documents to get you started: >>> • Accessing Hardware From Applications >>> <https://developer.apple.com/library/mac/documentation/DeviceDrivers/Conceptual/AccessingHardware/AH_Intro/AH_Intro.html >>> >>> <https://developer.apple.com/library/mac/documentation/DeviceDrivers/Conceptual/AccessingHardware/AH_Intro/AH_Intro.html>> >>> • USB Device Interface Guide >>> <https://developer.apple.com/library/Mac/documentation/DeviceDrivers/Conceptual/USBBook/USBIntro/USBIntro.html >>> >>> <https://developer.apple.com/library/Mac/documentation/DeviceDrivers/Conceptual/USBBook/USBIntro/USBIntro.html>> >>> • USBPrivateDataSample >>> <https://developer.apple.com/library/mac/samplecode/USBPrivateDataSample/Introduction/Intro.html >>> >>> <https://developer.apple.com/library/mac/samplecode/USBPrivateDataSample/Introduction/Intro.html>> >>> • I/O Kit Framework Reference (look for the IOUSB* objects): >>> <https://developer.apple.com/library/Mac/documentation/Darwin/Reference/IOKit/_index.html >>> >>> <https://developer.apple.com/library/Mac/documentation/Darwin/Reference/IOKit/_index.html>> >>> >>> Also, just to make sure no existing in-kernel driver is already claiming >>> your device, run "/usr/sbin/ioreg -l” while your device is attached. >>> Search the output for your device ID so you can locate the relevant entry. >>> Then make sure it is a leaf node of the registry (meaning no other driver >>> has opened it and stacked on top of it). >>> >>> Cheers, >>> - Dean >>> >>> >>>> On Oct 21, 2014, at 2:39 AM, nick <[email protected] >>>> <mailto:[email protected]>> wrote: >>>> >>>> Hi Alex, >>>> >>>> Sorry to bother you again, I didn’t get any message back since yesterday. >>>> Is there anything wrong? >>>> Thanks. >>>> >>>> Nick >>>> >>>>> On Oct 20, 2014, at 5:16 PM, Nick Yao <[email protected] >>>>> <mailto:[email protected]>> wrote: >>>>> >>>>> Dear Alex, >>>>> >>>>> From my experiences in Windows and Linux, whenever an new device is >>>>> plugged in, we always have to install the device driver, which lives >>>>> in kernel spaces. So why does not Mac need a device driver lives in >>>>> kernel space? >>>>> >>>>> Thanks >>>>> >>>>> Nick >>>>> >>>>> On 10/20/14, Nick Yao <[email protected] >>>>> <mailto:[email protected]>> wrote: >>>>>> Dear Alex, >>>>>> >>>>>> Thanks a lot. >>>>>> Our goal is relatively simple. >>>>>> We have an IC with one USB interface and two I2C interfaces. >>>>>> Our goal is to use usb to transfer data from PC to i2c devices (maybe >>>>>> a camera or e2prom), and vice versa. >>>>>> My leader has already achieved it on Windows and Linux by writing >>>>>> corresponding OS driver. >>>>>> So he thinks it should be done in the same way by writing a device >>>>>> driver on MAC. >>>>>> and that's the reason I get the task. >>>>>> >>>>>> Have I answered your question? >>>>>> >>>>>> Nick >>>>>> >>>>>> On 10/20/14, Alexander von Below <[email protected] <mailto:[email protected]>> >>>>>> wrote: >>>>>>> Hello Nick, >>>>>>> >>>>>>> in order to help you, I need to understand what your primary goal is. I >>>>>>> have >>>>>>> developed a lot of USB code, and rarely found it necessary for it to >>>>>>> live >>>>>>> in >>>>>>> Kernel space. If your code does not need to live in Kernel space, that >>>>>>> would >>>>>>> immediately solve your issue, correct? >>>>>>> >>>>>>> Alex >>>>>>> >>>>>>> >>>>>>> Am 20.10.2014 um 09:29 schrieb Nick Yao <[email protected] >>>>>>> <mailto:[email protected]>>: >>>>>>> >>>>>>>> Dear Alex >>>>>>>> add subject. >>>>>>>> My leader has assigned the driver task to me. So It's kind of an order. >>>>>>>> I just want to know the interface through which upper applications >>>>>>>> talk to device driver. >>>>>>>> I cannot find these interfaces in IOKit Classes. >>>>>>>> >>>>>>>> Thanks. >>>>>>>> >>>>>>>> Nick >>>>>>>> >>>>>>>> On 10/20/14, Alexander von Below <[email protected] >>>>>>>> <mailto:[email protected]>> wrote: >>>>>>>>> Exactly what is your goal? Why does your USB code need to live in >>>>>>>>> kernel >>>>>>>>> space in the first place? >>>>>>>>> >>>>>>>>> Alex >>>>>>>>> >>>>>>>>> Von meinem iPhone gesendet >>>>>>>>> >>>>>>>>>> Am 20.10.2014 um 09:00 schrieb Nick Yao <[email protected] >>>>>>>>>> <mailto:[email protected]>>: >>>>>>>>>> >>>>>>>>>> Hello experts, >>>>>>>>>> >>>>>>>>>> I'm new to MAC development with some linux device driver >>>>>>>>>> experience, and I am working on developing an usb device driver. >>>>>>>>>> I have already read iokit fundamental, but still very confused. >>>>>>>>>> how does kext get request form upper applications？Every base >>>>>>>>>> Class in iokit have different functions. >>>>>>>>>> It gives me the expression that iokit does't expose the same >>>>>>>>>> uniform interface to upper applications. >>>>>>>>>> Is there anything like read/write file operations functions in >>>>>>>>>> Linux? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks. >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> Do not post admin requests to the list. They will be ignored. >>>>>>>>>> Usb mailing list ([email protected] >>>>>>>>>> <mailto:[email protected]>) >>>>>>>>>> Help/Unsubscribe/Update your Subscription: >>>>>>>>>> https://lists.apple.com/mailman/options/usb/below%40mac.com >>>>>>>>>> <https://lists.apple.com/mailman/options/usb/below%40mac.com> >>>>>>>>>> >>>>>>>>>> This email sent to [email protected] <mailto:[email protected]> >>>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>> >>>> >>>> _______________________________________________ >>>> Do not post admin requests to the list. They will be ignored. >>>> Usb mailing list ([email protected] <mailto:[email protected]>) >>>> Help/Unsubscribe/Update your Subscription: >>>> https://lists.apple.com/mailman/options/usb/dean.reece%40apple.com >>>> <https://lists.apple.com/mailman/options/usb/dean.reece%40apple.com> >>>> >>>> This email sent to [email protected] <mailto:[email protected]> >> >> _______________________________________________ >> Do not post admin requests to the list. They will be ignored. >> Usb mailing list ([email protected] <mailto:[email protected]>) >> Help/Unsubscribe/Update your Subscription: >> https://lists.apple.com/mailman/options/usb/psichel%40sustworks.com >> <https://lists.apple.com/mailman/options/usb/psichel%40sustworks.com> >> >> This email sent to [email protected] <mailto:[email protected]>
_______________________________________________ Do not post admin requests to the list. They will be ignored. Usb mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/usb/archive%40mail-archive.com This email sent to [email protected]
