There seems to be an overall consensus that the ioctl interface used by ethtool is a poor design as it's inflexible, error prone and notoriously hard to extend. It should clearly be replaced by netlink and obsoleted. Unfortunately not much actual work has been done in that direction until Hackweek 16 (fall 2017) when this project started.

At the moment (June 2019, just before Hackweek 18), first part of the kernel series has been submitted to upstream (in March 2019) and received review which resulted in severe rewrite. Most of it is done but there are few requests which still need to be addressed before submitting v6.


Looking for mad skills in:

kernel networking netlink c

This project is part of:

Hack Week 16 Hack Week 17 Hack Week 18


  • over 1 year ago: dsterba liked netlink interface for ethtool
  • over 1 year ago: pvorel liked netlink interface for ethtool
  • about 2 years ago: a_faerber liked netlink interface for ethtool
  • about 2 years ago: jiriwiesner joined netlink interface for ethtool
  • about 2 years ago: jiriwiesner liked netlink interface for ethtool
  • Show History


    • mkubecek
      about 2 years ago by mkubecek | Reply

      I played a bit already, here is a small demo.

    • mkubecek
      about 2 years ago by mkubecek | Reply

      End-of-hackweek status: disappointing, to be honest. Because of a series of P0/P1 bugs, not much time was left to work on the project. The plan was to have 8-10 most common subcommands implemented on both kernel and ethtool side, ready for an RFC submission, and maybe also some work on wireshark dissector. Reality is much less impressive:

      • kernel: basic infrastructure, GET_DRVINFO, GET_SETTINGS and half of SET_SETTINGS
      • ethtool: basic infrastructure, ethtool -i <dev>

      Current code can be found in mkubece/ethnl on Github and homeadd-emojiethnl OBS project. Let's hope we can get to an RFC submission by the end of this week (I would like to have ethtool ( | -s | -i ) <dev> working on both sides for that).

    • mkubecek
      over 1 year ago by mkubecek | Reply

      Marked the project for Hackweek 17 but I won't actually have Hackweek 17 in the usual sense due to Netdev conference. Instead, the plan is to dedicate five days (probably five Fridays in near future) to the project.

      Current state: kernel supports GET_DRVINFO, {G,S}ET_SETTINGS and {G,S}ET_PARAMS, dumps for all supported requests and notifications for SETTINGS and PARAMS (DRVINFO is read only by nature so there shouldn't be anything to notify). All of these requests are also supported by ethtool; the code for dumps (use* as device name) and monitoring (use --monitor as first parameter) also exists but the parser needs a bit more work to be presentable.

    • mkubecek
      7 months ago by mkubecek | Reply

      Status update just before Hackweek 18.

      Kernel series is almost ready for upstream submission of first part. The main missing part is unified request header and unified processing of it. There may also be some minor issues found in v5 review. Submitting v6 is the primary goal for Hackween 18 but it should only take part of the week (the smaller the better).

      More work needs to be done on userspace ethtool utility which is lagging behind a bit:

      • without EVENT notifications (rejected by upstream), monitor will need "lazy load" of string sets
      • some commands will require rtnetlink or devlink; rethink the context structure and socket handling
      • monitor needs to also listen to and react to rtnetlink and devlink notifications
      • syntax extensions need to be documented in man page
      • new debugging options showing structure of sent/received messages
      • use the same parser to interpret bad attribute offset from extack error/warning messages

    Similar Projects

    work on sunxi a64 cpufreq driver (for teres-1, pine64) by mbrugger

    With the teres-1 [1] laptop we have a first arm...

    Help with mainline support for the Mediatek chromebook (MT8173 based) by mbrugger

    Lately the necessary patches to get rudimentary...

    Upstreaming of mediatek helios board by mbrugger

    The only Mediatek "hacker" board available is f...

    openSUSE/SLE/Mainline U-boot for some not-yet-supported ARM64 boards by ldevulder

    The Khadas VIM ( is an a...

    Improving picotm by tdz

    Picotm is a system-level transaction manager. I...

    dmidecode: no more open-coded printfs by jdelvare

    There's a long standing request to extend the o...