Darren Reed writes:
> James Carlson wrote:
> > I think it's likely that clients will need to be able to go from a
> > given netid_t to some sort of internal state structure. That's the
> > one where I see potential usage trouble.
>
> Ok; I've added "net_data_t hpe_family" to hook_pkt_event_t
> which serves the same role as "net_data_t hne_family" in
> hook_nic_event_t.
OK.
> > What you're suggesting seems like a bit of a trap. I can add X and
> > remove it with no trouble. I can add Y and remove it. But if I add X
> > and Y, and then try to remove Y, I'm now stuck and am forced to remove
> > X.
>
> Actually no, and I can't believe I didn't mention this -
> at least in net_hook_register().
> If a hint cannot be satisfied at insertion time, the
> registration fails. If X must be before Y and there is
> a hint asking for this, then if Y isn't there, registering
> X will fail.
Well, it sounds like that's the core of the issue. The sorts of
dependencies you're envisioning are quite different from the ones I
can picture.
To come up with a usage model for "dependencies," I was picturing the
following three as examples:
- compression
- encryption
- filtering
Pretty obviously, I don't want to compress after encrypting -- I'd end
up with near zero compression if the encryption is any good at all --
nor do I want to try to filter encrypted bits.
If I were adding plug-ins to handle these things, I'd want the order
of operations on output to work as:
filter -> compress -> encrypt
and on input as:
decrypt -> decompress -> filter
The scheme you're providing allows me to say "filter before compress"
as well as "compress before encrypt," but, unfortunately, does not
allow me to say "filter before encrypt." I get that effect if
compress is present, but if it's not, I can't specify it, because the
rule allows only one other module to be specified as a dependency.
Importantly, in this example I don't really have any "run-time"
dependencies. In other words, if the compress/decompress plug-in
disappeared, none of the other plug-ins would care. All that really
matters is that they're installed in the right order _when_ they're
there.
I read through the documentation you provided and came to a different
set of conclusions about what it was doing. I can't really picture
plug-ins that depend on each other in the intimate ways you're
suggesting -- any depending on the internal state of others -- so I
don't know what to make of that. I think some concrete examples would
help.
As an aside, I think that brings up a separate set of questions. The
dependencies seem to be in reference to the transmit side of the path,
is that correct? Should the plug-in author assume that the receive
side of the path is always an exact mirror of the transmit path?
(That is, if transmit goes through A->B->C, then receive goes through
C->B->A.)
Or are there cases where that would not or should not be true? Are
there instances where "first" actually means "I want to be first on
both transmit and receive?"
> I think I'd call this a "strong binding" behaviour and
> one where a hook was allowed to disappear (when it has
> dependents) "weak binding." For now I'd like to concentrate
> on "strong binding" and come back to something that allows
> for "weak binding" (where you might have a callback to
> inform you that your dependency is now broken.)
The only problem I see is that I can imagine what "weak binding" would
be used for, and I can't imagine using "strong binding." Though maybe
I'm not trying hard enough. :-/
--
James Carlson, Solaris Networking <[EMAIL PROTECTED]>
Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
_______________________________________________
networking-discuss mailing list
[email protected]
