On Apr 25, 2025, at 11:30 AM, Omer Shapira via Wireshark-dev <wireshark-dev@wireshark.org> wrote:
> On Apr 25, 2025, at 6:07 AM, Anders Broman <a.broma...@gmail.com> wrote: > >> Den fre 25 apr. 2025 kl 02:38 skrev Omer Shapira via Wireshark-dev >> <wireshark-dev@wireshark.org>: >> >>> On Apr 24, 2025, at 4:29 PM, Guy Harris <ghar...@sonic.net> wrote: >>> >>>> On Apr 24, 2025, at 2:56 PM, Omer Shapira via Wireshark-dev >>>> <wireshark-dev@wireshark.org> wrote: >>>> >>>>> Unfortunately, when the support for the process metadata was added, the >>>>> team missed the opportunity to do the right thing and to use CUSTOM block >>>>> for the metadata, and instead used the LOCAL block id (with the MSB set). >>>>> This was before my time, and as far as I can tell, this decision was not >>>>> made in spite, but due to the lack of context and the general sense of >>>>> urgency. >>>> >>>> Unless it was done before custom blocks were in the pcapng spec, in which >>>> case it was done because there was no alternative. >>> >>> That’s possible, as I mentioned, I don’t have the full view of the reasons >>> behind it. > > I just double checked, this was indeed the case. There were no custom blocks > back then. Then Apple did what it was supposed to do, and there's no need on Apple's part for using a local-use block. >> One idea for presenting the data is to put it in the frame data section. >> Another idea is to change the packet list to present >> the pcap-ng blocks at the lowest level which could be useful to put non >> packet blocks in the list such as IDB:s statistical blocks and "events". May >> be problematic for other capture file types. > > I was thinking about expanding the frame data section, so that this > information will be accessible at every layer. I.e., do it the same way that the interface information is done? _______________________________________________ Wireshark-dev mailing list -- wireshark-dev@wireshark.org To unsubscribe send an email to wireshark-dev-le...@wireshark.org
