On Mon, 2009-10-12 at 23:52 +0200, Alexis Berlemont wrote: > 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. >
Fair enough. However, the technical proposal you sent required the readership to be aware of both the current Comedi and potentially future Analogy implementation. This may be asking too much to get answers. I see two ways to get out from this: - me, switching on bozo mode and making that thread running like a joke with silly questions, - you, introducing the topic with higher level considerations and questions about what could make Analogy better than Comedi, in terms of user experience. E.g. what are the annoying issues with the API semantics on the application side, what makes writing a card driver the best incentive to start a therapy and so on. So, should I enter bozo mode or will you spare people a therapy? > > 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. > Yes. Yes. Yes. Indeed. > -> 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: Since that should not break the ABI, additions of that kind should go to the 2.5.x maintenance releases first. Which also means that you may want to account for the ABI stability requirement up front. > -> Comedi compatibility layer > -> Auto calibration > -> Any Ideas / requests coming from users > -> More Analogy drivers. > > Is that ok ? > Yes, provided this does mean that people working with Analogy 1.0 should be able to port to newer releases without redesigning their code. > > > > 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 -- Philippe. _______________________________________________ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
