James Carlson wrote: > Darren Reed writes: >> James Carlson wrote: ... >>> 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.
It would seem that you really want to say "encrypt after compress and filter". The limit on allowing a single preference is to reduce the complexity of the implementation as well as the mistakes, but there's no reason why there can't be a list in before/after. The types of silliness I'm thinking of here is saying "i want to be last but before X". By taking the approach of requiring dependencies to exist when an insert is attempted, it solves the circular dependency problem of X wanting to be before Y and Y wanting to be before X automatically. So rather than try add code to deal with that, I was looking to just design that problem out. > 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. Yup, I can see that. > 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. Hmmm. And so far as this goes, there are other means that can be used to provide strong hints about whether X is present or not (such as the SMF service being present.) Hmm. > 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.) No. The packet events for inbound and outbound are not connected in any way, so if you say "before X" for inbound, you should say "after X" for outbound. > 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?" This depends on what you're trying to achieve. If, for example, you want to see the packet as it would be received/transmitted from/to the wire, then you need to be first for input and last for output. If, on the other hand, you want to see the packet before anyone else modifies it then you always want to be "first". Darren _______________________________________________ networking-discuss mailing list [email protected]
