Darren Reed writes: > James Carlson wrote: > > 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".
I want to say that along with "filter before compress," yes. > 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. Yep; I understood why that was done, and it seemed entirely reasonable to me. The issue I'm pointing out is that the usage-case is a little unclear to me, so all sorts of possibilities and up being "reasonable." It's hard to pick one that's obviously "right." I won't complain if you settle on some set that make sense to you, but I'd suggest writing something into the design that documents what sort of usage cases you were assuming. If projects come along later that have different assumptions, then the set of HH_* values may need to change. Noting what was intended will help. > 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. Yep; understood. > > 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.) That's another dimension of it that I hadn't considered. Yes, if the hooks are installed by SMF, then sequencing them and dealing with dependencies becomes "easier." It's not so clear what you'd need here ... but it's possible that some ordering constraints might be needed anyway because the SMF dependencies end up _not_ translating correctly into ordering requirements. For instance, a packet filter used for security purposes will probably want to be installed (temporally) before anything else happens -- clamp down the hatches first for security reasons. The service would depend on few things, and the world will depend on it. But that doesn't necessarily mean that we want the filter first on the list. It _might_ need to be last, as with the inbound filtering hooks. > > 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. Ah, right; they're separate hooks. I get it now. > > 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". It sounds like the dependencies lead into a set of classes -- "I modify packets," "I need to be near the wire with unmodified packets and I don't modify them," "I have to be near the user's data." Maybe. ;-} -- 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]
