Re: supporting extend 'open live capture' parametes

[Michael Richardson <mcr () sandelman ottawa on ca>]

> > > > > "Abeni" == Abeni Paolo <paolo.abeni () telecomitalia it> writes:
    Abeni> - the (possibly high) number of new API that need to be added
    Abeni> in order to support all required/wanted options for the open
    Abeni> call - if we use the pcap struct to store all the supplied
    Abeni> options (witch seams a reasonable choice, at least to me) it
    Abeni> need to be changed/updated every time a new option need to be
    Abeni> added. Can this scenario possibly leads to ABI compatibility
    Abeni> issue ?!?

  a) the structure should be opaque, or at least, the beginning of it
     should not change.
  
  b) the structure should always be allocated by the library.

    Abeni> could be implemented with very little platform specific code,
    Abeni> if upon complete initialization allowed option/values are
    Abeni> stored into the pcap handle. Moreover, since the caller knows
    Abeni> the parameter is requesting, it could be inferred it know
    Abeni> also the parameter's size: any others APIs to request this
    Abeni> information should not be required.

  It's best to put both.

    Abeni> I would like to try to implement the new API this way and
    Abeni> post some code, even in very experimental form, in the hope
    Abeni> to make the discussion/analysis easier (at least to
    Abeni> me...). What do you think?

  I think it's a great idea.

-- 
]           Bear: "Me, I'm just the shape of a bear."          |  firewalls  [
]  Michael Richardson,    Xelerance Corporation, Ottawa, ON    |net architect[
]mcr () xelerance com      http://www.sandelman.ottawa.on.ca/mcr/ |device driver[
]panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [


-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.