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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
