On Monday 12 October 2009 11:30:11 you wrote:
> 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 Comedi/RTDM.
>
> 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 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 ?
>
> 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
> developing drivers.
>
> 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
> then,
>
> - we could provide an upgrade path from Comedi/RTDM (drivers and APIs)
> to Analogy that way...
> OR,
> - 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
> > 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 ?
>
> 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
> > lacks users on one side and contributors on the other side. The machine
> > is not running.
>
> 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 drivers.
>
> 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
> drivers yourself).
>
> 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 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 done.
>
> You already answered the question whether such redesign is required or
> not, right?
Clearly no. I would have been happy having technical talks about how people
would see the design. I did not send the mail to impose a solution but to
receive critics and to find out the best way. My opinion was just a starting
point.
> Otherwise, what are we talking about?
No need to say more.
I think I clearly understood your issues. I kept on focusing on the technical
aspects leaving the plan unclear, which is not the right path.
I also made a mistake by saying that I would create an analogy branch in my
git repository for a potential redesign. That did not leave place for the
current design.
My former mails should have dealt with what Analogy _was_ instead of what
Analogy _would_ become.
So here is what I propose:
I like your idea "analogy 1 and analogy 2" but let's focus on 1.x series, the
stable one (the experimental flag will vanish in Kconfig).
-> Goal: ensure a smooth transition between Comedi and Analogy.
-> So far, the transition with Comedi is not good enough. So after the
2.5 Xenomai release, I will work on improving this issue; along with the
Analogy driver API, a Comedi driver API will be available in some intermediate
layer.
-> The calibration feature is still missing. I will work on that point.
Then Analogy users would have a stable base on which acquisition applications
could evolve.
So, to sum-up:
In Xenomai 2.5: Analogy 1.0 :
-> the current code
-> Support of a great part of National Instruments PCI cards (thanks
to the pcimio driver).
In Xenomai x.x: Analogy 1.1:
-> Comedi compatibility layer
-> Auto calibration
-> Any Ideas / requests coming from users
-> More Analogy drivers.
Is that ok ?
>
> 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
> will entail?
>
> 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?
>
Alexis.
_______________________________________________
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
