bJames Carlson wrote: > 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.
Hmmm. At present specifying the preference requires knowledge of the name of what you want to be before/after. If we get into classes (as you alluded to), then things change and the above becomes possible in a generic kind of way. I suppose the question becomes should the current design be morphed into something that reflects classes? I'm not convinced. The primary objection I have is that it assumes we can classify everything into a specific bucket now. I don't know how to classify what others want to do and I'm reluctant to try and decide for them. There's also the question of ordering between things that say they are of the same class(es). > ... > 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." The primary usage case (from ISVs) that is on the plate at present is being able to specify a hook as being before/after ipfilter. > 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 more I think about this, the more scope I see for lots of scope for future evolution here in the ordering hints, if not the hooks themselves. For example, if you wanted your firewall hook to be before any/all hooks that did compression, then that seems to imply a hook advertising that it has that property (performing compression) and being able to specify an ordering preference that includes reference to that property. Or class. I don't see this work as being the final work in this space for OpenSolaris, but rather the next step. I suspect it will need to continue evolving in the years to come as more people use it and want to extend it. > ... > 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. Indeed, but it does allow later things to say if the firewall service is enabled then the firewall hooks must exist, so should be able to successfully load something that has a hook saying "put me before the firewall." So with SMF dependencies, you should be able to form a strong binding between hooks even if the hooks themselves only supported a weak binding. Darren _______________________________________________ networking-discuss mailing list [email protected]
