On Friday 09 October 2009 10:04:07 you wrote:
> On Fri, 2009-10-09 at 00:00 +0200, Alexis Berlemont wrote:
> > If I understand well, I have gone too far too soon; the idea should be
> > to keep the current framework as it is for 2.5.
> >
> > However, my former mail was not a definitive plan. The first goal was
> > to share ideas. So, do not worry too much. :)
> Maintaining two different frameworks for the same purpose won't fly. I'm
> worried because the future of Comedi/RTDM as merged in the 2.5 tree just
> became unclear - to say the least - as from you introduced the idea of
> changing its architecture.
> Your potential user-base has to know whether using the current
> Comedi/RTDM framework for new designs based on 2.5.x will still make
> sense in six months from now, when Analogy eventually emerges.
> In other words, is there any upgrade path planned? What would this
> entail?
> Would one have to rewrite custom DAQ drivers to port them from
> Comedi/RTDM to Analogy, or could rely on a some compat wrapper for
> supporting legacy Comedi/RTDM Driver-Kernel interface on top of the
> Analogy core?
> Would that new architecture bring changes in the applications, i.e. what
> about the impact of such changes on the way userland interfaces to the
> acquisition framework and/or its drivers?
> I would have thought that Comedi/RTDM in the 2.5 tree would become
> Analogy as is, and evolve over time in a careful manner so that people
> always have a reasonable upgrade path. But now, I'm unsure whether this
> is going to be the case, or we would end up with two different
> frameworks. So, what is the _exact_ plan?

Ok. I will try to give my rough ideas.

Comedi / RTDM is facing many questions:

1) Peter Soetens, a Comedi user, once told us that the APIs (kernel and user) 
divergences with upstream were going to bring many troubles. maintaining 
tasks, difficulties to lure orginal Comedi users, etc. 
-> Should I ignore what was told that day or should I find a way to satisfy 
the main request which was a smooth transition between Comedi upstream and 

2) People developing with Comedilib do not seem to be the same guys working on 
the drivers. So, even if common users agreed with porting their applications 
on the new library interface, they could not integrate their needed drivers 
into the Xenomai drivers set. If you want a clue, have a look at the Comedi 
mailing list, there are plenty of mails starting with "Is there a Comedi 
driver for ..."
-> Should I still be confident that there will be contributions of drivers ?

3) The Comedi framework is too different from other well-known frameworks. 
However, I consider that audio and multimedia cards are not different from 
acquistion devices. All of them can be divided into subdevices or components 
but neither v4l2 nor alsa did implement subdevices configurations like Comedi 
did. v4l2 and alsa drivers are working both with devices fops-like structures 
but Comedi is working with per subdevices callbacks far from the Linux driver 
model. Etc.
-> Should I leave our framework like it is ? Are we sure that the fact the 
original Comedi framework is slowly losing contributions is a coincidence ?

4) I tried to exchange with the original Comedi developers (even on the LKML). 
Nothing emerged from my mails (except that the Comedi maintainers told me to 
send my contributions to Greg KH and Greg KH told me to send my contributions 
to the Comedi maintainers).
-> Do you have any sign that someone is working on the Comedi core ?

5) So far, Comedi/RTDM has only one driver which deserves interest: the 
National Instruments NI PCIMIO. And it took quite a long time to make it work 
by myself and I still have some work to do on it. A user still has some 
troubles with his specific PPC host board. We are striving to find the bug.
-> Do we really have a significant user base for Comedi/RTDM ?

These questions led me to the conclusions I shared in the ML:

1) I have a true worrisome problem: Comedi/RTDM is not living because it lacks 
users on one side and contributors on the other side. The machine is not 

2) It is still time to make it overtake by assessing what went wrong. There 
are Comedi users but they cannot use our framework because of the lack of 

3) The driver is the key. So, the kernel side is the key. We have to improve 
it in two ways:
- (almost) seamlessly recover the original Comedi drivers;
- get some feedback on the best way to implement such a framework and make it 
flexible, because, right now, I am pretty convinced I am in the middle of what 
people call "the midlayer mistake".

 So, I was not at the "plan" level yet when I sent the first mail of this 
thread. I am still in the "design" phase just in case a redesign needs to be 


Xenomai-core mailing list

Reply via email to