Re: I/O operations priority in RTOS

[Nicholas Mc Guire <der.herr@hofr.at>]

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...

Any pointers to VFIO ?

hofrat