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

[Dan McGee]

On Nov 9, 2007 7:45 AM, James <iphitus at gmail.com> wrote:
> Lets look at this differently. To put it lightly, editing the kernel26
> pkgbuild to add/remove things, can be daunting for most or annoying to
> do every release. This is why they want us to do it.  Why don't we
> make the kernel26 PKGBUILD a bit more adaptable/friendly?

YES YES YES! Thank you for bringing this up. For that matter, I tried
and failed at this because we use too much damn magic in our PKGBUILD!

I've custom compiled my own TRUE vanilla kernel for one of my boxes,
and I didn't use this PKGBUILD because it is just way too hard to
decipher. Can someone please clean this up? I don't care if we have a
select group of devs that are our "kernel maintainers"- it shouldn't
take a rocket scientist to change this PKGBUILD and know what is going
on.

Why is there a 'yes "" | make config' in there? What is this sed
EXTRAVERSION line? Do we even need the System.map file anymore? Add
headers for lirc package, wtf? dm headers, inotify, blah blah, blah.
This is a ridiculous PKGBUILD that two people know what is going on,
and that is unacceptable.

On Nov 9, 2007 8:59 AM, Thomas Bächler <thomas at archlinux.org> wrote:
> 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.

dmcgee at dublin /var/abs/core/base/kernel26
$ ls | wc -l
38

Wow. I agree that this is getting out of hand. We need 38 files to
build a "vanilla" kernel? As I said above, what happened to the
make/make install concept?

> * acpi-dsdt-initrd-v0.8.4-2.6.21.patch
>
> 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.

And if it hasn't been merged upstream, then there is an issue here.

> * toshiba-bluetooth.patch

Die.

> * 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?

I agree with Thomas here.

> * 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.

Die.

> 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.

Document these patches please.

> 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.

Agree.

> 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.

<sarcasm>Glad that it got added without much discussion.</sarcasm>

> # 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.

I agree with Thomas' sentiment here. We seem to be deviating from our
own "strictly vanilla" kernel rules a bit too much. At every major
kernel release, *every* patch should be reviewed and a decision made
on future inclusion. I'm not asking for an all-dev vote here or
anything, as that would be stupid, but I am asking for more than one
person to decide.

I don't mean to come across as critical here, as I appreciate you guys
maintaining the kernel. But I think we need to continuously improve
what we do, and this is one of those areas we could do that in.

-Dan