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

Activity

  • 2 months ago: dsterba liked netlink interface for ethtool
  • 2 months ago: pvorel liked netlink interface for ethtool
  • 11 months ago: a_faerber liked netlink interface for ethtool
  • 11 months ago: jiriwiesner joined netlink interface for ethtool
  • 11 months ago: jiriwiesner liked netlink interface for ethtool
  • Show History

    Comments

    • mkubecek
      11 months ago by mkubecek | Reply

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

    • mkubecek
      10 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
      2 months 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

    Make parted great again! by sparschauer

    During regular L3 work I often don't find enoug...


    L3: Improve crash-setup, develop a core-setup by sparschauer

    The current crash-setup source is located [here...


    Improve linuxrc/rescue system by aginies

    <p>Rescue system has a lot of options , but...


    Upstreaming of mediatek helios board by mbrugger

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


    layer3 cloud by bmwiedemann

    One of the things that make deploying SUSE Open...