Re: Reserving a libpcap DLT value

[Kent Dahlgren <kent () praesum com>]

Guy

My goal here is not to get into the great debate about file
formats, but to make Ethereal useful for debugging some
new interfaces.

If you absolutely have a problem with the named transport
approach, then I need three new transports defined for
libpcap:

        DLT_RIO         for RapidIO
        DLT_PCI_EXP     for PCI Express
        DLT_AURORA      for the Xilinx Aurora link layer

How do you want to go about adding these?

Kent

At 01:10 AM 10/9/2002 -0700, Guy Harris wrote:
> On Wed, Oct 09, 2002 at 10:00:31AM +0200, Hannes Gredler wrote:
> > IMHO changing protocols/formats once code is shipping is clearly a thing
> > to avoid;
>
> I.e., we can never ever ever introduce a new libpcap format to add new
> capabilities?  I don't agree with that at all.  It's not as if the new
> format would use the same magic number, so it's not as if you've changed
> *the* libpcap format, so that new programs can't read old files.
>
> (And as for never changing protocols, well, so much for NFSv3, NFSv4,
> and IPv6....)
>
> > the DLT_private type would fiz both problems at the expense of
> > a few extra bytes ...
>
> It "fixes" the problem of changing the file format by, in effect,
> changing the file format - if only the DLT_private type can have
> extensions, then only versions of libpcap that support the DLT_private
> type *and* applications that support it can handle files with
> extensions, which means that, for all intents and purposes, you've
> changed the file format (i.e., you've made a file format that older code
> can't read, which is the *ONLY* problem I see with introducing a
> second-generation libpcap format).


-
This is the TCPDUMP workers list. It is archived at
http://www.tcpdump.org/lists/workers/index.html
To unsubscribe use mailto:tcpdump-workers-request () tcpdump org?body=unsubscribe