Kernel capabilities (Was: Kernel-package, fix version 2 ...)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Sat, 22 Oct 2005 08:36:50 +0200
Sven Luther <sven.luther@wanadoo.fr> wrote:
[regarding kernel-package becoming smarter at picking ramdisk-tool]
> In any case, i think the best idea would no more be to make a hard
> choice, but maybe use some kind of heuristic, or even make it
> configurable at package build time, so that it can be overiden. I
> need to think about this a bit more.
I think it is bad to put this intelligence into the package postinst
(as is currently the case as I understand it).
Instead, have the kernel packages only declare some "capabilities", and
let a separate kernel-install-helper deal with the actual install.
This ended up being a quite long email - it took me all day to write.
If response is positive it would probably make better sense to post it
on the wiki, but perhaps I am silly and you've already discussed (and
turned down) things like this long ago...
Let's for a moment assume we are dealing not only with linux-2.6,
but the following source packages:
linux-2.4
linux-2.6
hurd
kfreebsd-5
Our current ramdisk handling only relates to linux-2.6 (and linux-2.4
if anyone wanted to do maintain that) but other capabilities like
netboot support may be relevant across kernel types.
My point here is I want a tool that is generic across (Linux and
non-Linux) kernels, and usable for ramdisk generators, bootloaders and
other tools dealing with kernels. Even if right now we want to solve a
linux-specific, ramdisk-tool-specific problem.
A concrete example in the not-so-distant future (based on a true story
on #debian-kernel yesterday): Sesse wants to upgrade his machine to
2.6.15. He uses EVMS and is currently running 2.6.12.
Announcing kernel capabilities
- ------------------------------
The package linux-kernel-2.6.15-1-k7 includes the following file:
/boot/linux-2.6.15-1/kernel:
linux-initramfs
linux-sysfs
ext2fs
linux-devmapper
ext3fs
Third-party module package (and perhaps later on: module packages
generated from linux-2.6 source) can add their own files in same dir.
Perhaps later it would make sense to move module capabilities like
linux-devmapper and (for x86 but not powerpc) ext3fs out to a
separate /boot/linux-2.6.15-1/kernel-modules, so tools like braindead
bootloaders can query builtin capabilities instead of only
builtin+modular ones. But that's another story...
Installing the kernel
- ---------------------
The package linux-kernel-2.6.15-1-k7 recommends "kernel-install-helper".
In postinst the kernel package invokes "kernel-install-helper" to take
care of whatever it takes to finalize the kernel installation -
selecting a ramdisk, install/update bootloader, wrap kernel itself
(needed for some bootloaders and used to be needed for use with
etherboot).
If kernel-install-helper does not exist the postinst simply falls back
to old-style builtin script.
Selecting ramdisk tool
- ----------------------
The first implementation of kernel-install-helper does exactly the same
as proposed for kernel-package v2 (order reversed here compared to
earlier discussion):
1) If ramdisk=[colon-seperated list of tools]: try them one by one:
a) If tool does not exist, skip to next tool
b) If tool does not accept host and target kernels, skip to next tool
c) Use tool blindly. If tool fails, fail with error
d) if no tools left, fail with error
2) If ramdisk=[a single tool]: use tool. If tool fails, fail with error
3) If ramdisk=[undefined]: use builtin list and do like 1)
That's v1 of the implementation. Let's start with that!
Second implementation do similar, but instead of the current "run if
acceptable with this host and target kernel versions", it first queries
all tools for a list of supported/required capabilites of both host and
target kernels. Yaird would respond that it requires
"linux-initramfs,linux-sysfs" for both host and target kernels (which
equals kernels since 2.6.8), and that it supports
"ext2fs,ext3fs,xfs" (but not yet linux-evms). initramfs would respond
(I guess) that it requires nothing for host kernel but
"linux-initramfs,udev" for target kernel (or whatever is the reason
behind the current 2.6.12 restriction).
So adjust the logic for v1 with following change to case 1b:
b) Query tool for --{supported|required}-{host|target}-capabilities
I) If query fails: Use tool with --supported-{host|target}-version
II) If query returns negative: Skip to next tool
III) If query returns positive: Use tool
As soon as all (2!) tools that currently support host/target version
restrictions have switched to supporting the query mode, we can drop
case 1bI. But if Jeff and Maximilian for some reason choose to add
version restrictions but refuse to support capability querying then we
just leave it support for both.
We probably soon want some enhancements - like a "keep-trying" option
for case 1c, or interactive choice of ramdisk tool (like dictionaries
today) if more than one i valid. But the above should be possible
without any changes to the current documented format
of /etc/kernel-pkg.conf and - important! - without too much coding, so
let's keep it at that first.
Oh, and off course the kernel-install-helper package should take over
ownership of /etc/kernel-pkg.conf, with debconf support on the TODO
list ;-)
Using capabilities
- ------------------
So, would all these changes lead to succes for Sesse?
Well, assuming EVMS requires only the Linux devmapper and
initramdisk-tools was either explicitly chosen by Sesse or "elected" by
the kernel-helper-tool, then yes.
If both yaird and initramfs-tools installed then yaird would be favored
due to its kernel-version support, try to run, but fail. The frustrated
Sesse would then (as he actually explained on IRC that he tried)
uninstall yaird or explicitly choose to use initramfs-tools and it would
work as above.
A little down the road then...
1) kernel-install-helper would add "required-capabilities"
to /etc/kernel-pkg.conf
2) An updated evms package would suggest Sesse through debconf to add
"linux-devmapper" to the list of local required capabilities
3) kernel-install-helper would pick initramfs-tools because yaird
considered linux-devmapper an unknown (and thus unsupported) target
capability
Or...
1) A newer yaird would make use of its build-time probing in the
wrapper and include "unknown-filesystem" as an (always impossible)
requirement when it fails to parse /etc/fstab
2) kernel-install-helper would pick initramfs-tools because yaird
includes "unknown-rootfs" as target requirement
If EVMS still (as it says in the long description of the package)
requires a kernel compiled with kernel-patch-evms applied then Sesse
would need to manually add a new file /boot/linux-2.6.15-1/local
containing the single word "linux-devmapper".
A little down the road then...
1) Kernel patch packages would hint about added capabilities
1) kernel-package would recognize and include kernel patch package
capability hints
- Jonas
- --
* Jonas Smedegaard - idealist og Internet-arkitekt
* Tlf.: +45 40843136 Website: http://dr.jones.dk/
- Enden er nær: http://www.shibumi.org/eoti.htm
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
iD8DBQFDWqoCn7DbMsAkQLgRAmgSAKCI36WyTajWZF301xVI+ofYbMbrKwCeInp4
1FVL+gkdg21CMMP68FFalcw=
=pjO4
-----END PGP SIGNATURE-----
Reply to: