From: Jonathan W. <jw...@ju...> - 2014-01-23 22:10:14
|
On Thu, Jan 23, 2014 at 01:27:10PM +0100, Clemens Ladisch wrote: > Jonathan Woithe wrote: > > On the subject of the hwdep interface to the kernel driver, I still need to > > have a look at that in more detail - I'll try to get to this soon. In > > particular, I would like to check what is in struct snd_firewire_get_info > > and whether we should consider adding additional fields in there which are > > likely to be required by other firewire audio drivers in future. > > The _only_ purpose of this ioctl is to allow identifying the /dev/fw* > device that corresponds to an ALSA card. Ok. As I said, I need to take a closer look at the code. The sample hwdep program which was posted a while back seemed to indicate that additional identifcation information was fed back from this ioctl as well (for example, the device name, the card, GUID and so on). To avoid potential confusion I'm talking about the SNDRV_FIREWIRE_IOCTL_GET_INFO here. > > At the very least we should include some mechanism allowing the > > structure to be enlarged in future without creating an ABI breakage. > > If this is really needed, it could be done with another ioctl code. Ok, if there's no problem with adding ioctls to this then I'm fine with it. > > Either that or we'll need to accept the fact that some of the future > > drivers will need additional interfaces (perhaps under /sys). > > The main interface between userspace and the device would be /def/fw*. > Anything that cannot be shared between the application and the kernel > driver (such as the DICE notification) requires a special ioctl code > anyway. That's ok then. I recall hearing at some point that there was resistance to adding too many ioctls these days with preferences being to use sysfs and the like. If additional ioctls can be added as needed to support other devices then there's no problem. The context here is mostly the RME devices. It turns out that it's impossible to query the device for the current configuration (where "configuration" here extends beyond the streaming status and includes things such as phantom power status, optical port modes and so on). As a result there needs to be a single source for this information provided by the software environment which can be shared by all programs which make use of the interface. In FFADO at present this is done by way of a shared memory segment which is created by the first FFADO component to run and destroyed by the last one to exit. When I move the RME streaming engine into the kernel it will be the kernel which will have to provide this repository. I should add that this device configuration information is required equally by the streaming engine and the mixer/control components so it isn't sufficient to palm this out to userspace. If an ioctl is regarded as an appropriate way to get and set this status then I'm happy. Regards jonathan |