Kacheong Poon wrote:
> ---
> * providing information about what hooks have been registered for events
>    and related statistical data.
>
> ...
>
> A hook is limited to specifying only *1* hint for itself.  If either the
> "before" or "after" hints are used, the hook specified by the name supplied
> with the hint *must* already exist on the hook chain associated with the
> event.
> ---
>
>
> If there is not a mechanism for a module to find out what hooks
> have been registered, how does a module use the before or after
> hints?  Is it assumed that somehow the module will know the
> names of other hooks in the chain?
>   

Even if you did, what do you know except that there is another name
in the queue somewhere?

Unless the names given to hooks are assigned a particular stability,
and this is something I'm considering for at least IPFilter in Solaris,
using a name in a static manner can lead to trouble.

So does this make it useless?  No.

If I have two separate products and there is a dependency between
them, I can express this here, as well as via other mechanisms (such
as in the pkginfo file), providing surety about who is called first/second.

> ---
> Example 1.
> If hook A is registered for event E first, and asks to be placed first
> on the list, then this will be done.  If a later hook, B, is registered
> for event E, it may either ask to be placed before A or to be placed in
> the first position.  In satisfing either of these requests, the initial
> hint is no longer true - hook A is now second.
> ---
>
>
> Can there be a mechanism to notify the owner of hook A
> that its position is now changed after hook B is registered?
> Then the owner of hook A can decide if this is OK.  If not OK,
> it may notify the user that A may not work properly now and
> some actions are needed.
>   

What I'm wary of is if that mechanism exists, A may decide to unhook 
itself and
reinsert itself at the front, upon which B gets an event and does the 
same, leading
to A.... and so on - like a kitten chasing its own tail...

Darren

_______________________________________________
networking-discuss mailing list
[email protected]

Reply via email to