Re: I/O operations priority in RTOS

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

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

On 2011-06-06 00:39, Armin Steinhoff wrote:
> Jan Kiszka wrote:
>> On 2011-06-05 10:46, 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 !
>> ...which are forced to use threaded IRQs over -rt as well.
> 
> What's wrong with that approach? You have an ISR in the kernel module
> and an interrupt thread at user space.

Under -rt, you have an ISR kernel thread in addition to whatever threads
you create in user space. I thought your point about UIO was avoiding
the need to worry about priorities, but maybe I misunderstood this.

> Seem OK for me since a long time with QNX :)
>> Taking threaded IRQs out of the picture, bottom-half mechanisms usually
>> come into play when dispatch workload that cannot be assigned to a
>> specific user context is significant. But then UIO is the wrong approach
>> anyway as it doesn't match well the requirements of multi-user device
>> interfaces.
>   Support of multi-user device interfaces at user space is just a design
> issue ... I use this concept since a long time with QNX :)

There is always a tradeoff. IIRC, even QNX is no pure microkernel
anymore when it comes to performance sensitive services that are shared
between many processes. And Linux is no pure monolithic kernel anymore
when it comes to easily implementing user space file systems or
exclusively assigning devices to processes.

Jan


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