[Xenomai] RTDM-native mainlining - status?

[Xenomai] RTDM-native mainlining - status?

[Michael Haberler]

Q - can I assume "RTDM-native" will be part of RT-PREEMPT if/when that goes mainline?

or must I assume this will remain a Xenomai-specific way of doing things which will not be available via a torvalds kernel?


- Michael

background - since we have a portable RT application, investing into RTDM drivers makes a lot more sense if both RT kernel flavors can make use of them (in fact three if a vanilla kernel is used - which is good enough for certain applications)

Re: [Xenomai] RTDM-native mainlining - status?

[Gilles Chanteperdrix]

Michael Haberler wrote:
> Q - can I assume "RTDM-native" will be part of RT-PREEMPT if/when that
> goes mainline?
>
> or must I assume this will remain a Xenomai-specific way of doing things
> which will not be available via a torvalds kernel?

Yes, you can assume that. I do not see any way merging RTDM-native would
make sense for mainline. I mean, from their point of view, it would be
just redundant. For instance, from what I could gather, drivers based on
"OS abstraction layers" have been refused, and the people who wanted to
get them merged, asked to rewrite them using Linux driver API without the
abstraction layer.

>
>
> - Michael
>
> background - since we have a portable RT application, investing into RTDM
> drivers makes a lot more sense if both RT kernel flavors can make use of
> them (in fact three if a vanilla kernel is used - which is good enough for
> certain applications)

Well, if RTDM-native is made an out-of-tree Linux kernel module, you will
be able to compile it without applying patches, I think that would be good
enough for the usages you envision.


-- 
                    Gilles.

Re: [Xenomai] RTDM-native mainlining - status?

[Michael Haberler]

Gilles -

> Am 13.06.2015 um 01:02 schrieb Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>:
> 
> 
> Michael Haberler wrote:
>> Q - can I assume "RTDM-native" will be part of RT-PREEMPT if/when that
>> goes mainline?
>> 
>> or must I assume this will remain a Xenomai-specific way of doing things
>> which will not be available via a torvalds kernel?
> 
> Yes, you can assume that. I do not see any way merging RTDM-native would
> make sense for mainline. I mean, from their point of view, it would be
> just redundant. For instance, from what I could gather, drivers based on
> "OS abstraction layers" have been refused, and the people who wanted to
> get them merged, asked to rewrite them using Linux driver API without the
> abstraction layer.

thanks for the clarification

> 
>> 
>> 
>> - Michael
>> 
>> background - since we have a portable RT application, investing into RTDM
>> drivers makes a lot more sense if both RT kernel flavors can make use of
>> them (in fact three if a vanilla kernel is used - which is good enough for
>> certain applications)
> 
> Well, if RTDM-native is made an out-of-tree Linux kernel module, you will
> be able to compile it without applying patches, I think that would be good
> enough for the usages you envision.

that is in fact good enough, and I had not thought this being possible - since RT-PREEMPT-hardened threads are just fine for most scenarios we face, RT-hardened drivers are much more of a portability concern than threads.

While I do not feel qualified to aid development significantly, I would be very interested in exploring this route and provide feedback if it became an option.

For instance, with the external clocking driver I recently mentioned, together with hardware-triggered position sampling, latency requirements change significantly: Jitter of the thread release point is not a source of control loop noise anymore - the requirement changes from "thread must start at exactly this point in time and complete within window" to "thread must run and complete within a certain time window", which is a significant relaxation while at the same time improving results.

To cons up an example - if it were possible to reliably schedule say a Posix thread within say 200uS on a vanilla kernel that would suggest we could get away with stock kernels and still get better results than we have now. 

I hope I do not overlook some boundary condition - but assuming that building out-of-tree RTDM support is significantly less invasive and version-dependent than patching a kernel, that scheme could enormously widen the range of platforms we could deploy with good results, and at the same time lower maintenance requirements.

I guess you see the big lever this could have for us and hence our motivation - so I am all ears if there is anything going on in that direction!

Summary: "Jump!" "How high?" ;)

- Michael

> 
> 
> -- 
>                    Gilles.

Re: [Xenomai] RTDM-native mainlining - status?

[Gilles Chanteperdrix]

Michael Haberler wrote:
> I hope I do not overlook some boundary condition - but assuming that
> building out-of-tree RTDM support is significantly less invasive and
> version-dependent than patching a kernel, that scheme could enormously
> widen the range of platforms we could deploy with good results, and at the
> same time lower maintenance requirements.

