LWN: Comments on "The 2022 embedded Linux update"

The 2022 embedded Linux update

rschwebel — Tue, 12 Jul 2022 08:35:09 +0000

One thing that hasn't been solved yet is GPL friendly NDAs from chip vendors. It is still standard that the "purpose" of an NDA is "evaluation" or "building hardware with a chip". Writing software seems like a non-usecase. With many chip vendors it is still impossible to get an NDA that says "the manual itself is confidential, but it is allowed to write open source software with it" or having a proper patch clearance process.

There are of course several chip vendors out there who just put their reference manuals on the internet, such as NXP, Microchip/Atmel etc., which makes it quite easy to write proper upstream kernel code. There is a reason why those have really good mainline support...

Huhu Tim, remember me, next time you talk to the IMX camera department folks :-)

Speaking of updates

fratti — Tue, 12 Jul 2022 03:06:10 +0000

I can't speak from a maintainer's point of view, just of that from someone who does run mainline linux on my embedded devices, and makes mainline Linux run on them by porting downstream code.

> But suppose the BSP is being written for a piece of custom hardware that has a FPGA that implements a custom peripheral. Should the driver for something that only exists in a few devices in the world be upstreamed?

I think the usual cutoff is that if there is at least one user of the driver in the mainline Linux tree, it stays. If you are a business selling very expensive low volume scientific equipment with custom FPGA peripherals to select businesses, you'll probably sell that with software support as a whole service package, so users of said devices are unlikely to be running mainline Linux even if it were possible. In that case I agree, upstreaming such a driver (or even submitting it to mainline, as opposed to just code dumping it somewhere) would be counter-productive and a waste of time on everyone's part.

However, asking the question of "how could this be useful for mainline" usually already leads down the path of refactoring code to be more generic and in turn better. As an example, I recently came across an out-of-tree vendor driver for a DCF-77 time signal receiver card that implements a vendor specific userspace interface. I wondered how this could be made generic across vendors, and discovered that there currently (to my knowledge) was no Linux kernel uapi for authoritative time keeping sources such as atomic clocks or time keeping radio signal receivers, because apparently everyone who makes these never actually tried to upstream their work. It's a niche product, but the kernel would still be better off if there was a generic way to support these niche devices.

> Similarly for the DTS files that pull it all togther, do we really want all the DTS files for every embedded Linux system in the world in the upstream kernel?

In my opinion, yes. Naturally if it's a device that's never brought to market, it doesn't make sense, but erring on the side of "too many" is better in my opinion. Chances are most of your device tree's interesting parts will be in the SoC's dtsi, which is useful for every other device that uses the same SoC and may also want to be upstream. A lot of the DT review process is also already automated with tooling that can generate useful (and sometimes not so useful) warnings about common pitfalls.

Maintainers may of course disagree with me here as they'd rather get fewer submissions as to ease their workload. But I for one would love if my now 6 year old phone had an upstreamed DT written against mainline bindings even if nobody would've run mainline Linux on it when it came out (but they might want to now with that becoming a thing). I also wouldn't mind a device tree for my parents' laundry machine that inexplicably runs FreeBSD; device trees are conceptually independent of kernels after all, and the motor in that thing will probably outlast the official software support for its solid state electronics.

So I guess I should rephrase my statement: If you are a SoC vendor or have been hired to work for one, please don't stop at board support packages; at least upstream the SoC parts.

Speaking of updates

mfuzzey — Mon, 11 Jul 2022 20:39:22 +0000

> stop with the board support packages

How realistic *or* desirable (from the upstream point of view) is this?

If as part of building a BSP I write a driver for some currently unsupported COTS chip, or fix bugs in existing in tree code then I definitely agree upstream is the way to go because that driver could be used in many other devices so benefits everyone (and I get the free code review as you say).

But suppose the BSP is being written for a piece of custom hardware that has a FPGA that implements a custom peripheral. Should the driver for something that only exists in a few devices in the world be upstreamed?

Similarly for the DTS files that pull it all togther, do we really want all the DTS files for every embedded Linux system in the world in the upstream kernel? It's great for dev boards, SOMs, and maybe some consumer products that can be repurposed but many devices aren't even publicly available.

Speaking of updates

fratti — Mon, 11 Jul 2022 17:16:45 +0000

I've started engaging with embedded Linux just recently (5.16 is the first kernel with some driver code touched by me) and it's great so see how much else is happening in the space that is not always readily visible to people like myself who mostly work on SoC support as a hobby.

Something I wish people working in the space professionally would push for more is that vendors upstream their driver code. Everybody knows why they don't, I'm preaching the choir here if I state why they should and how it makes sense for them as a business decision, but I'd be beating a dead horse. I have huge respect for contractors in the embedded world who do upstream their work, such as Collabora, Pengutronix or BayLibre to name a few.

Please just... stop with the board support packages. If you are hired to develop a board support package, also submit the patches upstream, they'll be better for it. If you are working at a company that internally develops its board support packages, tell your manager about this cool way you could get a free code review.

The 2022 embedded Linux update

geert — Fri, 08 Jul 2022 07:18:16 +0000

AVG definitely existed at the 2003 Plenary Meeting in Las Vegas. Same for system size and boot time.
So I'm afraid security was the afterthought that was not part of the original big 5 ;-)

The oldest presentations Google found[1][2] list 8 working groups. the Embedded Linux Wiki page[3] is newer, and lists a different set of 5.

[1] https://elinux.org/images/8/82/CE_Linux_Forum-Ueda-Bird.pdf
[2] https://slidetodoc.com/status-of-embedded-linux-celf-plen...
[3] https://elinux.org/CE_Linux_Forum

The 2022 embedded Linux update

tbird20d — Fri, 08 Jul 2022 01:32:40 +0000

Oh, shoot! Yes I did. I'm trying to remember if that was one of the original workgroups we created at our first 2003 "requirements" meeting, or if it came along a bit later. But it was a big part of CELF's efforts for a number of years. Embedded Linux never did standardize around a single user-space library for graphics, but the kernel's framebuffer API saw a lot of significant use in those early days.

The 2022 embedded Linux update

geert — Thu, 07 Jul 2022 09:23:41 +0000

Looks like he missed the CELF AVG (audio/video/graphics) workgroup.

The 2022 embedded Linux update

bartoc — Thu, 07 Jul 2022 03:59:21 +0000

And openwrt itself has no auto-update mechanism!

My netgear's stock operating system, which is likely based on openwrt has such a mechanism and it works pretty well

The 2022 embedded Linux update

mtaht — Thu, 07 Jul 2022 00:32:15 +0000

Grumpily: home router vendors are often shipping 10 year old kernels, based on an obsolete, hacked up, vendor specific, unsupported version of openwrt.

Nobody knows how many "security" cameras are based on Linux because few in that market comply with the GPL.

It really is great that Linux has so much of the embedded market now, but "fossilized" FOSS is costing the world a lot in lost security, features, and developer interest.

Being there (at handhelds.org and MontaVista) I remember vividly the most compelling argument for linux in embedded in the 00s... was MMU support.