Re: I/O operations priority in RTOS

[Jan Kiszka <jan.kiszka@web.de>]

[-- Attachment #1: Type: text/plain, Size: 2610 bytes --]

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 #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 259 bytes --]