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 7 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 6 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 5 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 5 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 5 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
Linux on Cavium CN23XX cards by tsbogend
Before Cavium switched to ARM64 CPUs they developed quite powerful MIPS based SOCs. The current upstream Linux kernel already supports some Octeon SOCs, but not the latest versions. Goal of this Hack Week project is to use the latest Cavium SDK to update the Linux kernel code to let it running on CN23XX network cards.
Create a DRM driver for VGA video cards by tdz
Yes, those VGA video cards. The goal of this project is to implement a DRM graphics driver for such devices. While actual hardware is hard to obtain or even run today, qemu emulates VGA output.
VGA has a number of limitations, which make this project interesting.
- There are only 640x480 pixels (or less) on the screen. That resolution is also a soft lower limit imposed by DRM. It's mostly a problem for desktop environments though.
- Desktop environments assume 16 million colors, but there are only 16 colors with VGA. VGA's 256 color palette is not available at 640x480. We can choose those 16 colors freely. The interesting part is how to choose them. We have to build a palette for the displayed frame and map each color to one of the palette's 16 entries. This is called dithering, and VGA's limitations are a good opportunity to learn about dithering algorithms.
- VGA has an interesting memory layout. Most graphics devices use linear framebuffers, which store the pixels byte by byte. VGA uses 4 bitplanes instead. Plane 0 holds all bits 0 of all pixels. Plane 1 holds all bits 1 of all pixels, and so on.
The driver will probably not be useful to many people. But, if finished, it can serve as test environment for low-level hardware. There's some interest in supporting old Amiga and Atari framebuffers in DRM. Those systems have similar limitations as VGA, but are harder to obtain and test with. With qemu, the VGA driver could fill this gap.
Apart from the Wikipedia entry, good resources on VGA are at osdev.net and FreeVGA
Improve various phones kernel mainline support (Qualcomm, Exynos, MediaTek) by pvorel
Similar to previous hackweeks ( https://hackweek.opensuse.org/projects/improve-qualcomm-soc-msm8994-slash-msm8992-kernel-mainline-support, https://hackweek.opensuse.org/projects/test-mainline-kernel-on-an-older-qualcomm-soc-msm89xx-explore-mainline-kernel-qualcomm-mainlining) try to improve kernel mainline support of various phones.
Model checking the BPF verifier by shunghsiyu
Project Description
BPF verifier plays a crucial role in securing the system (though less so now that unprivileged BPF is disabled by default in both upstream and SLES), and bugs in the verifier has lead to privilege escalation vulnerabilities in the past (e.g. CVE-2021-3490).
One way to check whether the verifer has bugs to use model checking (a formal verification technique), in other words, build a abstract model of how the verifier operates, and then see if certain condition can occur (e.g. incorrect calculation during value tracking of registers) by giving both the model and condition to a solver.
For the solver I will be using the Z3 SMT solver to do the checking since it provide a Python binding that's relatively easy to use.
Goal for this Hackweek
Learn how to use the Z3 Python binding (i.e. Z3Py) to build a model of (part of) the BPF verifier, probably the part that's related to value tracking using tristate numbers (aka tnum), and then check that the algorithm work as intended.
Resources
- Formal Methods for the Informal Engineer: Tutorial #1 - The Z3 Theorem Prover and its accompanying notebook is a great introduction into Z3
- Has a section specifically on model checking
- Software Verification and Analysis Using Z3 a great example of using Z3 for model checking
- Sound, Precise, and Fast Abstract Interpretation with Tristate Numbers - existing work that use formal verification to prove that the multiplication helper used for value tracking work as intended
- [PATCH v5 net-next 00/12] bpf: rewrite value tracking in verifier - initial patch set that adds tristate number to the verifier
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/
Remote control for Adam Audio active monitor speakers by dmach
Description
I own a pair of Adam Audio A7V active studio monitor speakers. They have ethernet connectors that allow changing their settings remotely using the A Control software. From Windows :-( I couldn't find any open source alternative for Linux besides AES70.js library.
Goals
- Create a command-line tool for controlling the speakers.
- Python is the language of choice.
- Implement only a simple tool with the desired functionality rather than a full coverage of AES70 standard.
TODO
- ✅ discover the device
- ❌ get device manufacturer and model
- ✅ get serial number
- ✅ get description
- ✅ set description
- ✅ set mute
- ✅ set sleep
- ✅ set input (XRL (balanced), RCA (unbalanced))
- ✅ set room adaptation
- bass (1, 0, -1, -2)
- desk (0, -1, -2)
- presence (1, 0, -1)
- treble (1, 0, -1)
- ✅ set voicing (Pure, UNR, Ext)
- ❌ the Ext voicing enables the following extended functionality:
- gain
- equalizer bands
- on/off
- type
- freq
- q
- gain
- ❌ udev rules to sleep/wakeup the speakers together with the sound card
Resources
- https://www.adam-audio.com/en/a-series/a7v/
- https://www.adam-audio.com/en/technology/a-control-remote-software/
- https://github.com/DeutscheSoft/AES70.js
- https://www.aes.org/publications/standards/search.cfm?docID=101 - paid
- https://www.aes.org/standards/webinars/AESStandardsWebinarSC0212L20220531.pdf
- https://ocaalliance.github.io/downloads/AES143%20Network%20track%20NA10%20-%20AES70%20Controller.pdf
Result
- The code is available on GitHub: https://github.com/dmach/pacontrol
ESETv2 Emulator / interpreter by m.crivellari
Description
ESETv2 is an intriguing challenge developed by ESET, available on their website under the "Challenge" menu.
The challenge involves an "assembly-like" language and a Python compiler that generates .evm binary files.
This is an example using one of their samples (it prints N Fibonacci numbers):
.dataSize 0
.code
loadConst 0, r1 # first
loadConst 1, r2 # second
loadConst 1, r14 # loop helper
consoleRead r3
loop:
jumpEqual end, r3, r15
add r1, r2, r4
mov r2, r1
mov r4, r2
consoleWrite r1
sub r3, r14, r3
jump loop
end:
hlt
This language also supports multi-threading. It includes instructions such as createThread to start a new thread, joinThread to wait until a thread completes, and lock/unlock to facilitate synchronization between threads.
Goals
- create a full interpreter able to run all the available samples provided by ESET.
- improve / optimize memory (eg. using bitfields where needed as well as avoid unnecessary memory allocations)
Resources
- Challenge URL: https://join.eset.com/en/challenges/core-software-engineer
- My github project: https://github.com/DispatchCode/eset_vm2 (not 100% complete)
Achivements
Project still not complete. Added lock / unlock instruction implementation but further debug is needed; there is a bug somewhere. Actually the code it works for almost all the examples in the samples folder. 1 of them is not yet runnable (due to a missing "write" opcode implementation), another will cause the bug to show up; still not investigated, anyhow.
FizzBuzz OS by mssola
Project Description
FizzBuzz OS (or just fbos) is an idea I've had in order to better grasp the fundamentals of the low level of a RISC-V machine. In practice, I'd like to build a small Operating System kernel that is able to launch three processes: one that simply prints "Fizz", another that prints "Buzz", and the third which prints "FizzBuzz". These processes are unaware of each other and it's up to the kernel to schedule them by using the timer interrupts as given on openSBI (fizz on % 3 seconds, buzz on % 5 seconds, and fizzbuzz on % 15 seconds).
This kernel provides just one system call, write, which allows any program to pass the string to be written into stdout.
This project is free software and you can find it here.
Goal for this Hackweek
- Better understand the RISC-V SBI interface.
- Better understand RISC-V in privileged mode.
- Have fun.
Resources
Results
The project was a resounding success 
Lots of learning, and the initial target was met.
Add a machine-readable output to dmidecode by jdelvare
Description
There have been repeated requests for a machine-friendly dmidecode output over the last decade. During Hack Week 19, 5 years ago, I prepared the code to support alternative output formats, but didn't have the time to go further. Last year, Jiri Hnidek from Red Hat Linux posted a proof-of-concept implementation to add JSON output support. This is a fairly large pull request which needs to be carefully reviewed and tested.
Goals
Review Jiri's work and provide constructive feedback. Merge the code if acceptable. Evaluate the costs and benefits of using a library such as json-c.
FastFileCheck work by pstivanin
Description
FastFileCheck is a high-performance, multithreaded file integrity checker for Linux. Designed for speed and efficiency, it utilizes parallel processing and a lightweight database to quickly hash and verify large volumes of files, ensuring their integrity over time.
https://github.com/paolostivanin/FastFileCheck
Goals
- Release v1.0.0
Design overwiew:
- Main thread (producer): traverses directories and feeds the queue (one thread is more than enough for most use cases)
- Dedicated consumer thread: manages queue and distributes work to threadpool
- Worker threads: compute hashes in parallel
This separation of concerns is efficient because:
- Directory traversal is I/O bound and works well in a single thread
- Queue management is centralized, preventing race conditions
- Hash computation is CPU-intensive and properly parallelized