Spoiling Linux Kernel with "sanctioned" code - UoWPrint Blog

UoWPrint Blog

Home

Posts

Blame Wi-Fi drivers for printer (mDNS) discovery issues

Pantum M6500 Linux scanner driver issue

HP LaserJet MFP M28-M31 does not scan on Linux

Box64 vs FEX emulation performance on ARM Cortex-A53

Spoiling Linux Kernel with "sanctioned" code

Search

Previous

Next

Spoiling Linux Kernel with "sanctioned" code

Spoiling Linux Kernel with "sanctioned" code

…sending patches which can't be accepted, ever?

Last year I've fixed a bug in Linux kernel OHCI (USB 1.1) stack, which rendered<br>my old printer unreliable: OHCI adds artificial delay of 1ms for each USB<br>transfer of send-read pattern, while my very old, host-based printer expects very tight timings and<br>constant latency, like some kind of CnC machine.

This artificial delay was introduced in pre-git era (March 2004) as a race<br>condition fix for the USB OHCI host controllers of the time: Endpoint Descriptors<br>(EDs) are unlinked as soon as they become idle, but only after receiving next Start of Frame (SOF) interrupt.

The fix was small and rather simple: delay Endpoint Descriptors unlinking when they're idle for some time,<br>assuming that the ED will be reused soon. I've ended up moving the code into I/O watchdog which runs every 275ms: it fixes the latency<br>issue, should not affect compatibility with the controllers, and does not increase RAM consumption in all realistic USB 1.1 workloads I could think of.

Long story short: Greg Kroah-Hartman, the right hand of Linus Torvalds, the maintainer of linux-lts kernels, and the author of original OHCI code, never replies me. Not only me, but to other people from Russia as well, and to anyone asking about them, including other kernel maintainers.

As I've been told by the developers who spoke to him in person on this matter, lawyers recommend Greg not to communicate with people who might be designated or somehow affected by sanctions in any way, who can't be proven otherwise.

In other words, from my understanding, both I and the current USB stack maintainer have been denied any comment on my contribution from Greg only because I've emailed it from .ru domain.

However that's not what I wanted to talk about.

What I wanted to talk is as follows:

Send code contribution from any sanctioned country (Russia, Iran, North Korea), a proper bug fix

The code can't be merged into Linux kernel unless the contributor can verify they're not working in a sanctioned company of said country (guilty until proven innocent)

Other people who would like to have this bug fixed can't commit it from their name or reuse the code present in the mail list from assumingly sanctioned entity

The bug is forced to be fixed in some other way, not in a way it has been fixed by the bug fix contributor

As soon as the guilty-until-proven-innocent contributor sends the patch to the mail list, the kernel becomes spoiled with their code similar to how patents work: this exact bug fix can't be implemented in the very same way as the presumably-sanctioned entity did that.

Think about it.

Search

From here you can search these documents. Enter your search terms below.

Keyboard Shortcuts

Keys<br>Action

Open this help

Next page

Previous page

Search