[arch-dev-public] Kernel - vanilla vs patched?

[Thomas Bächler]

I was about to start this thread just this morning, but didn't have the
time. Here is what I think: The Arch way is to keep things as untouched
as possible and frankly, our kernel has become full of stuff that I
don't see a reason for.

* acpi-dsdt-initrd-v0.8.4-2.6.21.patch

My opinion on this one is unclear:
There have been tons of fixes to ACPI and the kernel developers claim
that this patch should not be needed, as the Linux ACPI implementation
is supposed to support everything out of the box. Right now, many people
who needed a custom dsdt years ago, still use it despite the fact that
they don't need it. However, there are _some rare cases_ where only a
dsdt can fix the problems. The majority of computers however should now
work without it.
What I definitely don't like about the patch is that the ACPI subsystem
has changed substantially since 2.6.21 - the fact that the patch still
applies doesn't mean it doesn't introduce unwanted and stupid behaviour,
or hidden bugs. None of us would know the problems the patch may cause,
as none of us knows anything about kernel/ACPI code.

* toshiba-bluetooth.patch

What does this patch even do? It has been sitting there since .21. What
is the reason this hasn't been merged upstream? 1) It breaks other
setups, which would mean we should remove it, 2) it has been merged in a
different way and still applies, in which case it will only cause bugs,
but don't fix any, so we should remove it or 3) it has never been
submitted, in which case it shouldn't be our responsibility to keep it
along while the author isn't even capable of submitting it.
In any of the above cases, we should remove the patch.

* usb-storage-unusual-devs.patch

I submitted this patch after I created it, so either 1) or 2) of the
above apply, so we should remove it as well.

* mactel-linux-2.6.23.patch

What does this patch even do? There have been Macbook patches sitting
around since .20 or so, and again: why aren't they merged upstream? Any
of the reasons for them not being merged imply we should remove them.

* http://www.archlinux.org/~tpowa/alsa-patches/alsa-20071109.patch.bz2
*http://www.archlinux.org/~tpowa/alsa-patches/alsa-include-20071109.patch.bz2

Why do we update alsa all the time, especially to non-released versions?
This may have been necessary, when a large number of chipsets were
broken, but I don't think that is still the case. Is there any specific
reasons we cannot stick with the alsa version that Linux provides?

* acpi-buggy-bios.patch

Like mactel, this patch has been there since .20 or so, the ACPI
implementation has had many changes, and it is more likely that it
introduces bugs than that it fixes any. Again, this patch should be
removed for one of the above reasons.

squashfs3.2-patch.bz2
http://download.filesystems.org/unionfs/unionfs-2.1/unionfs-2.1.8_for_2.6.23.1.diff.gz

Why are none of these merged upstream? Why do we have to add features
ourselves? I know we had problems with externally built unionfs, but
adding it in-kernel shouldn't be the solution, especially because it
results in more work maintaining.

* put_filp.patch
* lhash-2.6.22.patch

I don't know what these are, but these seem to be new bugfixes. Still,
it should be evaluated if they are still needed before they are added
again in 2.6.24.

* adjust_current_level_to_closest_available.patch

This is a bugfix that has already been merged for 2.6.24. This is an
example of how things should work. I discovered this bug on my notebook,
posted to the right mailing list and got a fix, confirmed it and now it
will be merged in the next version. So we only need to take the patch
along until the next version, and can then drop it.

hibernate-saa7134.diff

How long has this been sitting here? Again, the "why hasn't it been
merged" question should be asked, and the patch removed, most likely.

sata_sis-2.6.23.patch
ipw2x00-2.6.23.patch
zd1211rw-oops-2.6.23.patch
ide-helper-2.6.23.patch

I guess those are new, so again, we can keep them until .24, but they
should be fixed by then and our patches removed.

* linux-phc-0.3.0-kernel-vanilla-2.6.23rc3.patch

This is an extra feature. One that a small minority of people can use.
It is said to be unintrusive, but then, why isn't it in the upstream
version? If it is so unintrusive, the upstream devs shouldn't object to
adding it. So either it was never submitted or it was rejected for a
good reason.

# genpatches from gentoo
* 2405_hostap-netdev-type.patch
* 2525_usb-storage-nikon-d200-quirk.patch
* 2530_usb-storage-nikon-d40x-quirk.patch

What do these do? Why do we need them?

* pre-2.6.23.2.patch

Where does this patch come from? Where is it (not in our CVS)? The
2.6.23.y git tree shows no new patches since .23.1, so I would at least
like a comment about it.


My opinion is, we should remove most of the above patches as 1) we don't
know what bugs they may introduce, 2) they haven't been merged upstream
for a reason or 3) they have been merged but in a different way,
introducing two fixes for the same problem, and the one in the vanilla
kernel is most likely much cleaner.

It appears to me that tpowa often blindly adds patches that are
submitted, with the only condition that they apply and build.

I want to reduce the number of patches applied to our kernel, and I want
that any patch that adds a new feature or bugfix MUST be merged in a
future version. If a patch has never been submitted, it should be
submitted, if it has been submitted and rejected, it should be dropped.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 252 bytes
Desc: OpenPGP digital signature
URL: <http://archlinux.org/pipermail/arch-dev-public/attachments/20071109/1829db92/attachment.pgp>