Parsing /proc/net/dev in perl and displaying deltas with ncurses was one of my first teenage hacks (ca ‘97), ages before iptraf. This has been an issue for a long time.

This is a welcome change. Is the netlink interface described accessible in /proc or /sys with a standard fopen, or is it a special linuxism?

Netlink interface is a socket opened with socket(AF_NETLINK, ...). https://man.archlinux.org/man/netlink.7.en

Bummer that it requires platform-specific APIs; I much prefer the "everything is a file" approach. Is there a particular reason Linux chose to do it this way?

Linux interpretation of "everything is a file" includes that things like sockets (including netlink) are files, because you interact with them through file descriptors.

Many of the things that could be files not being files is because someone messed up. Why are network interfaces not in /dev? Well, during the UNIX wars, every vendor came up with their own stuff, and much of it wasn't very good. BSD and Linux inherited some of these needless inconsistencies.

Plan 9 is a much more UNIXy system than the dominant UNIX derivatives.

I suppose, but if I want to consume it in an app or library, not only do I have to write the platform-specific parser, but I also have to write the platform-specific bytes-getter. Seems silly to me to not make it available to standard unix tools (ie cat, grep, sed, awk).

I think it's really intended for the power users. Updating firewall rules, routes, upgrading tc classes, reading qdiscs stats, all without ever forking a new process. It's also quite low-overhead when you subscribe to firewall or audit log rules... Netlink is quite amazing but also... Quite mysterious sometimes. libnl and reading the kernel source will help a lot for the new user. Also stracing the iproute2 tools will help see how it's done.

Anyway, if anyone has a way of checking the state of a plug-qdisc (is it plugged or unplugged) I'd be quite interested ;-)

Try to open() or seek() a socket file descriptor.

You can't lseek() (what is seek()?) a socket because lseek doesn't make sense on 'streaming' data. There are multiple answers for how it can be done (i.e. receive it to a buffer) but you can do that yourself, in userspace, at no real expense. You also can't lseek a pipe, or files on some types of hardware, and "POSIX does not specify which devices must support lseek()" (https://man7.org/linux/man-pages/man2/lseek.2.html)

open(), of course, is an operation on a path/filename, not generally a descriptor. Not sure what usage you're referring to.

I am referring to everything is a file descriptor, except when not.

Cool, but a pathname is not and has never been a file descriptor, and open is an operation upon a pathname.

At least close() is universal (even for stuff like epoll descriptors), and read() and write() are very widely applicable.

"Everything is a file" still involves platform-specific APIs. The filename and manner of operation on that file are, after all, platform-specific.

+1 for the file interface

I guess mainly because POSIX and UNIX in general doesn't matter that much on server room, only Linux APIs.

It behaves much like a datagram socket IIRC.

Ethtool gets information from the SIOCETHTOOL ioctl and AF_NETLINK sockets. The former are traditional ioctls that can be performed on any socket (e.g. AF_INET), the latter is a message-oriented protocol for communicating networking information to/from the kernel. (For example, “ip route” and “route” tools transact routing info through RT_NETLINK messages on AF_NETLINK sockets.) There are many different protocols that sit on top of NETLINK sockets.