On Tuesday 17 February 2009 10:41:10 Jan Kiszka wrote:
> Peter Soetens wrote:
> > These are the facts we observed:
> >
> > * The Xenomai/Comedi port breaks the complete Comedi API, user space
> > *and* kernel space. (We thought/assumed that only the user space
> > interface would go over RTDM and that once that was done, the kernel
> > modules could be almost copy/pasted into the new framework.)
>
> Maybe you have a list of the major differences. Then please share it so
> that the motivation can be discussed here and maybe clarified (it's a
> blurred topic for me as well).
Damn. I should have posted back then :-) Our main lead was the Doxygen pages,
from which we went on to see how things were done in code. Unfortunately (?),
I'm not a Comedi developer, I twiddled only with one Comedi driver. Once. I
can't really compare to the bone. But what was clear immediately was that both
user API and kernel API were different.
User ('Library') API was cleaned up and streamlined, we could live with that
for new applications. I'm sure there are still issues, but they'll only come
up once people start using this branch. I like the separation between a low
level 'instruction' api and a high level 'function' api. Something upstream
comedi mixes to much.
For kernel ('Driver') API, a new data transfer mechanism is in place, which
requires the 'porting' of all drivers. I genuinely can't estimate how
drastically this changes existing drivers, but the API is quite huge and works
with the 'inversion of control' paradigm: Each driver must implement a series
of hooks, and the Comedi/RTDM framework will call these when necessary.
Another fact I shouldn't have omitted:
* The Xenomai/Comedi layer is very well documented and allows anyone to learn
from it, even the upstream maintainers.
* Seen from my little device driver knowledge, the technical implementation
looks ok for synchronous/asynchronous reading and writing. Memory mapped IO is
not available, it seems, and the classical comedi_config, inp,outp,... family
isn't complete yet either.
>
> > * The Xenomai/Comedi port is not supported by 'upstream' (what you call
> > 'legacy'). It's not discussed on their ML, they don't send in patches or
> > feedback.
> > * There aren't any (?) device drivers ported to the Xenomai/Comedi
> > project (public trunk)
> >
> > This is what we concluded:
> >
> > * Xenomai/Comedi has no future as long as it ignores (or is ignored by)
> > upstream. Even after a port of a device driver, pulling fixes from
> > upstream will be hard due to the changed kernel API.
>
> IMHO, that heavily depends on the use cases both projects are able to
> cover. If there are major RT design issues upstream that this variant
> solves, then people may be willing to live with the differences
> (including a smaller driver set downstream). It wouldn't be the first time.
I see the short term profits as well. I'm fearing a maintenance nightmare in
the long term.
>
> > * As GKH puts it: all device drivers belong in the Linux kernel. Upstream
> > is doing this right now, which makes acceptance of Xenomai/Comedi
> > unlikely, which makes its life expectations uncertain.
>
> I don't think anyone expect to see the RT drivers here and around in
> mainline Linux in the foreseeable future. That's not the primary goal.
> At the same time, it's still unclear how serious mainline is about RT
> redesigns of existing drivers or frameworks. And I recall from earlier
> threads on the comedi list that at least the current comedi maintainers
> consider RT use at best as a niche and not an important scenario.
That's what I recall as well. But I was wondering how the RT issue was
overtaken by reality: running plain comedi in a preemptible kernel.
>
> > * We're now actually considering Preempt/RT as the kernel to use in
> > combination with the original Comedi. We might be stupid, but then again,
> > it might just work.
> > * We believe the name Xenomai/Comedi is strongly misleading. It suggests
> > a painless transition path, but it's a completely different software
> > project, different interfaces, different maintainer(s ?).
>
> I agree. If reasons for significant differences in the user API remain,
> then a different name would be appropriate, too. Looks like this is not
> Socket-CAN vs. RT-Socket-CAN here?
Most functions and structs have been renamed and have modified arguments,
although there could be a 1:1 mapping (1 old function -> 1 new function).
I believe Alexis can defend his design better than anyone else, and it's not
the design I wanted to tackle. It's how he plans to maintain it.
Peter
--
Peter Soetens -- FMTC -- <http://www.fmtc.be>
_______________________________________________
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
