[alsa-devel] alsactl init - implementation and more..

[Mark Brown]

On Wed, Aug 13, 2008 at 04:18:16PM +0200, Takashi Iwai wrote:

> Of course, it's a question how fine-grained each file should be.  But
> in general, modifying the default configuration just for adding a new,
> fairly independent item is a bad idea.  In my scenario: you want to
> add the support for a new hardware -- fine, just add the file without
> changing anything else.  This would make the maintenance a lot easier

Yeah, I can see embedded people liking this too - a relatively small
proportion of machines end up submitting their code to mainline for
various reasons and carrying patches is no fun.

> (imagine you maintain a distro package).

Or use one, for that matter - if you've got local changes then you need
to resolve the conflicts between them and the distro versions on every
upgrade.

> > I'm not sure. The restore action will always overwrite all 'init' values 
> > (at least when control identifier list is not changed in the driver). 
> > Probably, I would prefer a buildin procedure like 'if restore fails then 
> > do init'. What about 'alsactl boot' action name?

> The init makes sense in the case when the driver is updated and some
> new controls.  Then the newly added controls are set up properly, then
> the other values are overwritten via restore.

I've not looked at the new code yet but it would be *really* nice to
have a format where only the control names are used.