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 this project started.
The project started in Hackweek 16 (fall 2017) and has been worked on since, both in Hackweek 17-19 and outside. First two parts of kernel implementation are in mainline since 5.6-rc1, first part of userspace implementation (ethtool utility) has been submitted to upstream at the end of Hackweek 19 (2020-02-16).
Links:
Looking for hackers with the skills:
This project is part of:
Hack Week 16 Hack Week 17 Hack Week 18 Hack Week 19
Activity
Comments
-
-
about 8 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_SETTINGSand half ofSET_SETTINGS - ethtool: basic infrastructure,
ethtool -i
Current code can be found in mkubece/ethnl on Github and home:mkubecek:ethnl 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 )working on both sides for that). - kernel: basic infrastructure,
-
over 7 years 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_SETTINGSand{G,S}ET_PARAMS, dumps for all supported requests and notifications forSETTINGSandPARAMS(DRVINFOis 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--monitoras first parameter) also exists but the parser needs a bit more work to be presentable. -
over 6 years 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
EVENTnotifications (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
- without
-
almost 6 years ago by mkubecek | Reply
Status update before Hackweek 19
After few more review rounds and rewrites, initial part of the kernel series was accepted to net-next tree and reached mainline as part of the 5.6 merge window (so that it's going to appear in
v5.6-rc1. What is in mainline at the moment allows netlink based implementation ofethtoolethtool s ...ethtool -P(using rtnetlink)
and corresponding notifications.
The userspace ethtool counterpart, however, will need a lot of work to make it ready for upstream submission. As it is highly desirable to have it in ethtool 5.6 release, this is going to be the primary focus at least for the first part of Hackweek 19.
-
almost 6 years ago by mkubecek | Reply
Status update after Hackweek 19
TL;DR: The primary goal was achieved (12 minutes before the end of the week
).Summary of the Hackweek 19 progress:
- abstractions for netlink socket and message buffer separated from
struct nl_context - rework the code generating multiple messages from one set of parameters (for
ethtool -s) - rework "char bitset" parser (for
ethtool -s wol ...) - drop bitfield32 helpers and other code no longer used
- compatibility with existing test suite (
make checksucceeds now) - split some too long patches
- some bugs fixed
- lot of style cleanups
- more comments and better commit messages
- cover letter
- current work in progress tracked on github again
The resulting series has been submitted to upstream.
- abstractions for netlink socket and message buffer separated from
- abstractions for netlink socket and message buffer separated from
struct nl_context - rework the code generating multiple messages from one set of parameters (for
ethtool -s) - rework "char bitset" parser (for
ethtool -s wol ...) - drop bitfield32 helpers and other code no longer used
- compatibility with existing test suite (
make checksucceeds now) - split some too long patches
- some bugs fixed
- lot of style cleanups
- more comments and better commit messages
- cover letter
- current work in progress tracked on github again
Reply to mkubecek
Status update after Hackweek 19
TL;DR: The primary goal was achieved (12 minutes before the end of the week ).
Summary of the Hackweek 19 progress:
The resulting series has been submitted to upstream.
# A First Level Header ## A Second Level Header Use one asterisk to *emphasize* Use two asterisks for **strong emphasis** - Use hyphens - for unordereed - lists This is an [link to example.com](http://example.com/) This is an image  This is a user link @hans This is a project link hw#some-cool-title
Similar Projects
pudc - A PID 1 process that barks to the internet by mssola
Description
As a fun exercise in order to dig deeper into the Linux kernel, its interfaces, the RISC-V architecture, and all the dragons in between; I'm building a blog site cooked like this:
- The backend is written in a mixture of C and RISC-V assembly.
- The backend is actually PID1 (for real, not within a container).
- We poll and parse incoming HTTP requests ourselves.
- The frontend is a mere HTML page with htmx.
The project is meant to be Linux-specific, so I'm going to use io_uring, pidfs, namespaces, and Linux-specific features in order to drive all of this.
I'm open for suggestions and so on, but this is meant to be a solo project, as this is more of a learning exercise for me than anything else.
Goals
- Have a better understanding of different Linux features from user space down to the kernel internals.
- Most importantly: have fun.
Resources
Add Qualcomm Snapdragon 765G (SM7250) basic device tree to mainline linux kernel by pvorel
Qualcomm Snapdragon 765G (SM7250) (smartphone SoC) has no support in the linux kernel, nor in u-boot. Try to add basic device tree support. The hardest part will be to create boot.img which will be accepted by phone.
UART is available for smartphone :).
Backporting patches using LLM by jankara
Description
Backporting Linux kernel fixes (either for CVE issues or as part of general git-fixes workflow) is boring and mostly mechanical work (dealing with changes in context, renamed variables, new helper functions etc.). The idea of this project is to explore usage of LLM for backporting Linux kernel commits to SUSE kernels using LLM.
Goals
- Create safe environment allowing LLM to run and backport patches without exposing the whole filesystem to it (for privacy and security reasons).
- Write prompt that will guide LLM through the backporting process. Fine tune it based on experimental results.
- Explore success rate of LLMs when backporting various patches.
Resources
- Docker
- Gemini CLI
Repository
Current version of the container with some instructions for use are at: https://gitlab.suse.de/jankara/gemini-cli-backporter
bpftrace contribution by mkoutny
Description
bpftrace is a great tool, no need to sing odes to it here. It can access any kernel data and process them in real time. It provides helpers for some common Linux kernel structures but not all.
Goals
- set up bpftrace toolchain
- learn about bpftrace implementation and internals
- implement support for
percpu_counters - look into some of the first issues
- send a refined PR (on Thu)
Resources
Improve UML page fault handler by ptesarik
Description
Improve UML handling of segmentation faults in kernel mode. Although such page faults are generally caused by a kernel bug, it is annoying if they cause an infinite loop, or panic the kernel. More importantly, a robust implementation allows to write KUnit tests for various guard pages, preventing potential kernel self-protection regressions.
Goals
Convert the UML page fault handler to use oops_* helpers, go through a few review rounds and finally get my patch series merged in 6.14.
Resources
Wrong initial attempt: https://lore.kernel.org/lkml/20231215121431.680-1-petrtesarik@huaweicloud.com/T/
pudc - A PID 1 process that barks to the internet by mssola
Description
As a fun exercise in order to dig deeper into the Linux kernel, its interfaces, the RISC-V architecture, and all the dragons in between; I'm building a blog site cooked like this:
- The backend is written in a mixture of C and RISC-V assembly.
- The backend is actually PID1 (for real, not within a container).
- We poll and parse incoming HTTP requests ourselves.
- The frontend is a mere HTML page with htmx.
The project is meant to be Linux-specific, so I'm going to use io_uring, pidfs, namespaces, and Linux-specific features in order to drive all of this.
I'm open for suggestions and so on, but this is meant to be a solo project, as this is more of a learning exercise for me than anything else.
Goals
- Have a better understanding of different Linux features from user space down to the kernel internals.
- Most importantly: have fun.
Resources
Port OTPClient to GTK >= 4.18 by pstivanin
Project Description
OTPClient is currently using GTK3 and cannot easily be ported to GTK4. Since GTK4 came out, there have been quite some big changes. Also, there are now some new deprecation that will take effect with GTK5 (and are active starting from 4.10 as warnings), so I need to think ahead and port OTPClient without using any of those deprecated features.
Goal for this Hackweek
- fix the last 3 opened issues (https://github.com/paolostivanin/OTPClient/issues/402, https://github.com/paolostivanin/OTPClient/issues/404, https://github.com/paolostivanin/OTPClient/issues/406) and release a new version
- continue the rewrite from where we left last year
- if possible, finally close this 6 years old issue: https://github.com/paolostivanin/OTPClient/issues/123
Smart lighting with Pico 2 by jmodak
Description
I am trying to create a smart-lighting project with a Raspberry Pi Pico that reacts to a movie's visuals and audio that involves combining two distinct functions: ambient screen lighting(visual response) and sound-reactive lighting(audio response)
Goals
- Visuals: Capturing the screen's colour requires an external device to analyse screen content and send colour data to the MCU via serial communication.
- Audio: A sound sensor module connected directly to the Pico that can detect sound volume.
- Pico 2W: The MCU receives data fro, both inputs and controls an LED strip.
Resources
- Raspberry Pi Pico 2 W
- RGB LED strip
- Sound detecting sensor
- Power supply
- breadboard and wires
x64id: An x86/x64 instruction disassembler by m.crivellari
Description
This is an old side project. An x86/x64 machine code decoder. It is useful to get instructions' length and identify each of its fields.
Example:
C7 85 68 FF FF FF 00 00 00 00
This is the instruction:
MOV DWORD PTR SS:[LOCAL.38],0
What follows are some of the information collected by the disassembler, based on the specific instruction:
RAW bytes (hex): C7 85 68 FF FF FF 00 00 00 00
Instr. length: 10
Print instruction fields:
Located Prefixes 0:
OP: 0xC7
mod_reg_rm: 0x85
disp (4): 0xFFFFFF68
Iimm: 0x0
Lacks the mnemonic representation: from the previous machine code is not able to produce the "MOV..." instruction, for example.
Goals
The goal is almost easy: partially implement the mnemonic representation. I have already started during the weekend, likely tomorrow I will push the branch!
Resources
- The project: https://github.com/DispatchCode/x64-Instruction-Decoder/
- This is useful to avoid gdb and objdump in local: https://defuse.ca/online-x86-assembler.htm
- Another interesting resource is https://godbolt.org/
Progress
- An initial implementation can be found at: https://github.com/DispatchCode/x64-Instruction-Decoder/tree/mnemonic-support It is described under the "Mnemonic translation" in the README file!
Let's consider this example:
[...other bytes...] 43 89 44 B5 00 01 00 [...other bytes...]
Improve the picotm Transaction Manager by tdz
Picotm is a system-level transaction manager. It provides transactional semantics to low-level C operations, such as
- memory access,
- modifying data structures,
- (some) file I/O, and
- common interfaces from the C Standard Library and POSIX.
Picotm also handles error detection and recovery for all it's functionality. It's fully modular, so new functionality can be added.
For the Hackweek, I want to dedicate some time to picotm. I want to finish some of the refactoring work that I have been working on. If there's time left, I'd like to investigate two-phase commits and how to support them in picotm.
Picotm is available at http://picotm.org/.