Daniele Nicolodi wrote:
> Alexis Berlemont wrote:
> > Daniele Nicolodi wrote:
> >> After fixing analogy to permit continuous acquisition, I discovered that
> >> ongoing commands are not canceled when a device is closed (I obtain a
> >> DMA buffer owerwrite warning in the kernel log when I abruptly terminate
> >> my acquisition program).
> >> I think this is quite a surprising behavior. I would expect that the
> >> commands are canceled when there isn't a data consumer any more. Would
> >> it be possible to cancel any ongoing command on device close? If there
> >> is agreement on this, I can look into providing a patch.
> > The close should indeed stop any occurring acquisition. I implemented
> > this behaviour. It is in my git repository.
> Hi Alexis. I have been working with analogy from your git three and I
> should say that the new behavior, in my use case, is worst than the
> Now, when a device is closed, all accurring acquisition are terminated,
> also the ones that haven't been started by the current process. While it
> is possible to use at the same time two different subdevices, from two
> different processes, now it is not possible to terminate one process and
> leave the other one running. I think that the correct behavior would be
> to terminate just the acquisitions started by the current process.
> However, I have no idea on how difficult this would be.
We had two alternatives: either stopping nothing or cancelling "any
ongoing command" related with the device. Cancelling only acquisitions
initiated by a specific process implies the implementation of some
tricky mechanism above the file approach (open, ioctl, close). I am
afraid that we will create some complex code for an issue which should
be solved by a suitable device file organization (maybe many dev files
instead of a single one).
I will have a look at what you asked but I cannot ensure anything, I
have no clear solution in mind.
> This bring me also to the fact that there isn't currently a way to
> prevent two concurrent processes to access the same subdevice,
> interfering each other. Would it possible to have a lock() method, as
> comedi has?
There is a lock mechanism but it is not exposed as it is in
comedi. The lock system is at the subdevice level: you cannot initiate
an instruction if a command is occuring (the reverse is true of
course). This is handled with a subdevice status bitfield atomically
accessed. Have a look at a4l_reserve_transfer() and tell me if I miss
> Thanks. Cheers,
> Xenomai-core mailing list
Xenomai-core mailing list