[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <463be980baf66b967031e3294c3b9745b07aa058.camel@sipsolutions.net>
Date: Thu, 07 Mar 2024 11:03:32 +0100
From: Johannes Berg <johannes@...solutions.net>
To: Anton Ivanov <anton.ivanov@...bridgegreys.com>, 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 Thu, 2024-03-07 at 09:54 +0000, Anton Ivanov wrote:
>
> PCAP is not feasible to incorporate into the build system at present.
> It has grown all kinds of warts over the years and brings a lot of dependencies.
> IMHO we should remove it from the tree. It has reached a point where it cannot
> be built on a modern system.
I suppose it might be possible to call pcap-config? But agree that it
doesn't seem really worth investing in.
> The users who need the same functionality can produce a bpf filter using tcpdump
> and load it as "firmware" into the vector/raw driver.
>
> I am working on a pure python bpf compiler which takes the same syntax as PCAP.
> It is showing signs of life and it can do some of the simpler use cases. Once
> that is ready, it should be possible to use that instead of pcap/tcpdump.
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?
johannes
Powered by blists - more mailing lists