Re: easy alsa patches for the stable kernel?

[Thorsten Leemhuis]

On 08.09.2007 19:49, Stefan Richter wrote:
> Thorsten Leemhuis wrote:
>> On 08.09.2007 01:38, Takashi Iwai wrote:
> [backports to -stable]
>>> Linux will suck really if one breaks so-called stable thing easily
>>> without actually testing.  For stable stuff, "it should be good" isn't
>>> enough.  It must be: "it IS good."
> This applies (or should apply...) to everything that goes to Linus in
> his pre -rc1 merge windows.  To post -rc1 submissions and even more so
> to -stable submissions, additional criteria apply.

Sure -- but new PCI-IDs for ATA-controller these days get added to
linus-tree post-rc1. They even find their way into the stable-tree since
some weeks now, and I think that's really good (due to one of those
patches my PATA-Controller in my 2 1/2 months old Laptop simply works
now and I don't have to wait until 2.6.23 is out).

But similar easy-and-small patches for the sound drivers (Â) take way
longer to get into the kernel.

(Â) -- like the patches I linked to earlier in this thread that add a
dmi-entry for another machine to the whitelist of machines to apply a
know workaround on. Or the regression for my laptop:
http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=a4eed138add1018846d17e813560b0c7c0ae8e01

> [...]
>> Linux IMHO will suck even more if crucial pieces of hardware does not
>> work for people easily, because Linux won't get even used then and will
>> frustrate people.
>>
>> Don't get me wrong; I understand and agree mostly to the points you
>> raised. But we nevertheless need to find a way to make todays hardware
>> usable more quickly, as that hardware is often on the market only for
>> some months or a year until the successor-model replaces it (which might
>> need new drivers or workarounds) --
> In the end there is but one solution to this:  Open specs.

Sure, I suppose most of us will agree on that.

But "open specs" is only part of the solution -- in and ideal world
users IMHO should have *easy* access to the proper drivers immediately
when the hardware becomes available. And that involves multiple layers IMHO:

1. hardware vendors need to open their specs before the hardware becomes
available (some like Intel for their ATA-Stuff do that afaics); hardware
also needs to be available for testing soon enough as well in case the
hardware-vendor is not the driver author at the same time (like in the
intel-case)

2. kernel developers need to have a workflow where at least small and
easy driver enhancements (e.g. those that just add a new PCI-IDs or
similar stuff like the extend list of machines to apply known workaround
on) make it quickly out into a officially released kernel. (Even bigger
driver updates IMHO need to get way quicker to the users, but that's a
more complex topic as there the risk of breaking something is bigger)

3. Distributors need to pick those kernels up and provide them to the
users. If they don't want to ship completely new kernels they need to
cherry-pick the improvements -- that's a lot of work and for the
distribution-kernel-maintainers if the maintainer of the driver in
question does not provide informations if a patch should be safe even
for older kernels; the interdependencies with other parts of the kernel
make it more complicated.

Point "3" is solved for me, as Fedora regularly ships new stable- and
linus-kernels during the life-time of a Fedora release (for other
distributions you are often out of luck and you have to use the
devel-tree, as only those get new kernels, but that's a different
discussion). But that doesn't help much if even a in-time
one-liner-pci-addition-patch from the vendor ("1") get stuck in area "2"
for weeks or months.

>> but it sometimes even for small
>> alsa-fixes takes as many months to make it from the developers out to
>> the kernel and from there to the distributions the user uses.
>>
>> It works better in some areas of the kernels (SATA and Network drivers
>> come to my mind) where patches make it quicker into the linus- and
>> stable-kernels -- in parts that is due to better cooperation with the
>> hardware-vendors, but it seems the sub-tree maintainers have a better
>> patch-/workflow, which has a strong impact as well.
> Feature additions to SATA and networking, e.g. support of additional
> hardware, are not backported to -stable or merged post -rc1 either, I
> presume. 

They are -- no many, but a few, and that's a good start IMHO:

=== linus

2.6.23-rc1 was on "22 Jul 2007"
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=f695baf2df9e0413d3521661070103711545207a

The we had things like

Wed Aug 15 02:53:39 2007 -0400 sata_mv: PCI IDs for Hightpoint
RocketRaid 1740/1742
http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=cfbf723eb7928879292ee71fa0d118fc4e37b8c9

Wed Aug 22 14:28:02 2007 -0700 USB: resubmission unusual_devs
modification for Nikon D80
http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=83fc8a151beda2d63e196a7ab2e12316c37a1e91

Fri Aug 31 03:48:49 2007 -0400 ata_piix: IDE mode SATA patch for Intel
Tolapai
http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=c5cf0ffa71d32c03607d287b76483479afb0bcd3

Fri Aug 31 04:00:19 2007 -0400 pata_marvell: Add more identifiers
http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=d36ee189f392ea89de85124a0b58477bb0f2e0a6

=== stable 2.6.22.y

Wed, 22 Aug 2007 23:23:26 +0000 (16:23 -0700) libata: add ATI SB700
device IDs to AHCI driver
http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.22.y.git;a=commit;h=3443d563dc53875b15d919c4bece391f1ffd4776

Wed, 15 Aug 2007 16:25:10 +0000 (09:25 -0700) pata_atiixp: add SB700 PCI ID
http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.22.y.git;a=commitdiff;h=fd2efeae63567dde934bb54772bb1b991275b04a

Thu, 9 Aug 2007 21:27:26 +0000 (14:27 -0700) Add a PCI ID for santa
rosa's PATA controller.
http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.22.y.git;a=commit;h=a03cf181b9c19b4e95d847cd394c7ffaf5109d06

> Maybe they are better in getting stuff ready in time before
> merge windows open --- I don't know, I don't watch these subsystems.

Well, hardware gets quickly from development over production info the
marked and we IMHO need to be quickly as well if we want to support
todays hardware and not only yesterdays.

> Maybe they have less trouble with closed or nonexisting specs...?

Hehe, I'd say you should consider yourself lucky for the OHCI-standard
in the FireWire space -- that makes sure you don't have to deal with
PCI-ID-additions. ;-) And workarounds for specific controllers seems to
be seldom in that area as well (but often needed for sound-drivers these
days; and I had wrongly thought HDA would put that to and end...)

CU
knurd
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/