* [Xenomai] RTDM-native mainlining - status? @ 2015-06-12 21:41 Michael Haberler 2015-06-12 23:02 ` Gilles Chanteperdrix 0 siblings, 1 reply; 10+ messages in thread From: Michael Haberler @ 2015-06-12 21:41 UTC (permalink / raw) To: xenomai 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) ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Xenomai] RTDM-native mainlining - status? 2015-06-12 21:41 [Xenomai] RTDM-native mainlining - status? Michael Haberler @ 2015-06-12 23:02 ` Gilles Chanteperdrix 2015-06-13 4:48 ` Michael Haberler 0 siblings, 1 reply; 10+ messages in thread From: Gilles Chanteperdrix @ 2015-06-12 23:02 UTC (permalink / raw) To: Michael Haberler; +Cc: xenomai 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. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Xenomai] RTDM-native mainlining - status? 2015-06-12 23:02 ` Gilles Chanteperdrix @ 2015-06-13 4:48 ` Michael Haberler 2015-06-13 7:19 ` Gilles Chanteperdrix 0 siblings, 1 reply; 10+ messages in thread From: Michael Haberler @ 2015-06-13 4:48 UTC (permalink / raw) To: Gilles Chanteperdrix; +Cc: xenomai 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. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Xenomai] RTDM-native mainlining - status? 2015-06-13 4:48 ` Michael Haberler @ 2015-06-13 7:19 ` Gilles Chanteperdrix 2015-06-14 7:31 ` Michael Haberler 0 siblings, 1 reply; 10+ messages in thread From: Gilles Chanteperdrix @ 2015-06-13 7:19 UTC (permalink / raw) To: Michael Haberler; +Cc: xenomai 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. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Xenomai] RTDM-native mainlining - status? 2015-06-13 7:19 ` Gilles Chanteperdrix @ 2015-06-14 7:31 ` Michael Haberler 2015-06-14 8:46 ` Gilles Chanteperdrix 0 siblings, 1 reply; 10+ messages in thread From: Michael Haberler @ 2015-06-14 7:31 UTC (permalink / raw) To: Gilles Chanteperdrix; +Cc: xenomai > 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. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Xenomai] RTDM-native mainlining - status? 2015-06-14 7:31 ` Michael Haberler @ 2015-06-14 8:46 ` Gilles Chanteperdrix 2015-06-14 8:53 ` Philippe Gerum 2015-06-14 11:37 ` Michael Haberler 0 siblings, 2 replies; 10+ messages in thread From: Gilles Chanteperdrix @ 2015-06-14 8:46 UTC (permalink / raw) To: Michael Haberler; +Cc: xenomai 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Xenomai] RTDM-native mainlining - status? 2015-06-14 8:46 ` Gilles Chanteperdrix @ 2015-06-14 8:53 ` Philippe Gerum 2015-06-14 8:55 ` Gilles Chanteperdrix 2015-06-14 11:37 ` Michael Haberler 1 sibling, 1 reply; 10+ messages in thread From: Philippe Gerum @ 2015-06-14 8:53 UTC (permalink / raw) To: Gilles Chanteperdrix, Michael Haberler; +Cc: xenomai 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. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Xenomai] RTDM-native mainlining - status? 2015-06-14 8:53 ` Philippe Gerum @ 2015-06-14 8:55 ` Gilles Chanteperdrix 0 siblings, 0 replies; 10+ messages in thread From: Gilles Chanteperdrix @ 2015-06-14 8:55 UTC (permalink / raw) To: Philippe Gerum; +Cc: xenomai 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Xenomai] RTDM-native mainlining - status? 2015-06-14 8:46 ` Gilles Chanteperdrix 2015-06-14 8:53 ` Philippe Gerum @ 2015-06-14 11:37 ` Michael Haberler 2015-06-14 11:43 ` Gilles Chanteperdrix 1 sibling, 1 reply; 10+ messages in thread From: Michael Haberler @ 2015-06-14 11:37 UTC (permalink / raw) To: Gilles Chanteperdrix; +Cc: xenomai > 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Xenomai] RTDM-native mainlining - status? 2015-06-14 11:37 ` Michael Haberler @ 2015-06-14 11:43 ` Gilles Chanteperdrix 0 siblings, 0 replies; 10+ messages in thread From: Gilles Chanteperdrix @ 2015-06-14 11:43 UTC (permalink / raw) To: Michael Haberler; +Cc: xenomai 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2015-06-14 11:43 UTC | newest] Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2015-06-12 21:41 [Xenomai] RTDM-native mainlining - status? Michael Haberler 2015-06-12 23:02 ` Gilles Chanteperdrix 2015-06-13 4:48 ` Michael Haberler 2015-06-13 7:19 ` Gilles Chanteperdrix 2015-06-14 7:31 ` Michael Haberler 2015-06-14 8:46 ` Gilles Chanteperdrix 2015-06-14 8:53 ` Philippe Gerum 2015-06-14 8:55 ` Gilles Chanteperdrix 2015-06-14 11:37 ` Michael Haberler 2015-06-14 11:43 ` Gilles Chanteperdrix
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.