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
Officially Become a Kernel Hacker! by m.crivellari
Description
My studies as well my spare time are dedicated to the Linux Kernel. Currently I'm focusing on interrupts on x86_64, but my interests are not restricted to one specific topic, for now.
I also "played" a little bit with kernel modules (ie lantern, a toy packet analyzer) and I've added a new syscall in order read from a task A, the memory of a task B.
Maybe this will be a good chance to...
Goals
- create my first kernel patch
Resources
- https://www.kernel.org/doc/html/latest/process/submitting-patches.html
- https://git-send-email.io/ (mentioned also in the kernel doc)
- https://javiercarrascocruz.github.io/kernel-contributor-1
Achivements
- found while working on a bug, this is the 1st patch: cifs: avoid deadlocks while updating iface [✅ has been merged]
Modernize ocfs2 by goldwynr
Ocfs2 has gone into a stage of neglect and disrepair. Modernize the code to generate enough interest.
Goals: * Change the mount sequence to use fscontext * Move from using bufferhead to bio/folios * Use iomap * Run it through xfstests
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
Contributing to Linux Kernel security by pperego
Description
A couple of weeks ago, I found this blog post by Gustavo Silva, a Linux Kernel contributor.
I always strived to start again into hacking the Linux Kernel, so I asked Coverity scan dashboard access and I want to contribute to Linux Kernel by fixing some minor issues.
I want also to create a Linux Kernel fuzzing lab using qemu and syzkaller
Goals
- Fix at least 2 security bugs
- Create the fuzzing lab and having it running
The story so far
- Day 1: setting up a virtual machine for kernel development using Tumbleweed. Reading a lot of documentation, taking confidence with Coverity dashboard and with procedures to submit a kernel patch
- Day 2: I read really a lot of documentation and I triaged some findings on Coverity SAST dashboard. I have to confirm that SAST tool are great false positives generator, even for low hanging fruits.
- Day 3: Working on trivial changes after I read this blog post:
https://www.toblux.com/posts/2024/02/linux-kernel-patches.html. I have to take confidence
with the patch preparation and submit process yet.
- First trivial patch sent: using strtruefalse() macro instead of hard-coded strings in a staging driver for a lcd display
- Fix for a dereference before null check issue discovered by Coverity (CID 1601566) https://scan7.scan.coverity.com/#/project-view/52110/11354?selectedIssue=1601566
- Day 4: Triaging more issues found by Coverity.
- The patch for CID 1601566 was refused. The check against the NULL pointer was pointless so I prepared a version 2 of the patch removing the check.
- Fixed another dereference before NULL check in iwlmvmparsewowlaninfo_notif() routine (CID 1601547). This one was already submitted by another kernel hacker :(
- Day 5: Wrapping up. I had to do some minor rework on patch for CID 1601566. I found a stalker bothering me in private emails and people I interacted with me, advised he is a well known bothering person. Markus Elfring for the record.
Wrapping up: being back doing kernel hacking is amazing and I don't want to stop it. My battery pack is completely drained but changing the scope gave me a great twist and I really want to feel this energy not doing a single task for months.
I failed in setting up a fuzzing lab but I was too optimistic for the patch submission process.
The patches
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
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
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.