On 27.04.2017 18:00, David Miller wrote: > From: Hannes Frederic Sowa <han...@stressinduktion.org> > Date: Thu, 27 Apr 2017 15:22:49 +0200 > >> Sure, that sounds super. But so far Linux and most (maybe I should write >> all) subsystems always provided some easy way to get the insights of the >> kernel without having to code or rely on special tools so far. > > Not true.
Yes, I should not have written it that generally. ;) > You cannot fully dump socket TCP internal state without netlink based > tools. It is just one of many examples. > > Can you dump all nftables rules without a special tool? You got me here, I agree that not all state is discoverable via procfs. But to some degree even netfilter and tcp do expose some considerable amount of data via procfs. In the case of netfilter it might be less valuable, though, I have to agree. > I don't think this is a legitimate line of argument, and I want > this to be done via the bpf() system call which is what people > are working on. I hope you saw that I was absolutely not against dumping or enumeration with the bpf syscall. It will be the primary interface to debug ebpf and I completely agree. Merely I tried to establish the procfs interface as quick look interface if some type of bpf program is loaded which could start any further diagnosis. This interface should not have any dependencies and should even work on embedded devices, where sometimes it might be difficult to get a binary for the correct architecture installed ad-hoc (I am thinking about openwrt). But this is definitely also solvable. I do think if a common utility in util-linux, like lsbpf, is available I will be fine. Anyway, I will take this argument back. Thanks, Hannes
