Philippe Gerum wrote:
> On Thu, 2009-10-08 at 01:26 +0200, Alexis Berlemont wrote:
>> Hi,
>>
>> The last week, I have been working on the global architecture of the analogy 
>> project.
>>
>> I tried to sum-up the main characteristics of Comedi. That was a start to 
>> figure out what shape analogy will get.
>>
>> Here are some notes on that subject:
>>
>> 1) Comedi drivers are not common Linux drivers. In these drivers:
>>      - there is neither fops structure nor ioctl operations
>>      - there is, of course, no cdev registration
>>      - The Linux API is sometimes wrapped into Comedi-specific functions 
>> (ex. 
>> irq).
>>
>> 2) Comedi imposes a specific organization: devices are composed of 
>> subdevices 
>> which are themselves composed of channels. Then a Comedi driver:
>>      - declares a list of subdevices
>>      - displays a list of callbacks per subdevices (command, instructions, 
>> trigger, etc.).
>>
>> 3) The Comedi midlayer is the link between the Linux driver programming 
>> model 
>> and the Comedi drivers:
>>      - The Comedi core manages a set of pre-registered character devices
>>      - Via a specific ioctl, the core assigns a dev file to some driver and 
>> an 
>> "attach" callback is called within the driver.
>>      - The comedi core is in charge of routing the ioctls to the proper 
>> subdevice 
>> callbacks.
>>
>> According to me, this architecture brings some troubles:
>> 1) Not all the drivers perfectly fit into the midlayer:
>>      - Some components of acquisition cards do not comply with the subdevice 
>> model 
>> (ex. the mite in NI card). 
>>      - We find card specific declarations in the Comedi core layer (ex.: 
>> some NI 
>> specific counter modes in comedi.h);
>> 2) On the user space side, it is difficult to write a card independant 
>> application.
>>
>> All these points make me think that the idea of midlayer itself is not 
>> suitable in our case. Because of the fact that the drivers do not fit well 
>> into the generic programing model, we find ourselves adapting user space 
>> programs to the card they will use.
>>
>> I would rather propose a framework composed of helper modules. Analogy 
>> drivers 
>> would be quite similar with common RTDM drivers (they would contain fops 
>> declarations, dev registrations, etc.); 
>>
>> As a consequence, Analogy will be a set of tools:
>>      - ioctl routing function
>>      - acquisition device registration
>>      - asynchronous buffer management modules
>>      - etc.
>>
> 
> This sounds like a plan, but this also raises a major concern: what's
> the status of your current code wrt the upcoming 2.5 now, given that you
> seem to imply that the current Comedi/RTDM tree does not exhibit the
> final architecture yet, and your proposal entails fundamental changes?
> 
> It was made very clear during the recent XUM that 2.5 will be out this
> year, which leaves us with enough time to tackle the current issues, but
> likely not to reshuffle a complete framework.
> 
> We could live with that framework only providing a single acquisition
> driver in 2.5.0, but the former has to be stable, and the ABI written in
> stone for the 2.5.x series. Provisions for transparent multi-ABI support
> might be acceptable, but this still requires to be confident about what
> would be needed in the long run, and that sudden change in your
> architecture is worrisome.
> 
> In short, assuming your current work description eventually holds,
> what's your timing to deliver?

Given that we did not deliver a stable version with comedi/analogy
support yet, what about declaring the whole thing "experimental" or
"unstable" (/wrt to its ABI) until the dust settled. That way any user
building some application on top if it would do this on his own risk.

Jan

Attachment: signature.asc
Description: OpenPGP digital signature

_______________________________________________
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core

Reply via email to