Hi, 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 > previous. > > 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 something. > > Thanks. Cheers, > -- > Daniele > > _______________________________________________ > Xenomai-core mailing list > Xenomai-core@gna.org > https://mail.gna.org/listinfo/xenomai-core -- Alexis. _______________________________________________ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
