Alexis Berlemont wrote: > Hi, > > Peter Soetens <peter.soet...@fmtc.be> writes: > >> 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. > > Just to sum-up why the whole Comedi API suffers so many changes from > the upstream Comedi API (sorry for 'legacy'): > > * At the very beginning (If I remember well), I just wanted to port > the current Comedi layer so as to comply with RTDM API. My first > resolution was to leave the drivers set unchanged so as to > seamlessly use them in the ported framework. However, I was facing > many issues (RT/NRT contexts, mix with kernel API, etc.) I could not > handle without altering drivers code. Eventually, I was unable to > provide a coherent RTDM Comedi module considering the code > organization. > > * That was the point which makes try to overhaul the original > branch. I sent an email on the Comedi mailing list. I received no > answer; by the way, the activity seemed quite low. I wanted to > develop a Comedi infrastructure usable on both configurations > (common Linux API and RTDM). Fulfilling such a constraint led me to > redefine the kernel driver API. Before integrating the code into > Xenomai's trunk, I decided to drop the common Linux interface while > keeping in mind that the RTDM-native module would allow the new > Comedi core to run on common kernels (maybe that was a > mistake). That is why, the driver API still have the context notion; > I should remove it. > > Then I did my best to design a coherent layer. There are still many > flaws to be improved. Notably at the driver level, the API is too > closed. I (and/or anyone interested) should find a way to provide more > freedom to drivers developers. > > Concerning the library API, I just thought there were too many > functions in comedilib, and some were redundant with each other. I > tried to propose an alternative like the native skin API was an > alternative to the RTAI API. Maybe I was wrong. > > All that work relied on my assumption that upstream Comedi was not > very active anymore. Then, it was an opportunity for me to have fun > trying to deliver an RTDM port based on a new architecture. > > That was the reason why, I was really suprised to find Comedi > integrated into the mainline kernel. What strikes me more is that > Comedi seems to be left as is. Do you think, it will be cleaned up or > reworked ?
Without rework Comedi will not make into mainline (I wouldn't call the staging corner "mainline"). And when reading this http://permalink.gmane.org/gmane.linux.kernel/793476, it is probably the best time now to propose interface changes and contribute back improvements made for the RTDM rework. Jan
Description: OpenPGP digital signature
_______________________________________________ Xenomai-core mailing list Xenomaifirstname.lastname@example.org https://mail.gna.org/listinfo/xenomai-core