[arch-dev-public] [Fwd: Re: [PATCH] Implement a hook-system that allows to add custom code to the initscripts at certain places]

[Thomas Bächler]

Full-quoting, as your mail didn't go to the list.

Michael Towers schrieb:
> 2009/8/25 Thomas Bächler <thomas at 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
> 




-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 260 bytes
Desc: OpenPGP digital signature
URL: <http://www.archlinux.org/pipermail/arch-dev-public/attachments/20090826/af5afa28/attachment.pgp>