Re: Packaged Kernel

Kevin Lentin (kevinl@cs.monash.edu.au)
Thu, 23 Jan 1997 17:16:51 +1100 (EST)


Michal Ostrowski Wrote ...
>
> Now I'm not advocating that we split everything up into tiny pieces, that
> may simply not be feasible especially with regards to applying patches (I
> certainly wouldn't want to go around trying to find individual
> patches for each of my device drivers), but something needs to be done.
>
> Perhaps what is needed is tighter controls on which drivers are included
> in the kernel (ie: based on how many people use them), and consideration
> for how one can include drivers not in the main source tree easily (with
> minimal patches to kernel source files).

How's this for an idea. IT could be done by some enterprising people and
wouldn't require the kernel developers to do much (or anything).

- write a script that untars and retars the kernel. Use some useful split
(eg, separate architecture stuff and then maybe some selected subdirs -
drivers/net, drivers/scsi, drivers/isdn, etc could be split, if they're
big enough). It's not important how it's split. Nor is it important that
the split remain constant over time.

- someone volunteers to download kernels when they get posted, split them
and then re-upload them somewhere. This could be done automatically as
part of a mirror.

- write a small front end to patch that will only apply patches in
directories that are present. Or maybe have a config file that lists
directories to include or exclude. You'd have to be careful about new
subdirs that get added - that's which I like the 'directories to exclude'
stuff.

Advantages:
- No hassles for Linus, et al
- The split and the patching are separate so the split can change from
version to version or with time without affecting patch's ability to
operate.
- Don't split up patch files so it's still easy to keep up to date.
Otherwise you'd need a full set of subdirs and tar files and who knows
what other nonsense to keep your patches up to date. And you run the risk
of parts of your kernel not being patched.
- If you suddenly require a 'module' that you didn't need before, you just
download the latest version of that module and continue.
- Only requires 2 straightforward programs and sometime to download/upload
and sites to house them (this scheme almost exactly doubles the space
needed to store kernels - sans patches. No change in storage for
patches).
- split is:
tar -zxf filename
tar -zcf subfile subdir
tar -zcf subfile subdir
tar -zcf subfile subdir

or
tar -zxf filename
for i in `cat subfiles`
do
tar -zcf $i $i.tar.gz
done

- patch is a little more complicated but could be achieved with a small
awk script that had a rudimentary understanding of unified diffs and
stripped out unneeded ones based on a list.
You can already achieve this using the '-f' or '-t' options to GNU
patch but you start losing control over the patch process to a small
degree when errors turn up. But it could be a start.

So: the whole thing can be done in a half dozen lines of shell script and
one arg to patch. Well, an initial stab at it.

-- 
[======================================================================]
[     Kevin Lentin               Email: K.Lentin@cs.monash.edu.au      ]
[   finger kevinl@fangorn.cs.monash.edu.au for PGP public key block.   ]
[  KeyId: 06808EED    FingerPrint: 6024308DE1F84314  811B511DBA6FD596  ]
[======================================================================]