Idea: dynamic loading of USB quirks

Idea: dynamic loading of USB quirks

[maillist]

Dear Alsa community,
I've some minor contributions in the form of patches for USB quirks for 
devices in the past. It occurred to me that having these USB quirks hardcoded 
into the driver maybe isn't the best thing.

Looking at the current quirks file, the majority of them are relatively trivial 
and are really just there to give the USB driver a nudge in the right 
direction.

Having to have these hardcoded into the driver creates a number of issues:

1. It needs someone with the expertise and will, and access the specific device 
for testing, to build the quirk. To hardened ALSA hackers this seems trivial, 
but to an average end user who has a device they want to get supported, this 
can be pretty inpenatrable. The complexity of just getting the alsa source 
installed and set up for compilation is enough to put off the vast majority of 
users.

2. It makes the process of getting the driver "to market" lengthy as these 
changes have to go through all of the normal release schedules, and these are 
pretty opaque.

3. It makes getting changing a driver (because of a bug, or a new release of 
hardware) difficult as the revisions need to go through the whole process of 
creating a patch, getting it accepted, and then the long kernel release 
process, as well as the various distribution release processes.

It occured to me that there might be a better way where quirks like this could 
be dynamically loaded into the driver after it has loaded. This would a 
structured text file describing the quirk to be created and pushed into the 
driver. Ultimately this could be wrapped into a framework where quirk files 
could be put into a common directory (similar to modprobe.d) with a startup 
script which pushed these into the driver.

At the moment I don't have any specific thoughts about how to do this, but I 
thought it would be useful to elicit ideas from this community. The way I see 
it it needs:

* A structured file format to describe the quirks
* A basic method to push these files into the driver at runtime (sysfs?)
* Some sort of dynamic data area for the driver to store the data
* changes to the driver to accept, store and process these data structures

At the moment I just thought I would get people thinking about this and, 
perhaps, making suggestions about whether it makes sense, whether it's 
practically achievable within the framework of the kernel and ALSA, and 
possible methods which might lead to a solution.

If I get the time (and, at the moment, that's unlikely for the next 6 months) 
I'll look at trying to code something up. If anyone else is inspired and feels 
like having a crack at it, then feel free.

All comments and discussion welcome.

Cheers,

Keith 

Re: [alsa-devel] Idea: dynamic loading of USB quirks

[Daniel Mack]

[cc lkml as this might be of broader interest]

On 01.11.2012 00:32, maillist@superlative.org wrote:
> Dear Alsa community,
> I've some minor contributions in the form of patches for USB quirks for 
> devices in the past. It occurred to me that having these USB quirks hardcoded 
> into the driver maybe isn't the best thing.
> 
> Looking at the current quirks file, the majority of them are relatively trivial 
> and are really just there to give the USB driver a nudge in the right 
> direction.
> 
> Having to have these hardcoded into the driver creates a number of issues:
> 
> 1. It needs someone with the expertise and will, and access the specific device 
> for testing, to build the quirk. To hardened ALSA hackers this seems trivial, 
> but to an average end user who has a device they want to get supported, this 
> can be pretty inpenatrable. The complexity of just getting the alsa source 
> installed and set up for compilation is enough to put off the vast majority of 
> users.
> 
> 2. It makes the process of getting the driver "to market" lengthy as these 
> changes have to go through all of the normal release schedules, and these are 
> pretty opaque.
> 
> 3. It makes getting changing a driver (because of a bug, or a new release of 
> hardware) difficult as the revisions need to go through the whole process of 
> creating a patch, getting it accepted, and then the long kernel release 
> process, as well as the various distribution release processes.
> 
> It occured to me that there might be a better way where quirks like this could 
> be dynamically loaded into the driver after it has loaded. This would a 
> structured text file describing the quirk to be created and pushed into the 
> driver. Ultimately this could be wrapped into a framework where quirk files 
> could be put into a common directory (similar to modprobe.d) with a startup 
> script which pushed these into the driver.

The idea is interesting, but we would need to find a way to not only
cover the entries in quirks-list.h but the other hard-coded details as well.

I fear that if quirk fixups are done on both the kernel level and loaded
from userspace, it actually makes debugging and maintainance harder.

Then again, if a versatile and clean solution to this problem is found,
there would be tons of other drivers in Linux to benefit from it, just
think about the hda driver to begin with. But not only in the ALSA area.


Daniel

Re: [alsa-devel] Idea: dynamic loading of USB quirks

[maillist]

On Thursday 01 Nov 2012 10:05:41 Daniel Mack wrote:
> [cc lkml as this might be of broader interest]
> 

> 
> Then again, if a versatile and clean solution to this problem is found,
> there would be tons of other drivers in Linux to benefit from it, just
> think about the hda driver to begin with. But not only in the ALSA area.
>

I was initially thinking of the more trivial USB quirkes only, and having the 
more complex quirks remain as hard coded.

But it does make sense that, if such a capability could be extended, that it 
could be used for other drivers too.

Cheers,

Keith

Re: [alsa-devel] Idea: dynamic loading of USB quirks

[Takashi Iwai]

At Thu, 01 Nov 2012 10:05:41 +0100,
Daniel Mack wrote:
> 
> [cc lkml as this might be of broader interest]
> 
> On 01.11.2012 00:32, maillist@superlative.org wrote:
> > Dear Alsa community,
> > I've some minor contributions in the form of patches for USB quirks for 
> > devices in the past. It occurred to me that having these USB quirks hardcoded 
> > into the driver maybe isn't the best thing.
> > 
> > Looking at the current quirks file, the majority of them are relatively trivial 
> > and are really just there to give the USB driver a nudge in the right 
> > direction.
> > 
> > Having to have these hardcoded into the driver creates a number of issues:
> > 
> > 1. It needs someone with the expertise and will, and access the specific device 
> > for testing, to build the quirk. To hardened ALSA hackers this seems trivial, 
> > but to an average end user who has a device they want to get supported, this 
> > can be pretty inpenatrable. The complexity of just getting the alsa source 
> > installed and set up for compilation is enough to put off the vast majority of 
> > users.
> > 
> > 2. It makes the process of getting the driver "to market" lengthy as these 
> > changes have to go through all of the normal release schedules, and these are 
> > pretty opaque.
> > 
> > 3. It makes getting changing a driver (because of a bug, or a new release of 
> > hardware) difficult as the revisions need to go through the whole process of 
> > creating a patch, getting it accepted, and then the long kernel release 
> > process, as well as the various distribution release processes.
> > 
> > It occured to me that there might be a better way where quirks like this could 
> > be dynamically loaded into the driver after it has loaded. This would a 
> > structured text file describing the quirk to be created and pushed into the 
> > driver. Ultimately this could be wrapped into a framework where quirk files 
> > could be put into a common directory (similar to modprobe.d) with a startup 
> > script which pushed these into the driver.
> 
> The idea is interesting, but we would need to find a way to not only
> cover the entries in quirks-list.h but the other hard-coded details as well.
> 
> I fear that if quirk fixups are done on both the kernel level and loaded
> from userspace, it actually makes debugging and maintainance harder.
> 
> Then again, if a versatile and clean solution to this problem is found,
> there would be tons of other drivers in Linux to benefit from it, just
> think about the hda driver to begin with. But not only in the ALSA area.

HD-audio driver has already a sort of "firmware" support.  It can read
text data to patch the pre-existing BIOS setup, add extra
initialization verbs or give hints for drivers to change the specific
behavior.

For USB-audio, a simple TLV representation would be feasible for an
extra quirk entry.


Takashi