Common interface for Linux NIC statistics | Hacker News Reader

Common interface for Linux NIC statistics

people.kernel.org

130 pointssohkamyung17 comments

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

It behaves much like a datagram socket IIRC.

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?

+1 for the file interface

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

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

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

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.

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 ;-)

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 guess mainly because POSIX and UNIX in general doesn't matter that much on server room, only Linux APIs.

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

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.

Reply on news.ycombinator.com