On 30/07/09 04:01 PM, Sebastien Roy wrote: > 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?
I was thinking along the lines of ib using ipnet but then it wouldn't be IP observability. I suppose the correct answer is that "sniffing" local to the protocol is not something to be abstracted outside of the protocol. >>>> 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. Yup, that's a perfectly reasonable approach too. Outside of the IP observability hooks, does anything come to mind about where else such a distinction would be made? Darren -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.opensolaris.org/pipermail/clearview-discuss/attachments/20090730/87283164/attachment.html>
