[Guy Harris <gharris@xxxxxxxxx>]

On Apr 25, 2025, at 11:30 AM, Omer Shapira via Wireshark-dev <wireshark-dev@xxxxxxxxxxxxx> wrote:

> On Apr 25, 2025, at 6:07 AM, Anders Broman <a.broman58@xxxxxxxxx> wrote:
> 
>> Den fre 25 apr. 2025 kl 02:38 skrev Omer Shapira via Wireshark-dev <wireshark-dev@xxxxxxxxxxxxx>:
>> 
>>> On Apr 24, 2025, at 4:29 PM, Guy Harris <gharris@xxxxxxxxx> wrote:
>>> 
>>>> On Apr 24, 2025, at 2:56 PM, Omer Shapira via Wireshark-dev <wireshark-dev@xxxxxxxxxxxxx> 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?