Re: easy alsa patches for the stable kernel?

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.

However, there are special kernel trees out there which accept
backports. Linux distributors do backports, because they have the means
to do so.

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.

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. Maybe they are better in getting stuff ready in time before
merge windows open --- I don't know, I don't watch these subsystems.
Maybe they have less trouble with closed or nonexisting specs...?
--
Stefan Richter
-=====-=-=== =--= -=---
http://arcgraph.de/sr/
-
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/

Relevant Pages

  • kernel BUG at mm/slab.c:610
    ... I'm experimenting this kernel panic on 3 different ... I don't think this is related to buggy hardware ... Filesystem "hda1": Disabling barriers, not supported by the ... # ACPI Support ...
    (Linux-Kernel)
  • Re: PROBLEM: cannot get stable system since 2.6.28 kernel (amd64)
    ... Philippe> well, I don't really believe in hardware problem for two ... Philippe> older kernel, everything works like a charm, every time I ... Philippe> I haven't any "overclocking" settings, and every hardware ... # Device Drivers ...
    (Linux-Kernel)
  • BUG: soft lockup in 2.6.25.5
    ... hardware, ... Running CentOS 5.2 with a kernel.org kernel ... # PCI IDE chipsets support ... # Input Device Drivers ...
    (Linux-Kernel)
  • Re: [PATCH] xen: core dom0 support
    ... Despite all the noise made about kvm in kernel circles, ... For example, Xen manages to use new hardware virtualization features pretty quickly, partly because it doesn't need to trade-off against normal kernel functions. ... We end up mapping the event channels back to irqs and they are delivered as normal interrupts as far as the rest of the kernel is concerned. ...
    (Linux-Kernel)
  • PROBLEM: Unable to add subdirectory: Ooops in sys_add_file, called from kobject_register
    ... I got an Ooops while trying to load a little kernel module I wrote. ... The module's sysfs handling/initialization is based on ... and x86_64 hardware. ... # ACPI Support ...
    (Linux-Kernel)