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:[EMAIL PROTECTED]?body=unsubscribe