No, alas a Linux driver is always version-dependent, so, the driver would
contain some wrappers to handle differences between version. But this is
not something new, everybody maintaining out-of-tree Linux kernel code has
been doing it for a very long time. We do it for Xenomai, even Linux
developers are doing it for the driver backport project.

-- 
                    Gilles.

Re: [Xenomai] RTDM-native mainlining - status?

[Michael Haberler]

> Am 13.06.2015 um 09:19 schrieb Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>:
> 
> 
> Michael Haberler wrote:
>> I hope I do not overlook some boundary condition - but assuming that
>> building out-of-tree RTDM support is significantly less invasive and
>> version-dependent than patching a kernel, that scheme could enormously
>> widen the range of platforms we could deploy with good results, and at the
>> same time lower maintenance requirements.
> 
> No, alas a Linux driver is always version-dependent, so, the driver would
> contain some wrappers to handle differences between version. But this is
> not something new, everybody maintaining out-of-tree Linux kernel code has
> been doing it for a very long time. We do it for Xenomai, even Linux
> developers are doing it for the driver backport project.

certainly, but if the problem scope changes from "patch a specific kernel version for full Xenomai support" to "maintain the API and support library for a set of out-of-tree drivers on top of a stock kernel from elsewhere" we're in a different (my guess: easier and more widely applicable) ballgame

I would really be interested in exploring this route with a simple example, like this GPIO RTDM driver, and try to make this work with say a vanilla or RT-PREEMPT kernel - if only to gauge feasibility, effort and results

what would you recommend as a starting point?

like trying to build the RTDM library code against a vanilla kernel without the rest of Xenomai? from looking over ksrc/skins/rtdm it seems to rely on primitives from the rest of the Xenomai kernel API, like locking, memory allocation, threads

Or is that "spinning out RTDM" something which is going to happen anyway?


- Michael


> 
> -- 
>                    Gilles.

Re: [Xenomai] RTDM-native mainlining - status?

[Gilles Chanteperdrix]

Michael Haberler wrote:
>
>> Am 13.06.2015 um 09:19 schrieb Gilles Chanteperdrix
>> <gilles.chanteperdrix@xenomai.org>:
>>
>>
>> Michael Haberler wrote:
>>> I hope I do not overlook some boundary condition - but assuming that
>>> building out-of-tree RTDM support is significantly less invasive and
>>> version-dependent than patching a kernel, that scheme could enormously
>>> widen the range of platforms we could deploy with good results, and at
>>> the
>>> same time lower maintenance requirements.
>>
>> No, alas a Linux driver is always version-dependent, so, the driver
>> would
>> contain some wrappers to handle differences between version. But this is
>> not something new, everybody maintaining out-of-tree Linux kernel code
>> has
>> been doing it for a very long time. We do it for Xenomai, even Linux
>> developers are doing it for the driver backport project.
>
> certainly, but if the problem scope changes from "patch a specific kernel
> version for full Xenomai support" to "maintain the API and support library
> for a set of out-of-tree drivers on top of a stock kernel from elsewhere"
> we're in a different (my guess: easier and more widely applicable)
> ballgame

There should not be a need for a support library, since RTDM uses the
usual driver API open, read, write, ioctl, I would expect an RTDM native
driver to work with the plain Linux version of these calls.

>
> I would really be interested in exploring this route with a simple
> example, like this GPIO RTDM driver, and try to make this work with say a
> vanilla or RT-PREEMPT kernel - if only to gauge feasibility, effort and
> results
>
> what would you recommend as a starting point?

Well, RTDM native is not part of Xenomai (yet), so, the first step would
be to to try and compile it. The last commits in the git date back from
2007, so, some adaptation will be needed to get it running with the latest
kernels.

https://git.xenomai.org/rtdm-native.git/

-- 
                                            Gilles.
https://click-hack.org

Re: [Xenomai] RTDM-native mainlining - status?

[Philippe Gerum]

