[Pkg-alsa-devel] Drop ALSA modules from kernel-image?

[Thomas Hood]

--=-4bFGWjDgRLC1YmgvS3pZ
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

FYI here is an IRC discussion on FreeNode:#debian-kernel of the
question: Should ALSA modules be removed from the kernel-image packages?
I asked this question on IRC after the idea was introduced in this
mailing list thread:

http://lists.debian.org/debian-devel/2005/03/msg00131.html

The conclusion I draw from the discussion is that ALSA modules will not
be removed from k-i.  This means that alsa-modules can be phased out in
the long run.  It also means that users of OSS under 2.6 have a problem:
nothing blacklists the ALSA modules that ship with k-i 2.6.
-- 
Thomas Hood <jdthood@aglu.demon.nl>

--=-4bFGWjDgRLC1YmgvS3pZ
Content-Disposition: attachment; filename=alsa-modules.irclog
Content-Type: text/plain; name=alsa-modules.irclog; charset=ISO-8859-15
Content-Transfer-Encoding: 7bit

<jdthood> How about removing the ALSA modules from the kernel-image packages?
<svenl> jdthood: whyever that ?
<jdthood> Because they are out of date relative to what you get in alsa-modules packages.
<jdthood> To get up to date modules you install alsa-modules.  Then the modules in kernel-image are not used and are wasting space.
<svenl> jdthood: why not patch the kernel-modules instead ? Or are the alsa modules built against the kernel-image ones ?
<jdthood> Furthermore, the presence of ALSA modules in k-i is only a source of trouble for people who want to run OSS.
<jdthood> svenl: Backporting the changes would be a waste of time.  Huge effort required for no benefit.
<nchip> Isn't it more usefull to have alsa in mainline kernel up to date?
<svenl> nchip: exactly.
<jdthood> nchip: Why is it more useful to have up to date modules in kernel-image when up to date modules are available in alsa-modules?
<jdthood> Also, who is going to update the modules in k-i?
<svenl> jdthood: do the alsa-modules come precompiled for the official kernels for all arches ?
<svenl> jdthood: you ?
<jdthood> svenl: Not currently, but it's easy to generate them for 2.6 just as we generate them for 2.4.
<nchip> jdthood: Well shrug, maybe we should maintain ide and scsi systems outside kernel as separate module packages
<svenl> jdthood: it is probably too late for sarge though.
<jdthood> nchip: Are those module systems already available in separate packages?
<svenl> jdthood: some qre
<svenl> are even.
<jdthood> Currently it is not really safe to use OSS under 2.6 because nothing blacklists ALSA modules.
<dilinger> i'd rather just drop OSS :P
<jdthood> There are no separate oss-modules packages so dropping OSS modules from k-i is not an option unless you want to drop support for OSS in 2.6 entirely.
<svenl> dilinger: :)
<dilinger> jdthood: right, that's what i'm saying
<dilinger> anyways, i don't see this as a major problem
<dilinger> hotplug blacklists oss if alsa-base is installed
<dilinger> not sure if discover does the same, but it should
<jdthood> Yes, but nothing blacklists ALSA modules if the user wants to use OSS.
<dilinger> if using 2.6, alsa should be used.  oss is a fallback thing if the alsa modules are broken; and if that's the case, then the user's gonna have to modify stuff anyways
<jdthood> OK, so the "improves OSS support" argument doesn't have any importance for you.  There are also the "improves ALSA support" and "saves space" and related arguments.
<makx> jdthood: it's not time to take massive destabilisation just for better sound support!
<nchip> jdthood: what is there in alsa-modules what is not in the alsa of kernel? And why is alsa in kernel not maintained as well as the external modules?
<makx> we won't take backport patches for alsa.
<jdthood> nchip: The ALSA modules in the kernel are old: version 1.0.4.  The latest version of ALSA is 1.0.8.
<svenl> jdthood: zhich kernel version are those ? 2.6.8 or 2.6.11 ?
<jdthood> 2.6.8 contains ALSA 1.0.4
<makx> jdthood: you put yourself in trouble while upgrading to newer userland :P
<jdthood> 2.6.10 contains ALSA 1.0.6
<svenl> jdthood: so, go bother the release managers so we can chip 2.6.11 in sarge :)
<waldi> svenl: where is the source for 2.6.11?
<svenl> waldi: in svn :)
<svenl> waldi: there was no upload yet.
<makx> the tg3 stuff and the prune stuff isn't yet done for 2.6.11
<jdthood> svenl: This is relevant to more than just the packages in sarge.  Going forward we will continue to see version mismatches between the ALSA modules in k-i and those alsa-modules and libasound2.
<svenl> jdthood: whcih will be gapped each time there is a new upstream release, no ?
<dilinger> jdthood: i would love to improve alsa support.  unfortunately, it's not going to happen for sarge (assuming sarge ships w/ d-i rc3)
<jdthood> dilinger: OK, that I understand.  I know it's late in the game.
<jdthood> s/late/too late/
<jdthood> In principle, though, and perhaps post sarge the ALSA modules should be removed from k-i.
<jdthood> Unless someone can think of a reason for keeping them in k-i that I haven't heard yet.
<svenl> jdthood: no, kernels should be made more uptodate, not broken by removing the ALSA modules.
<jdthood> Reasons for removing: They interfere with OSS, waste space on systems that use OSS or that use alsa-modules, and don't work as well as the modules in alsa-modules packages.
<dilinger> jdthood: are there alsa-modules-2.6* packages?
<svenl> jdthood: for all arches, not just x86.
<jdthood> dilinger: Not currently, but these could be provided.
<svenl> jdthood: you are willing to break sound support for most cases just to please a few.
<svenl> jdthood: provide them, and have them divert the kernel ones, and then we will see.
<jdthood> svenl: What are you talking about?  How will sound support be broken?
<dilinger> jdthood: for that to happen; there would have to be alsa-modules-2.6.x packages, kept up-to-date w/ kernel packages, that kernel-image-2.6.x depends upon
<dilinger> so, before we shipped 2.6.11 (for example), we'd have to make sure alsa-modules-2.6.11 was uploaded
<jdthood> We already do that for 2.4, so it's not difficult to do it for 2.6 as well.
<dilinger> we would also have to update them for ABINAME transitions, as well
<svenl> jdthood: because either the modules will only be available on x86, will be broken, or otherwise misconfigured.
<makx> jdthood: more packages are bad.
<svenl> jdthood: nope, we already do that for x86 2.4, all other arches are left in the mud.
<svenl> makx: look at ubuntu's X packages and reconsider that please :)
<dilinger> jdthood: the difference is, for 2.4, if alsa isn't ready when a new 2.4.x kernel is released, it's not a big deal
<dilinger> most people use oss
<dilinger> for 2.6, if alsa-modules-* aren't ready, then we end up blocking
<makx> like udeps for d-i.
<makx> svenl: that's userland, fine to hear. :)
<dilinger> jdthood: given that, i'd rather see k-i recommends/suggest alsa-modules-*, and allow both to be installed..
<svenl> makx: /me things there should be one .udeb for each module, and they should be installed on demand, automatically and dynamically by discover-like-detection :)
<jdthood> dilinger: OK, that's a good argument.
* svenl had too much dealing with d-i :)
<dilinger> i'm not overly concerned about space (someone who is is going to be building their own kernel anyways; /lib/modules/`uname -r` contains everything under the sun)
<jdthood> dilinger: It is already the case that alsa-modules can be installed for 2.6 kernels.  No problem there.
<dilinger> jdthood: as an added bonus, it would also potentially be possible for sarge, doing it that way
<waldi> lets check 2.6.11
<jdthood> dilinger: You might want to add something to the release notes too.  "The 2.6 kernels that ship with sarge contain ALSA modules whose version does not match the version number of the ALSA userland software that ships with sarge.  To fix this, install an alsa-modules package to match your kernel.  You may have to build this package yourself from alsa-source using the make-kpkg utility."
<dilinger> how much of this is an issue?
<dilinger> i mean, are ioctls changing between minor versions?
<waldi> if yes, the interface is fundamentaly broken
<jdthood> dilinger: Mixer controls have moved around.  There are some other incompatibilities which I haven't analysed in detail.  I just tell people to install alsa-modules.
<jdthood> There is also the problem of TV cards grabbing index 0.  This is fixed in alsa-modules but not in the k-i ALSA modules.
<dilinger> hm
<waldi> svenl: the source is unbuildable
<jdthood> The latter problem gets reported quite often.
<waldi> rm -f stamp-* .config* version.Debian
<waldi> dh_clean
<waldi> dh_clean: cannot read debian/control: No such file or directory
<waldi> make: *** [clean] Error 1
<waldi> debuild: fatal error at line 764:
<dilinger> jdthood: can we beat upstream w/ a large, blunt object, to keep them from doing that?
<svenl> waldi: debian/rules prune - it is the infamous debian/official problem. see the tail of the debian/rules for detaisl.
<dilinger> i mean, if people are switching between different kernels (ie, 2.6.8, 2.6.9, and 2.6.10), they'll need alsa-modules-2.6.{8,9,10}, which probably won't stay in the archive for very long..
<jdthood> dilinger: I agree that upstream isn't being perfectly helpful to distros.  However, I can understand why they don't want to provide backward compatibility.  It would make their job a lot more difficult.
<jdthood> dilinger: alsa-modules-2.6.{8,9,10} can be built on demand, of course.  If we were to provide binaries in the archive for all arches and kernels then their life cycle would have to be synced with the k-i's on which they depend.  Isn't this already done for things like pcmcia-modules?
<julietsierra_> sorry for butting in, but wrt ALSA versions, Jaroslav Kysela said this in an email on alsa-dev: "The alsa-lib 1.0+ should be compatible with ALSA driver code in 2.6 kernels. Of course, it's better to use last alsa-lib because of bug-fixes. This is true for drivers as well."
<hch_melb> umm, alsa is in the 2.6 kernels
<hch_melb> so it really shouldn't be separate modules
<julietsierra_> so versions should be compatible
<jdthood> julietsierra_: In practice there are differences, unfortunately.
<jdthood> Admittedly, not many of them.
<hch_melb> jdthood: so kick the alsa folks
<hch_melb> jdthood: all other drivers in the world are abi-compatible
<julietsierra_> yes, but they could be classified as bugs, let me see if I can find a lnk to that email
<hch_melb> linux-world, that is
<vorlon> jdthood: frankly, pcmcia-modules is already one of the more annoying bits to have to shuffle when kernels get updated.
<dilinger> vorlon: is that even necessary anymore?
* dilinger hasn't had the misfortune of using pcmcia lately, other than a cardbus modem which works fine w/ 2.6 drivers
<vorlon> the more key module packages we have that need to be rebuilt as part of kernel updates, the longer it takes to rev a kernel.
<vorlon> dilinger: necessary how?  Inasmuch as it is necessary, it's exactly the scenario jdthood is describing.
<dilinger> vorlon: i mean pcmcia-modules for 2.6
<vorlon> dilinger: we do have pcmcia-modules-2.6.8-2 binary packages
<dilinger> is there added benefit, or is it just legacy Hinds' stuff?
<hch_melb> vorlon: and with modern 2.6 pcmcia-modules doesn't make any sense at all anymore
<vorlon> shrug?
<hch_melb> vorlon: cardmgr will be dead in 2.6.11 or 2.6.12
<dilinger> \o/
<hch_melb> vorlon: and pcmcia stuff is really tightly integrated with the kernel now
<svenl> vorlon: unless we build them from a common kernel/module source package :)
<vorlon> hch_melb: don't look at me, I'm just the guy who tries to keep the bit-shuffling synced... :)
<julietsierra_> http://sourceforge.net/mailarchive/message.php?msg_id=9969716
<vorlon> hch_melb: design decisions are for you and the pcmcia-modules maintainers to work out.
<jdthood> Well, I am hearing that it is a PITA to keep *-modules synced with k-i, and that is something to take into account.
<dilinger> fuck me, i did it again
* dilinger uploads a hostap-source diff w/ .arch directories still in it
<vorlon> hch_melb: wait, sorry, this is pcmcia-modules-2.6.8-2-386-*di*, so doesn't apply.
<vorlon> but it's still an ongoing concern for 2.4.27.
<jdthood> vorlon: OK, I guess pcmcia-modules wasn't a good example.  What would be a good example of a *-modules package that has to be synced with k-i?
<vorlon> jdthood: pcmcia-modules *is* a good example, in terms of the difficulties in the 2.4 branch.
<vorlon> jdthood: the issues don't change at all for 2.4 vs 2.6, regardless of how the code might.
<dilinger> jdthood: i end up having to synch hostap-modules-i386 w/ k-i every once in a while.. but alsa is clearly higher priority
<jdthood> dilinger: I am drawing the conclusion that dropping ALSA modules from k-i may be a nice idea (for the reasons I gave) but is not practical because we don't have an easy way to keep -modules packages synced with k-i.  Agree?
<hch_melb> jdthood: it's not nice either
<dilinger> jdthood: correct.  the best we can do is allow them (and even recommend them) to be installed in parallel
<hch_melb> jdthood: but it might be nice if someone could follow alsa upstream and backport fixes
<hch_melb> jdthood: new big alsa updates often introduce more breakage then fixes
<svenl> jdthood: and because the current alsa-module build infrastructure doesn't care for non-x86.
<jdthood> svenl: If ALSA modules were removed from k-i then we would build alsa-modules for all arches.
<svenl> jdthood: and multiply by 11 the problems that where mentioned ?
<hch_melb> I still think it's a bad idea
<jdthood> svenl: Which arguments, exactly?
<svenl> jdthood: i think you should do it the other way around, first prove that you can build for all arches.
<hch_melb> stuff is QAed as part of the upstream kernels, and usually gets fixes ontop of the alsa merges
<svenl> jdthood: you are aware that all the 11 arches build kernels in a mostly anarchic way right now.
<hch_melb> alsa cvs is without all that fixing
<jdthood> hch_melb: That is interesting.  My impression was that ALSA cvs was merging fixes on a timely basis.

--=-4bFGWjDgRLC1YmgvS3pZ--