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. All I could find was this e-mail from April 2016. (Update: there is also one as early as February 2008 but that apparently died soon as well.)

The plan is to provide an RFC implementation of kernel netlink interface for the most frequently used functions and alternative ethtool code using it. It wouldn't be realistic to expect full functionality within a week but the result at the end of Hackweek 16 should be a proof of concept that can be built upon and that can be used to initiate the upstream discussion.

Looking for mad skills in:

kernel networking netlink c

This project is part of:

Hack Week 16 Hack Week 17


  • 8 days ago: dsterba liked netlink interface for ethtool
  • 9 days ago: pvorel liked netlink interface for ethtool
  • 8 months ago: a_faerber liked netlink interface for ethtool
  • 9 months ago: jiriwiesner joined netlink interface for ethtool
  • 9 months ago: jiriwiesner liked netlink interface for ethtool
  • Show History


    • mkubecek
      9 months ago by mkubecek | Reply

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

    • mkubecek
      8 months 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
      10 days 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.

    Similar Projects

    openSUSE/SLE/Mainline U-boot for Khadas VIM/VIM2 board by ldevulder

    The Khadas VIM ( is an a...

    An experimental tiny WM of Wayland by NalaGinrut

    Wayland would replace X11 in the future (maybe ...

    Add Ceph support for Azure RESTful protocols by dmdiss

    Microsoft Azure offers a bunch of interesting R...

    Secure keyboard by mwilck

    This idea was inspired by the recent discussion...

    Better support for Chromebooks by suntorytimed

    Better support for Chromebooks