[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4ee83195-99f5-4823-b4d0-339ef4127013@cambridgegreys.com>
Date: Thu, 7 Mar 2024 10:49:56 +0000
From: Anton Ivanov <anton.ivanov@...bridgegreys.com>
To: Johannes Berg <johannes@...solutions.net>,
Waqar Hameed <waqar.hameed@...s.com>, Ingo Molnar <mingo@...nel.org>
Cc: oe-kbuild-all@...ts.linux.dev, linux-kernel@...r.kernel.org,
kernel@...s.com, Richard Weinberger <richard@....at>,
linux-um@...ts.infradead.org
Subject: Re: pcap-dbus.o:undefined reference to `dbus_message_demarshal'
On 07/03/2024 10:29, Johannes Berg wrote:
> On Thu, 2024-03-07 at 10:27 +0000, Anton Ivanov wrote:
>>>
>>> How's that required to be formatted and loaded? tcpdump itself can also
>>> dump the filter in BPF format, with -d/-ddd (-dd is a C representation,
>>> so probably not useful). Perhaps we could even automatically call
>>> 'tcpdump' at runtime?
>>
>> That is one option.
>>
>> As far as common use cases are concerned, at present you can:
>>
>> tcpdump -ddd, convert it to raw binary (3 liner in a language of choice) and pass that to vecX as a bpffile=
>>
>> It may be worth it to make vecX also take the -ddd format directly by adding "format" options to bpffile.
>>
>> I'd rather do that instead of invoking tcpdump out of a device open. The -ddd notation (+/- a comma here and there) is
>> standard - it is also used by iptables, etc. It can used by other code generators as well.
>
> Yeah, that makes sense, this is all kind of special configuration
> anyway, and given that it's been broken forever ...
>
> I actually doubt anyone would scream if we just removed it, so maybe
> just remove it and if they do scream, point to the above, including said
> 3-liner in the response?
Let's make it so.
>
> johannes
>
>
--
Anton R. Ivanov
Cambridgegreys Limited. Registered in England. Company Number 10273661
https://www.cambridgegreys.com/
Powered by blists - more mailing lists