Problems with maintaining a separate alsa-driver in a distribution

Problems with maintaining a separate alsa-driver in a distribution

[Ozan Çağlayan]

Hi,

I'm maintaining the ALSA stack as a separate alsa-driver using the
supplied tarballs from www.alsa-project.org unlike some popular distros
which uses the in-kernel sound/ stack. This has the advantage of quickly
acting against latest quirk or driver support changes and pushing a
driver update instead of whole the kernel update.

But there is a big disadvantage that I'm not able to figure out how to
solve:

When we enable the SND Kconfig option in kernel, some other sound
support for some DVB devices(e.g. SAA7134 sound support, etc.) are
enabled as well. So if you're using the in-kernel ALSA, you can enable
and use them happily but in my case, those additional sound supports
can't be enabled in kernel.

Is there a way to hack around this when a separate alsa-driver is used
in a distro? Is it technically possible to patch those tiny drivers onto
alsa-driver and compile them if the .config file from the kernel source
has enabled those DVB devices?

Or maybe I should enable ALSA in-kernel, compile those DVB sound stuff
and remove the sound/ directory from the kernel package? (Even the idea
sounds really *dirty*, dunno if it's technically possible too)

Thanks,
Ozan Caglayan

http://www.pardus.org.tr/eng

Re: Problems with maintaining a separate alsa-driver in a distribution

[Takashi Iwai]

At Mon, 18 May 2009 13:33:10 +0300,
Ozan Çağlayan wrote:
> 
> Hi,
> 
> I'm maintaining the ALSA stack as a separate alsa-driver using the
> supplied tarballs from www.alsa-project.org unlike some popular distros
> which uses the in-kernel sound/ stack. This has the advantage of quickly
> acting against latest quirk or driver support changes and pushing a
> driver update instead of whole the kernel update.
> 
> But there is a big disadvantage that I'm not able to figure out how to
> solve:
> 
> When we enable the SND Kconfig option in kernel, some other sound
> support for some DVB devices(e.g. SAA7134 sound support, etc.) are
> enabled as well. So if you're using the in-kernel ALSA, you can enable
> and use them happily but in my case, those additional sound supports
> can't be enabled in kernel.
> 
> Is there a way to hack around this when a separate alsa-driver is used
> in a distro?

It's fairly difficult because the internal API was changed.
Especially the core struct was modified recently, thus there is no
ABI compatibility at all between the older kernel and the latest alsa
driver.

> Is it technically possible to patch those tiny drivers onto
> alsa-driver and compile them if the .config file from the kernel source
> has enabled those DVB devices?
>
> Or maybe I should enable ALSA in-kernel, compile those DVB sound stuff
> and remove the sound/ directory from the kernel package? (Even the idea
> sounds really *dirty*, dunno if it's technically possible too)

You'd need to copy the original ALSA in-kernel stuff, copy the headers
from alsa-driver, then rebuild the related modules in kernel to follow
the new API.  Also, some wrappers would be needed, e.g. for the
obsoleted snd_card_new().


Takashi
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Problems with maintaining a separate alsa-driver in a distribution

[Ozan Çağlayan]

Takashi Iwai wrote:
>
> It's fairly difficult because the internal API was changed.
> Especially the core struct was modified recently, thus there is no
> ABI compatibility at all between the older kernel and the latest alsa
> driver.
>
>   
>> Is it technically possible to patch those tiny drivers onto
>> alsa-driver and compile them if the .config file from the kernel source
>> has enabled those DVB devices?
>>
>> Or maybe I should enable ALSA in-kernel, compile those DVB sound stuff
>> and remove the sound/ directory from the kernel package? (Even the idea
>> sounds really *dirty*, dunno if it's technically possible too)
>>     
>
> You'd need to copy the original ALSA in-kernel stuff, copy the headers
> from alsa-driver, then rebuild the related modules in kernel to follow
> the new API.  Also, some wrappers would be needed, e.g. for the
> obsoleted snd_card_new().
>   

But that shouldn't pose any problem if I stick with 2.6.30_rc* + latest
alsa-driver right? But yes, during the lifetime of a stable distribution
release, the separate alsa-driver will always move faster than the
kernel and the ABI changes will be inevitable.

So It will become difficult enough when the stock kernel of the distro
and alsa-driver diverges from each other, am I right?

Thanks,

Re: Problems with maintaining a separate alsa-driver in a distribution

[Takashi Iwai]

At Mon, 18 May 2009 13:55:57 +0300,
Ozan Çağlayan wrote:
> 
> Takashi Iwai wrote:
> >
> > It's fairly difficult because the internal API was changed.
> > Especially the core struct was modified recently, thus there is no
> > ABI compatibility at all between the older kernel and the latest alsa
> > driver.
> >
> >   
> >> Is it technically possible to patch those tiny drivers onto
> >> alsa-driver and compile them if the .config file from the kernel source
> >> has enabled those DVB devices?
> >>
> >> Or maybe I should enable ALSA in-kernel, compile those DVB sound stuff
> >> and remove the sound/ directory from the kernel package? (Even the idea
> >> sounds really *dirty*, dunno if it's technically possible too)
> >>     
> >
> > You'd need to copy the original ALSA in-kernel stuff, copy the headers
> > from alsa-driver, then rebuild the related modules in kernel to follow
> > the new API.  Also, some wrappers would be needed, e.g. for the
> > obsoleted snd_card_new().
> >   
> 
> But that shouldn't pose any problem if I stick with 2.6.30_rc* + latest
> alsa-driver right?

Right.  It's about 2.6.29 or earlier kernels.

> But yes, during the lifetime of a stable distribution
> release, the separate alsa-driver will always move faster than the
> kernel and the ABI changes will be inevitable.
> 
> So It will become difficult enough when the stock kernel of the distro
> and alsa-driver diverges from each other, am I right?

Yes, at this time, the core struct was change, unfortunately.
If it's just about a function, this could be easier to add a hack, but
the struct is much more difficult to work around the ABI compatibility.


Takashi
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel