The SMBus standard specifies an address resolution protocol (SMBus ARP.) It has two key features :
* Handle I2C slave address collisions. If two SMBus slaves would use the same I2C address, ARP lets one of them pick a different address to avoid the address collision.
I would like to change the way "quilt setup" is implemented.
At the moment, we call rpmbuild and intercept the calls to tar and patch in order to record the location where archives are extracted and the order and options of the patches which apply to them. Then we replay that record to create our own quilt-compatible source tree.
On February 12th, 2015, the DMTF released version 3.0.0 of the System Management BIOS Reference Specification. This update isn't just adding enumerated values to existing structures, as previous updates did. It is also introducing a new entry point format which allows for larger tables and structures. Support for this needs to be added to dmidecode.
Additionally, reading the entry point and the table from /dev/mem is no longer possible on all systems, so some work is in progress to offer an alternative interface through sysfs. It would be great to finalize this and release a new version of dmidecode that would support both SMBIOS version 3.0 and this new kernel interface.
I have a few ideas of improvements for the delogo filter included in ffmpeg's libavfilter.
As a first step I would like to clean up the code by removing one unneeded option and then removing all the subsequently dead code.
The i2c-i801 kernel driver (for SMBus controller on most x86 Intel systems) has a lot of pending upstream patches from various contributors. There are bug fixes, clean-ups and new features. Without proper reviewing and merging work, most of the effort is likely to be lost.
So my project is to collect all contributions, review them, test as much as I can on the hardware I have, resolve all conflicts and submit a large single patch series upstream.
The SMBIOS specification includes an informative annex providing conformance guidelines for DMI table implementations. I would like to write a checker tool to verify the conformance of DMI tables, based on this document. Such a tool could be useful for system firmware writers.
We already have dmidecode which is able to locate and decode DMI tables. It should be fairly easy to reuse the same core and add an alternative structure parser, which would perform the checks instead of printing the decoded information.
While DDR4 memory has become quite popular, decode-dimms doesn't know about it and is not able to display any useful information for DDR4 memory modules. I would like decode-dimms to provide the same detailed information about DDR4 memory modules as it does for all older memory types.
In order to see the SPD (detailed memory information) data, the user currently has to manually load the needed kernel driver. Which driver to load depends on the memory type. Depending on the driver user, the devices may even have to be instantiated manually and this is a non-trivial multi-step task. Plus you need to be root to do it.
I would like to attempt to automatize all this at least in the most common and simple cases like Intel x86 desktop. The idea would be to figure out the memory type and the I2C address of the SPD EEPROMs based on DMI data. If the DMI data is of good quality then it should be possible to automatically figure out which driver to use and to instantiate the devices at boot time.
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.
The DMI table may contain BIOS-based error information. Currently dmidecode is not able to decode it. However an experimental patch was contributed a few years ago, which could be used as a starting point to enable this feature.
Back in June 2018, G. Branden Robinson submitted a 26-patch series intending to fix quilt's manual page, addressing both contents and technical issues with the roff formatting. I went through the whole series and reviewed it carefully. I recall I had many objections so there was a significant amount of work needed, including reordering some of the patches, before resubmitting a patch series I would consider committing. Unfortunately, the contributor vanished before resubmitting, and all the work from both sides went to oblivion.