[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Standardizing use of kernel hook scripts

The following message is a courtesy copy of an article
that has been posted to gmane.linux.debian.devel.kernel as well.

On Tue, Mar 24 2009, Frans Pop wrote:

> Hi all,
> I'm not sure whether this discussion should happen here (d-kernel + 
> selected interested parties) or would be better held on d-devel.
> If ppl think it would be better on d-devel, then please let me know and 
> I'll restart it there.

        I think this is best held on -devel, since a wider audience will
 benefit from this.

> =====
> For the past year and more I've been building upstream kernels without 
> using any Debian tools, by just calling the kernel's own 'make deb-pkg' 
> target.
> The maintainer scripts for the thus generated kernel image package don't 
> do anything but call hook scripts in /etc/kernel/{pre,post}{inst,rm}.d/.

        The new kernel package maintainer script will expand on
 this. The image packages do call run parts on
 In additions, the doc, source, and headers packages will call upon
 This means that hok scripts can take control at any of the maintainer
 script stages, for any of the packages produced by kernel-package.

        In the future, I'll extend this to 

> In general the kernel team should be aware that there _are_ other current 
> users of /etc/kernel/ hook scripts.

        Yes. And kernel-package has been doing so for a while, and
 intends to expand the usage.

> ===============
> My patch series for the upstream kernel contains roughly the following 
> changes:
> - some minor cleanup
> - a fix so that the arm kernel image gets found (use of KBUILD_IMAGE is
>   not completely standard across arches)
> - a way to pass maintainer script parameters to hook scripts (see below)
> - an option to specify a custom package version/revision
> - an option to use a different hook scripts directory from /etc/kernel
>   (I currently use /etc/kernel.custom to avoid my hook scripts to be
>   run when I install an official Debian kernel package)
> The last patch provides a general escape, but it would be nice if all 
> Debian kernel packages could use the same hook scripts. (/me dreams)

        Where are these patches?

> ======
> Parameters passed to hook scripts
> ---------------------------------
> Official Debian kernels (at least up to 2.6.26) and make-kpkg based 
> packages pass two parameters:
> - kernel version
> - $realimageloc$kimage-$version (/boot/vmlinuz-<kvers>)

> deb-pkg based packages only pass the kernel-version.
> AFAICT ltsp-client hook scripts use neither of these parameters.
> New initramfs-tools hook scripts uses the kernel version and includes a 
> hack that tests if $2 is defined to avoid running with pre-squeeze 
> kernels and make-kpkg kernels. Not ideal...
> There is legacy here which makes any transition hard. But given the 
> limited existing users of hook scripts I think we can essentially ignore, 
> but it would be good to agree on a standard for the future!

        There are more users of the kernel images than just Debian
 packages; and I do not think we can ignore an installed base without

> Is anything other than the kernel version really needed?

        Yes, since in the old days the image location could be changed,
 by passing a parameter to make-kpkg. I think this feature is used,
 since it was put into kernel-package by request.

> Maintainer script parameters
> ----------------------------
> Currently maintainer script parameters are not passed on to the hook 
> scripts, but IMO they could be very useful, for example: a bootloader 
> update only needs to be run on package removal, but not on purge.
> Given the previous point I think adding them to the parameters passed to 
> the hook scripts is not a good option. I therefore propose to instead 
> export them in a standard environment parameter. Proposal:
> 	export DEB_MAINT_PARAMS="$@"

        Hmm. That would mean that the first argument is the name of the
 script, then?

> Execution order of hook scripts
> -------------------------------
> Both initramfs-tools and ltsp-client currently just dump a script in the 
> hook dirs without any naming convention. If many packages were to do 
> that, chaos would be a guaranteed result.
> IMO scripts should have standardized names starting with numbers to 
> regulate execution order. Ranges should be reserved, for example:
> - early scripts 00-19
> - initrd generation 30-49
> - bootloader update 50-69
> - late scripts 80-99
> Use of new numbers by packages should probably be coordinated by the 
> kernel team.

        If this were to become policy, I would say _all_ stakeholders
 should be involved, not just the official kernel packages, and that
 means not shutting out end users who compile their own kernel image

> To conffile or not to conffile
> ------------------------------
> If I'm correct neither initramfs-tools nor ltsp-client currently defines 
> the hook scripts as conffiles. This is both good and bad.
> - good: the hook script are removed when the package is removed which
>   avoids the problem that it could get run after removal, but before purge
> - bad: user changes in the scripts get lost on package upgrades
> IMO all hook scripts should be conffiles so user changes get preserved. 
> But that means that they need to include a check (existence of main 
> package binary for example) and exit 0 if the package was removed but not 
> purged.

        Anything in /etc is a configuration file, and thus policy
 dictates user changes must be preserved. This is nothing special;
 policy must be followed here, as in any other package.

> Allow user to control execution of hook scripts?
> ------------------------------------------------
> There can be various cases where this could be useful. Example would be 
> that it's pretty bad if you have two bootloaders installed (grub and 
> lilo) and both have hook scripts that get run. Some standard mechanism to 
> disable a particular hook script could be useful.
> More advanced would be to allow to run hook scripts based on type of build 
> system used: official Debian kernel, make-kpkg, deb-pkg, ...
> This could be done by exporting some envvar that indicates the "source", 
> which would also remove the need for the abovementioned hack i-t uses now 
> (absence of the envvar would mean "legacy").
> Some standard for progress output/verbosity?
> --------------------------------------------
> It could be useful to provide some guidelines about when and how to 
> display progress info. As could a general "verbose" option for debugging.
> Basic infrastructure
> --------------------
> I think some package will need to provide some basic infrastructure:
> - general config options for all kernel hook scripts (see previous point)
> - install a README explaining the use of kernel hook scripts
> - provide a very early postinst hook that runs 'depmod -a <kvers>'; I'm
>   not sure how else that could be provided
> - possibly be responsible for creating/updating symlinks, although that's
>   always a tough one as you might want symlinks updated for official
>   kernels but not for custom built ones (or use different symlinks for
>   custom kernels); the suggested "source" envvar could help there
> - provide a shell library file with functions to implement some of the
>   ideas mentioned above

I am a man: nothing human is alien to me. Publius Terentius Afer
Manoj Srivastava <srivasta@acm.org> <http://www.golden-gryphon.com/>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Reply to: