On Sat, 10 Apr 2021 10:22:18 +0200, Takashi Sakamoto wrote: > > On Fri, Apr 09, 2021 at 04:18:00PM +0200, Takashi Iwai wrote: > > On Fri, 09 Apr 2021 15:34:14 +0200, > > Jaroslav Kysela wrote: > > > > > > Dne 09. 04. 21 v 12:59 Takashi Iwai napsal(a): > > > > > > >> 5. add any mechanism to bind lifetime of user-defined element set to user > > > >> process > > > >> > > > >> At present, the lifetime of user-defined element set is bound to card > > > >> itself. However, it's convenient to user processes to bind the lifetime > > > >> to process itself. I add any mechanism for it. > > > >> > > > >> For recent years I've made some patches in house but never arrive at the > > > >> best one. In the patches, I utilize access flags but in general the > > > >> maintenance of lifetime is not easy issue. I tackle again in this time. > > > > > > > > It sounds interesting, but I don't know how easily you can manage it. > > > > The driver doesn't care much about the user process lifetime, but > > > > mostly concentrate on the file handle... > > > > > > It should be easy to trace which process created the user element and > > > automatically remove this element when the process close the file descriptor. > > > Something like 'bind lifetime of the control to the active control file > > > descriptor'. > > > > If it's tied only with the file handle, it's easy. But I thought this > > is about the process? > > The 'lifetime' relates any operations from userspace relevant to > element. In the point, it's not so easy. It's better to see the list of > ioctl request to ALSA control character device, guys. I'm lost. What makes so difficult if the element is tied with the file descriptor? You'd nuke the corresponding element at snd_ctl_release(), and it should be enough. If it's not tied with the file descriptor, it's indeed difficult, but it has nothing to do with the number of ioctl implementations. Takashi
