Alexis Berlemont wrote:
> Hi,
> Peter Soetens <> 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, it is probably the
best time now to propose interface changes and contribute back
improvements made for the RTDM rework.


Attachment: signature.asc
Description: OpenPGP digital signature

Xenomai-core mailing list

Reply via email to