Skip to main content

Search

Items tagged with: Kernel


6/ To follow up once more:

@tuxedocomputers relicensed all full inhouse code in their driver package to GPLv2+ : gitlab.com/tuxedocomputers/dev… πŸ‘

They are working on doing the same for the remaining drivers.

They also submitted a updated version of the patchset making the #Linux #Kernel's module loader treat some of the modules as proprietary; the list of modules handled that way is much shorter now:

lore.kernel.org/all/2024111513…

CC: @waldi


6/ To follow up:

There are now patches under discussion upstream to '"teach the [#Linux #Kernel's] module loader that these modules [from @tuxedocomputers ] are proprietary despite their declaration to be GPLv2 compatible "until the legal stuff is sorted out". "'

lore.kernel.org/all/2024111410…

CC: @waldi #LinuxKernel


5/ TWIMC and for the record:

Werner Sembach from @tuxedocomputers *reverted* Uwe's changes that made the drivers provide the right license to the #Linux #kernel's MODULE_LICENSE()[1] macro "until the legal stuff is sorted out":

gitlab.com/tuxedocomputers/dev…

Wondering why that happened – did they only notice now that the drivers do not compile any more because they use GPL-onlyed symbols, which are inaccessible for any non-GPLv2-compatible module?

CC: @waldi


4/ TWIMC and for the record:

Werner Sembach from @tuxedocomputers now merged Uwe's proposed changes that make the drivers provide the right license to the #Linux #kernel's MODULE_LICENSE()[1] macro. πŸ‘

gitlab.com/tuxedocomputers/dev…

(side note: I suspect the kernel will now taint itself as "proprietary" when loading these drivers, but haven't tried)

CC: @waldi


3/ It got even stranger: it seems @tuxedocomputers provided the wrong license to the #LinuxKernel's MODULE_LICENSE()[1] macro either by accident or on purpose. 🧐

@waldi pointed that out earlier today elsewhere in this thread; PWM maintainer Uwe Kleine-KΓΆnig a little later submitted a bug report asking this to be fixed:

gitlab.com/tuxedocomputers/dev…

[1] they proclaim it's GPL, which according to the #Linux #kernel's docs means "GPLv2" (either -only or -or-later), when in fact the code is GPLv3


TIL: @tuxedocomputers released #Linux #kernel drivers for their machines under the #GPLv3, which makes it impossible for competitors and distros to ship them pre-compiled, as that license is incompatible with the #LinuxKernel's #GPLv2 only license.

They did this purposely, allegedly to "keep control of the upstream pacing" – and want to re-license the code while upstreaming.

github.com/tuxedocomputers/tux…

gitlab.com/tuxedocomputers/dev…

gitlab.com/tuxedocomputers/dev…

gitlab.com/tuxedocomputers/dev…


My colleagues @gpiccoli and AndrΓ© Almeida will attend the Linux Kernel Recipes 2024 in Paris, between the 23rd and the 25th of September. Make sure to talk to him if you are interested in what Igalia works on that is related to the Linux kernel and general OS development.

#igalia #kernelrecipes #linux #kernel


The #Linux 6.12 pull request for #PREEMPT_RT is handed to Linus. Likely the first PR ever submitted in printed form. #kernel #LinuxKernel #Realtime


Linus Torvalds: Rust will go into Linux 6.1

At the Kernel Maintainers Summit, the question wasn't, "Would Rust make it into Linux?" Instead, it was, "What to do about its compilers?"

The Rust in Linux debate is over. The implementation has begun. In an email conversation, Linux's creator @torvalds told, "Unless something odd happens, it [Rust] will make it into 6.1."

🐧 zdnet.com/article/linus-torval…

#linux #rust #linustorvalds #rustlang #it #code #opensource #kernel #linuxkernel


#Linux #kernel patches to allow enabling #PREEMPT_RT (aka proper #realtime support) for x86, ARM64, and Risc-V were posted for review:

lore.kernel.org/lkml/202409061…

"The printk bits required for PREEMPT_RT are sitting in linux-next. This was the last known roadblock for PREEMPT_RT. The RT queue has additionally the "atomic console" for the 8250 UART which is not yet in linux-next.[…]"

See also these earlier other related toots:

fosstodon.org/@kernellogger/11…
fosstodon.org/@kernellogger/11…


I'd really like to read a well researched article that sums up how Linux distros reacted to the massive influx of #Linux #kernel CVE that started ~half a year – both for their #LinuxKernel packages and their live-patching offerings.

But I guess that is an enormous amount of work that no media outlet in this world is willing to pay anyone for writing. πŸ˜•

Slide taken from @gregkh's "Why are there so many kernel CVEs?" talk he gave at OSS China yesterday (social.kernel.org/objects/c997… ) #LinuxKernel


Since I've migrated from screen to tmux years ago, I always felt that missed screen's excellent support for serial devices.

But recently I found github.com/tio/tio which was developed exactly with that use case in mind and I couldn't be happier. Such an amazing tool.

#linux #kernel #embedded


"Many recent Intel laptops have […] a raw MIPI camera-sensor connected to the IPU6 found in recent Intel laptop chips.

[…] #Linux support for the IPU6 relies on an out of tree #kernel driver with a proprietary userspace stack […]

[…] Linaro has started a project to […] allow these cameras to work without needing proprietary software and Red Hat has joined Linaro in working on this. […]

This work is at a point now where it is ready for wider testing. […]"

hansdegoede.livejournal.com/27… #LinuxKernel

⇧