On 06/14/2015 10:46 AM, Gilles Chanteperdrix wrote:
> 
> Michael Haberler wrote:
>>
>>> Am 13.06.2015 um 09:19 schrieb Gilles Chanteperdrix
>>> <gilles.chanteperdrix@xenomai.org>:
>>>
>>>
>>> Michael Haberler wrote:
>>>> I hope I do not overlook some boundary condition - but assuming that
>>>> building out-of-tree RTDM support is significantly less invasive and
>>>> version-dependent than patching a kernel, that scheme could enormously
>>>> widen the range of platforms we could deploy with good results, and at
>>>> the
>>>> same time lower maintenance requirements.
>>>
>>> No, alas a Linux driver is always version-dependent, so, the driver
>>> would
>>> contain some wrappers to handle differences between version. But this is
>>> not something new, everybody maintaining out-of-tree Linux kernel code
>>> has
>>> been doing it for a very long time. We do it for Xenomai, even Linux
>>> developers are doing it for the driver backport project.
>>
>> certainly, but if the problem scope changes from "patch a specific kernel
>> version for full Xenomai support" to "maintain the API and support library
>> for a set of out-of-tree drivers on top of a stock kernel from elsewhere"
>> we're in a different (my guess: easier and more widely applicable)
>> ballgame
> 
> There should not be a need for a support library, since RTDM uses the
> usual driver API open, read, write, ioctl, I would expect an RTDM native
> driver to work with the plain Linux version of these calls.
> 
>>
>> I would really be interested in exploring this route with a simple
>> example, like this GPIO RTDM driver, and try to make this work with say a
>> vanilla or RT-PREEMPT kernel - if only to gauge feasibility, effort and
>> results
>>
>> what would you recommend as a starting point?
> 
> Well, RTDM native is not part of Xenomai (yet), so, the first step would
> be to to try and compile it. The last commits in the git date back from
> 2007, so, some adaptation will be needed to get it running with the latest
> kernels.
> 
> https://git.xenomai.org/rtdm-native.git/
> 

And changes to the RTDM API brought in by the transition to xenomai 3 too.


-- 
Philippe.

Re: [Xenomai] RTDM-native mainlining - status?

[Gilles Chanteperdrix]

Philippe Gerum wrote:
> On 06/14/2015 10:46 AM, Gilles Chanteperdrix wrote:
>>
>> Michael Haberler wrote:
>>>
>>>> Am 13.06.2015 um 09:19 schrieb Gilles Chanteperdrix
>>>> <gilles.chanteperdrix@xenomai.org>:
>>>>
>>>>
>>>> Michael Haberler wrote:
>>>>> I hope I do not overlook some boundary condition - but assuming that
>>>>> building out-of-tree RTDM support is significantly less invasive and
>>>>> version-dependent than patching a kernel, that scheme could
>>>>> enormously
>>>>> widen the range of platforms we could deploy with good results, and
>>>>> at
>>>>> the
>>>>> same time lower maintenance requirements.
>>>>
>>>> No, alas a Linux driver is always version-dependent, so, the driver
>>>> would
>>>> contain some wrappers to handle differences between version. But this
>>>> is
>>>> not something new, everybody maintaining out-of-tree Linux kernel code
>>>> has
>>>> been doing it for a very long time. We do it for Xenomai, even Linux
>>>> developers are doing it for the driver backport project.
>>>
>>> certainly, but if the problem scope changes from "patch a specific
>>> kernel
>>> version for full Xenomai support" to "maintain the API and support
>>> library
>>> for a set of out-of-tree drivers on top of a stock kernel from
>>> elsewhere"
>>> we're in a different (my guess: easier and more widely applicable)
>>> ballgame
>>
>> There should not be a need for a support library, since RTDM uses the
>> usual driver API open, read, write, ioctl, I would expect an RTDM native
>> driver to work with the plain Linux version of these calls.
>>
>>>
>>> I would really be interested in exploring this route with a simple
>>> example, like this GPIO RTDM driver, and try to make this work with say
>>> a
>>> vanilla or RT-PREEMPT kernel - if only to gauge feasibility, effort and
>>> results
>>>
>>> what would you recommend as a starting point?
>>
>> Well, RTDM native is not part of Xenomai (yet), so, the first step would
>> be to to try and compile it. The last commits in the git date back from
>> 2007, so, some adaptation will be needed to get it running with the
>> latest
>> kernels.
>>
>> https://git.xenomai.org/rtdm-native.git/
>>
>
> And changes to the RTDM API brought in by the transition to xenomai 3 too.
>
>

Well, for a test run, as a first step, I guess Michael can ignore these
changes. But ultimately, I agree, this would have to be tackled.

-- 
                                            Gilles.
https://click-hack.org

Re: [Xenomai] RTDM-native mainlining - status?

[Michael Haberler]

