Re: I/O operations priority in RTOS

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

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

On 2011-06-06 09:41, Armin Steinhoff wrote:
> 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.
> 
> I found in a posting about VFIO that  " ioctls are used for all the
> basic interactions"  ... that means VFIO works with a lot of context
> switches.

That mostly refers to configuring VFIO devices (just check the code when
in doubt).

One exception is EIO. VFIO works generically, without any device
specific kernel stubs. So legacy interrupts are first generically
masked, then reported to user space to do the device specific handling,
and then ack'ed by user space via an IOCTL to remove the mask again. But
that only matters for legacy INTx, not for MSI[-X].

> That's not the case with UIO.  So why should VFIO be a mainline approach
> or next generation UIO at all?

Because it is promising to solve the DMA challenge without totally
ignoring security (in contrast to uio-dma). And because it already has
two major use cases (high-speed user space networking and virtualization).

Conceptually, VFIO should be able to cover most of those scenarios that
UIO currently addresses. But UIO is kernel ABI and wouldn't go away even
if VFIO was able to completely replace it.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 259 bytes --]