James Carlson wrote: ... > I don't quite follow that. The net_protocol_lookup() function[1], which > seems to be the way that one finds net_data_t instances, takes only a > single string argument, which I *think* should be "inet" for IPv4 and > "inet6" for IPv6.
There's some #define's that cover this and these need to be mentioned; NHF_INET and NHF_INET6. > So, if there's a separate net_data_t for each exclusive IP stack > instance, how do you find it? What's missing in the documentation is that the interface is: net_protocol_lookup(netid_t, char *) But let me expand on that... How do you discover the netid_t? At present, as a result of being called from the _create() when you do a net_instance_register() or use GLOBAL_NETID. > [1] As a detailed comment, it seems that net_protocol_lookup() returns > net_data_t *, but that all of the other functions take net_data_t. > Are the callers expected to dereference, or are the types > confused? That's an error in the documentation for net_protocol_lookup(), it should just return net_data_t. ... > The problem I see is that it's unclear when and if the consumer of > pfhooks has access to zone information. I understand that it may be > the case that some hooks can't provide this, but that others can, but > I don't think that the consumer of pfhooks should need to understand > how the hooks themselves are implemented -- the existence of zone > information should be called out where it is known. Ok. To make this easier, I can add these two: netid_t net_zoneidtonetid(zoneid_t) zoneid_t net_netidtozoneid(netid_t) This, along with "netid_t net_getnetid(net_data_t)" should provide enough information to find out which zone you're in when doing processing on a packet from an event. It is tempting to add net_data_t to the hook_*_event_t, so that the proper context is always available, rather than require the consumer to store this themselves. ... >> Now even if I do that, >> I'll get a netid_t, at which point I need a way to equate (or at least >> attempt >> to match up) my zone name with that, bringing to life the need for at >> least a function to map netid_t onto zoneid_t and convert a name into >> a zoneid_t (and probably the inverse of that too.) >> >> ... but the caveat here is that none of the existing code requires any of >> the above, so there are no existing consumers. > > That could be why I'm finding it hard to put it together ... From above... And if you're finding it hard, so will others... putting the context that a hook is executed in into the hook data structures is starting to seem like a very worthwhile low cost win here. ... > I think it'd be really helpful to have a listing of the SIOC* ioctls > and the corresponding pfhooks/netinfo functions -- both so that we > know where there might be gaps, as so that we have some help in > porting code from user to kernel space. > >>> Is it possible to invoke L2 (ARP/NDP) look-up? >> Not through this interface, no. > > I think this was one of the SDP/IB requests, so that's why I was > asking. It is something that could potentially be added - I don't see anything that exists now getting in the way of it. But I'd rather wait until they were knocking on the door (they aren't yet) and they knew exactly what interface they required. ... >>>> The word "hint" is used here deliberately as two of the optional hints, >>>> first and last, may not be continually satisified beyond the initial >>>> registration of the hook - they only represent the ordering requirement >>>> at the time of insertion. Furthermore, the "before" and "after" hints >>>> do not gaurantee "immediately before/after". >>>> >>> Why not? What happens if the hint isn't honored? Is it possible that >>> correctness is sacrificed? >>> >> Well, the hint being given is that X wants to be before Y, not that after >> directly after X should be Y. Yes, I suppose I'm cheating by playing on >> the definition of words here but that's somewhat deliberate. > > I have no problem with "X wants to be before Y" translating into > "X->Q->Y" in the stack. > > I'm not so sure I agree with "X wants to be first" translating into > "Q->X" in the stack. I'm not even sure I understand what "first" > means in those circumstances. Depending on load order, which doesn't > seem defined, it seems that a module specifying "first" could silently > be placed last after a long list of other modules. > ... > Suppose there > *are* two such products. Aren't they incompatible with each other? > Why not prevent incompatible products from being loaded > simultaneously? If each wants to access unmodified packets that come from the hook, then yes, they are incompatible if either one changes the packet. I think an extension that needs to be examined in more detail is what does it mean if a hook consumer says "I won't modify the packet"? But I'd like to take that on as an extension of the existing work rather than try fold that in now. > ... > I have no problem with that. The relative ordering makes sense, and > an intermediate module doesn't bother me. Instead, I'm confused about > the absolute ordering that's not really absolute. > ... > I'd answer that by saying that since they've both demanded to be > first, and only one can actually be first, then one must lose. As > long as that's a constraint listed in the documentation, and that > hook-using module writers explain to their customers, I don't see it > as a big problem. > ... I don't want to admit it, but you do have a point here with the argument you've put forward. One approach might be to recommend that developers design to operate "at any point in the list" and that if an attempt to insert a hook with a hint of first/last fails (because it is already being used), they should retry without a hint. Something that I haven't taken into account (and that I need to) is what happens if X must be before Y, but you try to remove Y before X? I think this is clearly an operation that must be denied: so long as there is a dependency on a hook, it can't be removed from the list. > ... > Dumb question time: this is all global, right? You can't have > per-interface hook lists, or per-exclusive-IP-stack hook lists, right? You can have per-exclusive-IP-stack hook lists. Shared IP stack zones are bound to whatever happens in the global zone. The hooks are now (and will continue to be) specific to each instance of IP. The easy example today is to have (say) the global zone with ipfilter enabled and a local zone that has an exclusive stack instance with ipfilter disabled. In the global zone, the physical-in/physical-out hook lists will have ipfilter on them and in the local zone, they'll be missing. Darren _______________________________________________ networking-discuss mailing list [email protected]
