netlink interface for ethtoola project by mkubecek 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). 
|
Boot system from Ceph RADOS Block Devicean idea by dmdiss Write a new Dracut module which adds support for booting a system where the root filesystem resides on a remote RBD image. * Pack keyring and ceph.conf (monitor address) in the initramfs image |
Add Ceph support for Azure RESTful protocolsan idea by dmdiss Microsoft Azure offers a bunch of interesting RESTful protocols, providing access to objects (Block Blobs, similar to S3 Objects), disk images (Page Blobs) and file systems (Azure Files). The underlying services seem to map pretty closely to RADOS, RBD and CephFS respectively, so adding support for these protocols to Ceph, despite being a lot of work, should be relatively straightforward. I've already worked on implementing a C client for these protocols via Elasto, so it might be worth reusing the same code in implementing the server functionality atop the public librados / librbd / libcephfs libraries. The other option would be to use civetweb/rgw, which is already embedded within Ceph for S3/SWIFT gateway support. |
|
|
ethtool ops for netdevsima project by mkubecek This can be seen as a subproject of ethtool netlink interface but from the technical view it's independent. Every new piece of software is going to be buggy and with frequent changes and rewrites, new regressions are introduced. Automated selftests can help a lot but as ethtool deals with hardware devices, we do not want these tests to depend on a specific hardware. The netdevsim driver was created as a virtual device which (unlike e.g. dummy) cannot be used for actual network traffic but implements various configuration interfaces so that it can be used for their (automated) testing.
|
|
dmidecode: no more open-coded printfsa project by jdelvare There's a long standing request to extend the output of dmidecode to something that would be machine-readable. Something like an XML or JSON-based format. Unfortunately this can't be implemented right now because the output of dmidecode is generated by open-coded printfs as the DMI table is being parsed, with no intermediate structures nor temporary buffers. While implementing a machine-parseable output is out of scope for a single hack week, let's remember that even the longest journey starts with a single footstep. I would like to try and rewrite the 5200 lines of code of dmidecode in such a way that printing the output would be somewhat separated from parsing the DMI table and done by a limited set of dedicated functions. Alternative output formats could later hook into such functions. 
|
make "predictable network interface names" more predictablean idea by mkubecek Since the so-called "predictable names" for network interfaces were introduced, the concept and mainly its implementation has been a target of a lot of critique and sometimes even hate. On the other hand, similar idea works reasonably well for block devices. In my opinion, the main reason why "predictable names" reception was not nearly as good as for block devices is the difference in how the implementation works. For block devices, the device name provided by kernel is preserved and other names based on multiple naming schemes (by path, by UUID, by various device identifiers) are created as symlinks so that all of them (including the original kernel one) can be used simultaneously. On the other hand, network interface has only one name and as it is not represented by a file, symlinks cannot be used for aliases. Therefore even if there are multiple naming schemes (e.g. based on BIOS enumeration, bus address etc.), only one of them can be used for each network device and it's rather unpredictable which one is it going to be. Moreover, some of the generated names are rather long, ugly and inconveninent and unlike with block devices, one cannot just ignore them and use a different name (e.g. one provided by kernel). |
Phoebe - where AI meets Linuxa project by mvarlese Project DescriptionPhoeβe (/ˈfiːbi/) wants to add basic artificial intelligence capabilities to the Linux OS. 
|
Make parted great again!
.png){kind=small}
L3: Improve crash-setup, develop a core-setup
Improving picotm
