-------- Original-Nachricht --------
Betreff: Re: [arch-dev-public] [PATCH] Implement a hook-system that
allows to add custom code to the initscripts at certain places
Datum: Wed, 26 Aug 2009 15:10:16 +0200
Von: Michael Towers <larch42@googlemail.com>
An: Thomas Bächler <thomas@archlinux.org>
Referenzen: <4A93C509.7060505@archlinux.org>
<4A93C694.3030401@archlinux.org>
<ed5b1830908260446o4cd75196s617baf1a3dd68db4@mail.gmail.com>
<4A95255D.2080507@archlinux.org>
2009/8/26 Thomas Bächler <thomas@archlinux.org>:
Full-quoting, as your mail didn't go to the list.
Michael Towers schrieb:
2009/8/25 Thomas Bächler <thomas@archlinux.org>:
Thomas Bächler schrieb:
A function add_hook can be called from functions.d to register a hook
function. The existing hooks are based on suggestions from Michael
Towers
(larch) and on the implementation of initscripts-extras-fbsplash which
currently uses the strings passed to stat_busy and stat_done for this.
More
hooks can be added if requested.
Forgot to mention this in the commit and the first mail: the hook
function
names should be prefixed by something to make them unique, for example:
add_hook premount larch_premount
If larch would decide to add a "premount" hook.
I've had a look at this now and find it basically a pretty good idea,
though I think I slightly prefer my suggestion.
Hmm, your suggestion required an extra file per hook and wouldn't allow
several parties to register code for the same hook. That's what I didn't
like.
This just seems a
little too complicated, but I have a couple of ideas for simplifying
it a bit. Mainly I'm not so sure about passing the script name as
argument and having hooks with the same name (e.g. 'start') in several
rc. files. That means that if I write a hook function for 'start' I
must always test that the call came from the correct rc. file.
Correct. The idea came up because if I have a "prekillall" hook, users like
fbsplash would want to hook up code regardless of whether it is caled from
rc.shutdown or rc.single, while other users would only want to use it from
rc.shutdown. This was part of my first approach.
With the new approach, I could have a hook shutdown_prekillall and
single_prekillall and just register the same function for it:
add_hook single_prekillall my_prekillall
add_hook shutdown_prekillall my_prekillall
So this is obsolete now, and I agree that renaming the hooks to be unique is
a better idea. If I don't receive a patch for that until tonight, I will do
it then.
Wouldn't it be simpler to give each hook a unique name, even if it has
to be something like 'start_shutdown'?
I will use the convention $FILE_$HOOKTYPE if that is alright, like
"sysinit_start" or "shutdown_poweroff".
That would be nearly the same
as what you are suggesting, but the hook functions would not have to
test the argument.
I also have a further suggestion for simplification - the
predeclaration of the hook names in the 'functions' file:
for hook in start end udevlaunched udevsettled premount prekillall
postkillall poweroff; do
hook_funcs["${hook}"]=""
done
is not necessary. Bash arrays return empty strings for undefined
indexes too. This has the great advantage that when a new hook is
added you wouldn't have to edit the 'functions' file.
I still would have to add a comment in 'functions', but I agree.
Apart from that it seems quite attractive, if you are determined to
keep it all as scripts in functions.d.
Yes, I don't want to add extra directories, functions.d can serve several
purposes quite fine. And if you like, your hooks can just be wrappers that
will call scripts from other places.
Anyway, I'm glad that this is an approach you are willing to work with, and
I hope fbsplash will also adopt this instead of parting $1 in stat_busy and
stat_done.
Can you give suggestions regarding the hook names (I still find some of them
sound weird) and comment on whether more hooks are needed, or some of them
are badly placed?
Regards,
mt
It sounds like my wishes will be well satisfied now! As to the names,
it's not something that seems terribly important to me. I try to
comment my code anyway and so it wouldn't even be a disaster if they
had names like x23_ooo_aaah (ok, I'm exaggerating, they should
probably make some sort of sense). I also can't say much about their
placement in general or suggest further places as I have only really
thought about the places the current larch design would use, and you
already have those. I guess you got the others from fbsplash. Maybe at
the beginning there shouldn't be too many - it would be easier to add
a new one than to move an old one (which somebody might already be
using).
Maybe briefly the reasons I requested this for larch. In a live system
it is helpful to have a bit of flexibility in the way the system is
started, the root filesystem is mostly aufs (etc.) and what should
appear in /etc/mtab is probably not the same as in a non-live system,
also what should get mounted or entered in fstab might well change
from boot to boot (from machine to machine). There are other points at
which this can be done, but via a hook in rc.sysinit seems cleaner to
me. As to rc.shutdown, the main need in larch is caused by session
saving, which is probably cleanest/safest when carried out towards the
end of the shutdown process. With CDs there is also the question of
ejecting the device, which must also happen right at the end. Up to
now I have used modified rc.sysinit and rc.shutdown scripts to achieve
this, which means editing them every time initscripts is updated -
rather annoying.
Thanks for your interest and work,
mt