Reader Reactions

Recently, I covered a discussion in which the kernel developers talked about Spectre and Retbleed security issues cropping up on 32-bit kernels running on 64-bit hardware. The upshot was that by and large the developers seemed to feel that users shouldn't do this, and therefore there was no real need for the developers to worry too much about that specific case.

In response to that column, I received the following letter from Gary Dale, which articulated a point of view the kernel folks may not have considered. I'm including the letter here, with permission. Gary told me:

"I believe the kernel developers severely underestimate how many people may be running 32bit kernels on 64bit hardware. I, and a lot of other Raspberry Pi owners, are doing just that for a variety of reasons.

"In my particular case, I use my Pi 4B to run Kodi. However accessing Netflix, Prime and other streaming services requires the widevine library which only seems to exist in a 32bit version. Unfortunately, 32bit Kodi wouldn't install under multiarch. The 64bit Raspberry Pi OS is noticeably faster than the 32bit version but I'm stuck with the 32bit version due to digital restrictions.

"It can be argued that this is an artifact of the newness of 64bit Raspberry Pi OS and the ARM architecture. However this is just one case where it is necessary to run an OS that doesn't match the architecture. The kernel developers should probably be less dismissive of the potential problems."

I was really glad to get Gary's letter. If other readers start sharing thoughtful responses like this one, maybe "Reader Reactions" will become a regular part of this column. Reader reactions can always be sent to edit@linux-magazine.com. I read them all.

Tracking Up-to-Date Kernel Documentation

Carlos Bilbao recently took over maintainership of the kernel-docs.rst file in the kernel source tree, as well as the Spanish translation of that file. This file exists in the kernel's larger documentation directory hierarchy, which consists of many files that cover a wide array of developer activities, such as how to apply a patch or add a new system call.

The kernel-docs.rst file is a list of kernel documentation materials – starting with the larger documentation directory that the file is a part of. It also lists published books, online resources such as LWN.net, and so on. The top of the file explains, "The need for a document like this one became apparent in the linux-kernel mailing list as the same questions, asking for pointers to information, appeared again and again."

Carlos submitted a patch making himself the official maintainer of this file, and he also put out "a call for anyone interested in adding new, more up to date references to kernel-docs.rst. The document has been abandoned for a while but its original goal is still important."

Jonathan Corbet, maintainer of the LWN.net, replied, "I made an attempt to update this document a few years back and concluded that it was pretty much hopeless. What is there is ancient … what do you replace it with? There is a vast amount of content out there that will go obsolete just as quickly."

But having said that, Jonathan added, "I'm certainly not going to stand in the way of anybody who wants to update and maintain this document, though."

Carlos attempted to clarify the potential issues involved in maintaining the file. First, he said, Jonathan was right about how quickly any resources it listed would go out of date. And second, he said, there was a real need to keep the file updated in a way that a single maintainer would find very difficult to do.

He suggested a standard process that he and others might follow together. To purge out-of-date material, he suggested that he could go into the file a couple times per year and remove anything more than three years old, "except for foundational books or active websites."

As far as updating the file, Carlos felt access should be opened up to the people producing the kind of documentation that would be listed in it. He said, "For example, Lorenzo Stoakes is writing a book on the Linux memory management subsystem. If Lorenzo reaches out to me when he is finished, I could add his work to this document, and also send a note informing subscribers of linux-docs about this new resource. I imagine that would be appealing to Lorenzo."

Essentially, his idea was to entice content creators to reach out to him directly, thus taking some of the burden of ongoing research off of his shoulders as the file's maintainer. He added, "Worst-case scenario, we end up with an equally outdated list of resources in a few years."

Jonathan had no objection, and Carlos started composing a new patch to document this approach within the file.

It's always good to see documentation efforts come to life and find new ways to stay relevant. Hopefully people maintaining or producing kernel-related documentation will get in touch with Carlos and help keep the kernel-docs.rst file up-to-date.

Linux in Carspace

Christoph Fritz wanted to support Local Interconnect Network (LIN) in Linux. LIN is a cheap, standardized networking protocol intended mostly for car manufacturers, to stop the proliferation of incompatible systems on the road.

Christoph posted some patches in the hopes of rallying kernel developers for a general discussion on the best way forward. His company, hexDEV, had already written a kernel driver called hexLIN. He said "its purpose is mainly to test, adapt and discuss different LIN APIs for mainline Linux kernel. But it can already be used productively as a Linux LIN node." He added, "We are looking for partners with Linux based LIN projects for funding."

Oliver Hartkopp replied, saying that the LIN-bus open source project already existed, "and implements the LIN protocol based on a serial tty adaption (which the serial LIN protocol mainly is)."

Christoph said he knew about that project and had even cc'd Pavel Pisa, one of its principal developers, in his original email. He pointed out, "When there is an internal kernel API for LIN, his sllin (tty-line-discipline driver for LIN) could be adjusted and finally go mainline."

Pavel himself also replied, saying he would love to get access to some actual hardware; he gave a brief technical explanation of some of the implementation difficulties he'd been having with the project so far.

Meanwhile, Ryan Edwards also said, "I've spent quite a bit of time trying to craft a solution for the LIN problem. Even with a TTY solution the best I was able to achieve was 40ms turnaround between the header and response which exceeded the timeout of the master. This was in userspace and I assume that a kernel solution would better be able to meet the timing but this solution would only work for devices with embedded UART."

Christoph, Pavel, and Ryan dug into the nitty gritty together, and Christoph tried to keep the discussion focused on choosing a target application programming interface (API) that they should all aim for. To which, Andrew Lunn cautioned, "for networking in general, we try very hard to make offload to hardware not special at all. It should just transparently work. One example of this is Ethernet switches which Linux controls. The ports of the switch are just normal Linux interfaces. You can put an IP address onto the ports in the normal way, you can add a port to a linux bridge in the normal way. If the switch can perform bridging in hardware, the linux bridge will offload it to the hardware. But for the user, it's just a port added to a bridge, nothing special."

Andrew added in conclusion, "please try to avoid doing anything special for hardware offload. We don't want one way for software, and then 42 different ways for 42 different offload engines. Just one uAPI [Universal API] which works for everything."

The discussion ended fairly abruptly shortly thereafter. But it does seem that at least several kernel developers care about automotive networking and the LIN standard in particular. And at least one of those developers favors identifying the friendliest and most generic possible API to go into the kernel.

It's interesting to think about. Many car companies use Linux as their car operating system, so features such as LIN support may feel relatively important for them to get into the kernel. Another interesting possibility, as Linux becomes more and more able to control vehicles, is that users might root their cars and install custom Linux systems on them. Certainly plenty of car owners are actively trying to reverse-engineer the various platform-specific protocols on their cars. I'm sure something interesting will come out of all that eventually.