>>>>> "Manuel" == Manuel Bouyer <bouyer@antioche.eu.org> writes:

    >> I'm trying to imagine what that would look like.  Would it be
    >> overkill if we introduced a 'payload' or 'in' variable in
    >> struct hook_desk;
    >> 
    >> /* * A generic linear hook.  */ struct hook_desc {
    >> LIST_ENTRY(hook_desc) hk_list; void (*hk_fn)(void *); void
    >> *hk_arg; + hookflag_t flag; };
    >> 
    >> 
    >> or would it be best for the flag to be global ?

    Manuel> Well, I have no ideas on this. I just can say that when I
    Manuel> looked at it, I saw it would touch a lot of code and said
    Manuel> "I'll do it later" :)

    Manuel> Would the generic hook subsystem be more usefull if the
    Manuel> caller could pass an opaque argument to the callees ? The
    Manuel> overhead is probably not a problem here, it's not a
    Manuel> critical path.

I imagine it would. Unless we wanted to multiplex the hook
infrastructure by writing wrappers for individual subsystems. 
(Eg: shutdown_hooks(), reset_hooks() etc. )

I guess the quickfix for now is Martin's suggestion to just paste in 
the shutdown parameters into the shutdown_hook callback functions. 


    Manuel> I have another issue with the way shutdown hooks work
    Manuel> currently (mostly related to raidframe, but other drivers
    Manuel> could probably have the same issue).  In short, some
    Manuel> subsystems want a powerhook to be called from valid kernel
    Manuel> thread context, before interrupts are blocked, to be able
    Manuel> to stop operations in progress that need a callback from a
    Manuel> lower subsystem to complete. This could be a second set of
    Manuel> powerhooks, or the same powerhook list called with 2
    Manuel> different parameters.

If they have to stop/flush at shutdown, wouldn't they have to do the
same at, say just before PWR_STANDBY ? In which case couldn't we
arrange to call those hooks before interrupts are blocked etc. ? 

Thanks,
-- 
~Cherry