On Thu, 2009-07-30 at 15:08 -0700, Darren Reed wrote: > On 30/07/09 01:26 PM, Sebastien Roy wrote: > > Hi Darren, > > > > On Sun, 2009-07-26 at 18:33 -0700, Darren Reed wrote: > > > > > Seb, > > > > ... > > > Additionally, do you have any comments about changing the behaviour > > > of dl_sap for /dev/ipnet devices? The change in number space I'd like to > > > promote is: > > > 0 => AF_UNSPEC > > > IPV4_VERSION => AF_INET > > > IPV6_VERSION => AF_INET6 > > > > > > > I can't say that I care very much either way. The advantage that the > > existing scheme has is that (except for 0 which is a special case) the > > SAP value appears in the IP header. > > > > My thoughts were along the lines of if the SAP becomes an address > family rather than the IP version number then it is easier to extend > the > IP observability infrastructure to be reused by other protocols. > > e.g. what if we wanted to do an Infiniband implementation of this > paradigm?
I don't follow. Infiniband already has a well-defined SAP space. Can you be more specific? > > > > > Finally, I'm thinking that it might either be worth dragging > > > ipobs_hook_type_t up to "Committed" or at least the symbols > > > it defines. The name "ipobs_hook_type" ... do you (or anyone > > > else) have any comments on that before it is cast in stone? > > > > > > > What would be the justification for raising their stability? What would > > be the consumer, and where would they be documented? The only original > > intended consumer was the ipnet module, and at that, the preferred plan > > would have been to use a more general hook (which was impossible at the > > time). I'd expect that we could fix the ip module to generalize its use > > of hooks, in which case "ipobs" hooks could theoretically go away. If > > that's the direction we're going in, then upgrading them to Committed > > seems counter to that. > > > > Well, libpcap is a potential consumer (see discussion on > tcpdump-workers.) > Importantly, the header from ipobs_hook_type_t gives the direction a > packet > is going in as a property that you can write a filter on - not > something you > can do with raw mac packets in BPF. So from that perspective, this > pseudo > header has unique value in its current form. I doubt that was intended > to be > true as a design feature but all the same, something to think about. Okay, I see what you're saying. If we need a Public definition for "packet direction", then perhaps it can be defined outside of the context of an IP observability "hook", though. I don't think we want to expose things specific to the hooks themselves if the consumer is only merely interested in parsing the ipnet header, which itself should indeed be a Public interface. -Seb
