Re: A modest proposal -- We need a patch penguin

Andreas Dilger
2002-01-29T22:25:13Z

On Jan 29, 2002 22:56 +0100, Andi Kleen wrote:
> Alan Cox <alan@lxorguk.ukuu.org.uk> writes:
> > Lots of the stuff getting missed is tiny little fixes, obvious 3 or 4
> > liners. The big stuff is not the problem most times.
>
> "Most times". For example the EA patches have badly failed so far, just
> because Linus ignored all patches to add sys call numbers for a repeatedly
> discussed and stable API and nobody else can add syscall numbers on i386.

But at times, keeping things external to the kernel for a good while isn't
a bad thing either. Basically, once code is part of the kernel, the API
is much harder to change than if it was always an optional patch.

For example, the EA patches have matured a lot in the time that they have
been external to the kernel (i.e. the move towards a common API with ext2
and XFS). Even so, the ext2 shared EA on-disk representation leaves a
bit to be desired, because it is only useful in the case of shared ACLs,
and fails if you add any other kind of EA type. See discussions on
ext2-devel for more information.

Similarly, my ext2 online resizing code was (and is) just fine, but when
I implemented the ext3 online resizing code (not yet available) I realized
I needed to change the on-disk format of some structures and this would
be much harder to do if it was part of the official kernel.

Like Ingo was saying, having to look over your code for a while also helps
it mature, and gives you some leeway to change it. That said, there is
also a benefit to adding code to the kernel, as it increases your user
base a LOT, and no code that is external to the kernel can be considered
as mature as that which is included into the kernel, I think. Drivers
may be an exception, because either you need the driver or you don't,
and people have little way of testing a driver if they don't have the hw.

Cheers, Andreas
--
Andreas Dilger