On Mon, 2009-10-12 at 00:51 +0200, Alexis Berlemont wrote:
> 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
You don't seem to get the point yet: I'm in no way arguing about which
technical direction you should head your project to, and I have no issue
with your technical analysis.
The issue I have is with your project management: Comedi/RTDM is
currently part of the Xenomai tree, scheduled for 2.5 for more than a
year, and you are now in the "back to the future" mode, asking people
their feedback about major changes your would like to see in your
infrastructure, at a moment when one may have expected it to be stable.
This won't fly.
> 2) People developing with Comedilib do not seem to be the same guys working
> 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 ?
If your point is about mentioning that OS implementers should provide a
stable framework to build over, for others to implement drivers for
their own devices, well, ok, I was vaguely aware of this; thanks for the
heads up anyway. Problem is that you have just shot yourself in the
foot, by tagging Comedi/RTDM has unstable and unusable in the context of
If you tell people that you are about to rewrite the kernel side
significantly before they had a chance to get their feet wet with it and
consider basing their future work on it, you won't get any contribution,
obviously. They will wait for your own dust to settle. Or they may not
wait at all, and walk away.
At any rate, deprecating the current Comedi/RTDM architecture now, only
a few weeks before Xenomai 2.5 is rolled out, has pretty bad timing, to
say the least.
> 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 ?
Nobody tells you to freeze your work, and/or not to think of a better
approach. But you need to do a better job of explaining how your
potential users will get their upgrade path to your new architecture.
And you did not. This is what having a plan means, not just telling
people that you are not happy with the framework, and asking them how
they would want it to be overhauled. Most of those who might want to
base their work on Comedi/RTDM today would NOT want you to make the
codebase a moving target.
So, the plan I was talking about could be something along these lines:
- we have such issues with Comedi/RTDM (fair enough)
- it is suggested to fix them later this way in Analogy
- we could provide an upgrade path from Comedi/RTDM (drivers and APIs)
to Analogy that way...
- there is no reasonable upgrade path, so well, we would have to scrap
Comedi/RTDM from the Xenomai 2.5 tree, because this makes no sense to
issue a temporary framework for writing long-lived code such as drivers.
Btw, AFAICT, it does not make much sense to keep Comedi/RTDM as your
project name within Xenomai 2.5; it should have been moved to Analogy
already. You may change your underlying architecture at some point
without changing the name of your project, and keeping "Comedi" in the
naming seems confusing, since there is no way it could be merged with
the original project anyway.
> 4) I tried to exchange with the original Comedi developers (even on the
> 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 ?
That is not the point. There is a problem with Comedi, fair enough, but
let's not import it to Xenomai. Unless I'm mistaken, that particular
issue has been solved by switching gear to Analogy, so let's not rehash
the reasons why it has been done, those are pretty obvious. Get away
with this and move on.
> 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 ?
Nobody can force a user base to exist, but you could make it simpler for
it to emerge, that is my point. By introducing uncertainty regarding
your architecture a few weeks before the first release of your project
in Xenomai, you are confusing people. This won't help having them write
drivers for it.
> 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
> users on one side and contributors on the other side. The machine is not
Users are expected to be your contributors when it comes to drivers,
most of the time if not always. Tell them why they should be confident
that building over Comedi/RTDM now is (still) a safe bet. That is the
"plan" I referred to.
> 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
Typical catch #22. You assume the framework has to be perfect for having
drivers contributed, but the framework can't be perfect without drivers
available in the first place. -EDEADLOCK (since you can't provide those
Instead of rehashing "we ought to be able to reuse Comedi drivers",
maybe it's time to walk the walk, and make this possible over
Comedi/RTDM. Any adaptation layer to do this would have to be long-lived
and well maintained, this could be a reasonable incentive for people to
base their work on Comedi/RTDM now. This only makes sense if that layer
can shield them from most changes in the next architecture though.
> 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
> 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
You already answered the question whether such redesign is required or
not, right? Otherwise, what are we talking about?
The design phase must be part of a more general course of action. I
won't argue about technicalities regarding how your acquisition system
should look like, you know better. But I'm asking you whether
Comedi/RTDM (or Analogy 1.0, whatever) - as it is now in the Xenomai 2.5
tree - still makes sense, with respect to what changing its architecture
If so, will some layer be provided to migrate drivers from Analogy 1.0
to 2.0, i.e. when the major architecture changes will have taken place?
> Xenomai-core mailing list
Xenomai-core mailing list