On 2011-06-06 00:29, Nicholas Mc Guire wrote: > On Sun, 05 Jun 2011, Jan Kiszka wrote: > >> On 2011-06-05 11:28, Nicholas Mc Guire wrote: >>> On Sun, 05 Jun 2011, Armin Steinhoff wrote: >>> >>>> Nicholas Mc Guire wrote: >>>>> On Sat, 04 Jun 2011, Monica Puig-Pey wrote: >>>>> >>>>>> Hello, >>>>>> I'm studying how to develop drivers in a real time OS and how do they >>>>>> work. I'm using Ubuntu 10.04 with the 2.6.31-11-rt patch installed. >>>>>> I would like to know the priority when executing open(), read(), write() >>>>>> and close() operations. >>>>>> In my example the thread which is using the driver runs with 10 RTPRIO, >>>>>> but I don't know what happens in kernel context with the priority when >>>>>> running the I/O operations. >>>>>> Thank you for your help, I don't know where to learn about this. >>>>>> >>>>> [] >>>>> Also when using bottom half mechanisms you need to take into account the >>>>> priority of the kernel thread that manages the defered work items, so >>>>> rt-drivers may have a different structure than normal drivers. >>>> >>>> That's the reason why I prefer UIO based user space drivers ! >>>> >>> ...and how to resolve DMA ? if DMA were resolved cleanly I would agree. >> >> Regarding that limitation, there is some hope: "next-generation" UIO is >> called VFIO. Useful for exclusively assigning virtual PCI functions of >> network adapters etc. to user space stacks or hypervisors like QEMU/KVM >> (for device pass-through). But it's not mainline yet. And it obviously >> requires an IOMMU. >> >> But the key point remains: "exclusively". Anything else cannot be >> modeled efficiently via UIO or VFIO. >> > for many RT apps that is an acceptable limit - in fact sometimes a requirement - having dynamic access and handling this at runtime is not necessarily an advantage for rt. Giving guarantees on timing for non-exclusive access in the general case would probably need to be based on a priority access model any way (i.e. running non-RT network traffic on a RT-link as "rt-idle" bandwidth usage - but full shared access at runtime would be very hard, if not impossible, to model at the device interface level without breaking RT properties. So I think its legitimate to keep it out of the device all together and let the user apps have a non-rt fight about access... There are good examples - in the RT domain - for both models. Sharing a device does not necessarily mean making things dynamic or even unpredictable. > > Any pointers to VFIO ? E.g. http://thread.gmane.org/gmane.linux.kernel.pci/10088 Jan
Attachment:
signature.asc
Description: OpenPGP digital signature