> Am 14.06.2015 um 10:46 schrieb Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>:
> 
> 
> Michael Haberler wrote:
>> 
>>> Am 13.06.2015 um 09:19 schrieb Gilles Chanteperdrix
>>> <gilles.chanteperdrix@xenomai.org>:
>>> 
>>> 
>>> Michael Haberler wrote:
>>>> I hope I do not overlook some boundary condition - but assuming that
>>>> building out-of-tree RTDM support is significantly less invasive and
>>>> version-dependent than patching a kernel, that scheme could enormously
>>>> widen the range of platforms we could deploy with good results, and at
>>>> the
>>>> same time lower maintenance requirements.
>>> 
>>> No, alas a Linux driver is always version-dependent, so, the driver
>>> would
>>> contain some wrappers to handle differences between version. But this is
>>> not something new, everybody maintaining out-of-tree Linux kernel code
>>> has
>>> been doing it for a very long time. We do it for Xenomai, even Linux
>>> developers are doing it for the driver backport project.
>> 
>> certainly, but if the problem scope changes from "patch a specific kernel
>> version for full Xenomai support" to "maintain the API and support library
>> for a set of out-of-tree drivers on top of a stock kernel from elsewhere"
>> we're in a different (my guess: easier and more widely applicable)
>> ballgame
> 
> There should not be a need for a support library, since RTDM uses the
> usual driver API open, read, write, ioctl, I would expect an RTDM native
> driver to work with the plain Linux version of these calls.
> 
>> 
>> I would really be interested in exploring this route with a simple
>> example, like this GPIO RTDM driver, and try to make this work with say a
>> vanilla or RT-PREEMPT kernel - if only to gauge feasibility, effort and
>> results
>> 
>> what would you recommend as a starting point?
> 
> Well, RTDM native is not part of Xenomai (yet), so, the first step would
> be to to try and compile it. The last commits in the git date back from
> 2007, so, some adaptation will be needed to get it running with the latest
> kernels.
> 
> https://git.xenomai.org/rtdm-native.git/

sounds reasonable, I will give it a try an report.

Any early advice on brushing up this tree would be particularly welcome!

- Michael


> 
> -- 
>                                            Gilles.
> https://click-hack.org

Re: [Xenomai] RTDM-native mainlining - status?

[Gilles Chanteperdrix]

Michael Haberler wrote:
>
>> Am 14.06.2015 um 10:46 schrieb Gilles Chanteperdrix
>> <gilles.chanteperdrix@xenomai.org>:
>>
>>
>> Michael Haberler wrote:
>>>
>>>> Am 13.06.2015 um 09:19 schrieb Gilles Chanteperdrix
>>>> <gilles.chanteperdrix@xenomai.org>:
>>>>
>>>>
>>>> Michael Haberler wrote:
>>>>> I hope I do not overlook some boundary condition - but assuming that
>>>>> building out-of-tree RTDM support is significantly less invasive and
>>>>> version-dependent than patching a kernel, that scheme could
>>>>> enormously
>>>>> widen the range of platforms we could deploy with good results, and
>>>>> at
>>>>> the
>>>>> same time lower maintenance requirements.
>>>>
>>>> No, alas a Linux driver is always version-dependent, so, the driver
>>>> would
>>>> contain some wrappers to handle differences between version. But this
>>>> is
>>>> not something new, everybody maintaining out-of-tree Linux kernel code
>>>> has
>>>> been doing it for a very long time. We do it for Xenomai, even Linux
>>>> developers are doing it for the driver backport project.
>>>
>>> certainly, but if the problem scope changes from "patch a specific
>>> kernel
>>> version for full Xenomai support" to "maintain the API and support
>>> library
>>> for a set of out-of-tree drivers on top of a stock kernel from
>>> elsewhere"
>>> we're in a different (my guess: easier and more widely applicable)
>>> ballgame
>>
>> There should not be a need for a support library, since RTDM uses the
>> usual driver API open, read, write, ioctl, I would expect an RTDM native
>> driver to work with the plain Linux version of these calls.
>>
>>>
>>> I would really be interested in exploring this route with a simple
>>> example, like this GPIO RTDM driver, and try to make this work with say
>>> a
>>> vanilla or RT-PREEMPT kernel - if only to gauge feasibility, effort and
>>> results
>>>
>>> what would you recommend as a starting point?
>>
>> Well, RTDM native is not part of Xenomai (yet), so, the first step would
>> be to to try and compile it. The last commits in the git date back from
>> 2007, so, some adaptation will be needed to get it running with the
>> latest
>> kernels.
>>
>> https://git.xenomai.org/rtdm-native.git/
>
> sounds reasonable, I will give it a try an report.
>
> Any early advice on brushing up this tree would be particularly welcome!

Well, you con try following the build instructions and fix everything that
stops the compilation.

Some information on how to build it may be found here:
https://www.osadl.org/RTDM-native.howto-rtdm-native.0.html
and here:
https://git.xenomai.org/rtdm-native.git/plain/README.rtdm-native

-- 
                                            Gilles.
https://click-hack.org