Re: Control TLV extension - final proposal

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



At Wed, 28 Jun 2006 15:19:26 +0200 (CEST),
Jaroslav Kysela wrote:
> 
> On Wed, 28 Jun 2006, Takashi Iwai wrote:
> 
> > > Yes, but that's the way how user control elements works. 
> > 
> > No, the question is how to pass the TLV list.  Using the same ioctl
> > for completely different purposes is confusing.
> 
> Note that writting new TLV value / contents might make perfect sense, so 
> it's not completely wrong.

Remember that TLV_WRITE is designed for a generic query.  The caller
can put an item to ask, and the driver is supposed to write the answer
back. 

If the same mechanism is applied to the user-space elements, the
queried item is simply registered as the new value and the whole
previous TLVs are lost.  (And even no error is returned!)

> > > The similar 
> > > situation is for the element value where no "back to user space callback" 
> > > exists so the written values cannot be verified.
> > 
> > Sorry what do you mean?  The elements without tlv write support?
> > In that case, you can know the TLV-WRITE ioctl is invalid for that
> > element beforehand.
> 
> No, I mean standard snd_ctl_elem_write() ioctl. There is no way to verify 
> if passed value is ok (no communication with the user space - the creator 
> task might not even exist, simply blind memcpy).

It's fine because snd_ctl_eme_read() and snd_ctl_elem_write() are
really corresponding 1:1.  The write is just write, and the read is
just read.

But, TLV_WRITE is used for a query.  The write means also read.  It's
the difference.

> > > If you want the "correct" behaviour, an another layer must be designed 
> > > and we may call these elements as user-defined version 2.
> > 
> > Urgh, it's a bad strategy to assume the next version before implementing 
> > the first version.
> 
> Nope in my eyes, this implementation is far easier. Why bother with much 
> difficult stuff like the value update request queueing now?

The important thing regarding desiging API is to define the demands
from the application side.  I feel it's still not well done.

If we really need something, it must be implemented.  If not needed,
then we shouldn't implement it at all.  Such a thing can be decided at
the very first stage.


Takashi

Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/alsa-devel

[Index of Archives]     [ALSA User]     [Linux Audio Users]     [Kernel Archive]     [Asterisk PBX]     [Photo Sharing]     [Linux Sound]     [Video 4 Linux]     [Gimp]     [Yosemite News]

  Powered by Linux