Darren Reed wrote:
> Even if you did, what do you know except that there is another name
> in the queue somewhere?
A module may decide not to register a hook or may decide
to register the hook at a different position.
> 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.
While there is no "authority" in maintaining the name
stability, it does not mean that the names are unstable.
For example, as stated above the IPFilter names will be
stable. A module may decide not to register a hook when
IPFilter hooks are there.
> So does this make it useless? No.
We should also ask if this makes it less useful. I think it
is less useful. Is there a technical problem if we provide
this hook registration info?
> 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...
I think this is just a bug in the user of the mechanism
and is not a problem of the mechanism. Without it, I'm
afraid that some modules will not work properly while they
think that they are working as designed and no one can know
about it.
--
K. Poon.
[EMAIL PROTECTED]
_______________________________________________
networking-discuss mailing list
[email protected]
