Jonathan Haws wrote: >>>>> I am writing a driver that needs to wake up a user space thread >> on >>>> a >>>>> hardware interrupt. I am reading about the Xenomai APIs >>>> semaphores >>>>> and want to know if I create a semaphore in my kernel module >> with >>>> a >>>>> given name using rt_sem_create, can I call rt_sem_bind in user >>>> space >>>>> to bind to that same semaphore? >>>>> >>>>> I am sure hoping the answer is yes! >>>> The answer is yes, but... >>>> this programming model is deprecated. You should be implementing >> a >>>> driver using the RTDM API, as you would do with Linux. >>> The driver is a really dumb driver - all it really does is setup >> pointers to the PCI BARs and installs the interrupt. I provide an >> mmap routine to map the BARs to user space so I can control the >> device from there. >>> Would this still be necessary to use the RTDM API? I guess to >> install the interrupt, but there really is not anything else the >> driver does. >> >> Abstraction is the primary job of a driver. Pushing things to user >> space >> quickly blurs the boundaries and ends up in tricky to maintain blob >> on >> the long term. > > That is what I am trying to do, abstract away the details of interfacing with > the hardware, however the user does need to have access to the BARs to be > able to configure the device at runtime in an efficient manner. IOCTL calls > are too slow for our application. We do not need this driver to be very > portable either - this is custom built hardware specific to our application > only.
No one says that every transfered byte need to be encapsulated into an IOCTL. There can be clever device models that only issue driver calls when the caller needs to wait on an event. Of course, this also depends on the hardware's capabilities. > >>> I was also reading the RTDM API and am confused about the >> rtdm_iomap_to_user() function - is that to be called from my user >> space application and it will then call the mmap routine that I have >> in place for my driver? >> >> It's part of the function set that a driver can use, not an >> application. >> This function will do all the work required to let some I/O memory >> show >> up in the user space's memory range. > > So, how would it be used? Does the driver call this routine with some > specific memory in mind and it returns a user space pointer? If so, how does > that pointer get passed back to user space? It's typically in a driver's IOCTL handler that processes a user request to set up the memory mapping for a specific device. So you pass the pointer back and forth as an argument to this IOCTL. For details on the service just look at its doc: http://www.xenomai.org/documentation/xenomai-2.4/html/api/group__util.html#gd3cd99bd0049763a4bf4c41edb249785 Jan
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Xenomai-help mailing list [email protected] https://mail.gna.org/listinfo/xenomai-help
