On 10/19/21 5:54 PM, Tim.Bird@xxxxxxxx wrote: > Well... Let me give some history, and then pontificate a little on the entry. > > Originally, this entry was created after Andrew Morton gave a talk at > an early Embedded Linux Conference, saying that there should be some > "ombudsman" for embedded issues in the kernel. This was in 2008. I've been doing this sort of thing on and off for a while, but I admit to gradually burning out over the years (sometime between https://www.spinics.net/lists/linux-embedded/msg00148.html and https://lkml.org/lkml/2017/9/13/651) as linux-kernel became actively hostile to hobbyists. > The linux-embedded mailing list was created about the same time. > The thinking was that there are issues that transcend any particular > sub-system, directory, or file, such as boot time or system size or > real-time. Changes to keep these system-wide metrics in check might > need the assistance of a respected upstream maintainer, who could > guide developers working in these areas, or who could help keep > other kernel maintainers apprised of requirements in these areas > for embedded products. Greg KH wouldn't listen to me when I was Documention maintainer. He wouldn't listen when I was busybox maintainer. Maintainer-without-portfolio ain't gonna get him to start. Keep in mind Greg and Kay Sievers were joined at the hip until Linus threw Kay out of Linux dev and he bogged off to systemd. If you point out things like "sysfs should to present a stable API to userspace" or "it's a bad idea to depend on magic packages like udev or systemd as things every Linux system must not only use verbatim from a single upstream supplier but must replace every time they upgrade the kernel", Greg is reliably against them. > I would say that realtime has been shepherded pretty well by Thomas > Gleixner (and it's almost all upstream!), independent of this entry. > The other system-wide issues (boot time and system size), people > have pretty much given up on, Nah, I've gotten them trimmed/working acceptably well in my systems. I just don't bother trying to poke linux-kernel about it anymore. Not since the Linux Foundation chased hobbyists out of Linux to the point where people literally started asking if hobbysts had ever really existed (circa https://lwn.net/Articles/563578/). Peter Anvin is actively hostile to the idea of reducing build-time dependencies (http://lkml.iu.edu/hypermail/linux/kernel/0802.1/4400.html) to the point that when my perl removal patches finally got traction in 2013 (after 5 years of follow-through), he switched one of his perl scripts to use bc instead so things like Gentoo and Linux From Scratch had to add a new build dependency for him (neither was installing bc before). This was after I'd convinced Denys to make ash do 64 bit math on 32 bit hosts so my shell translation ran under bash dash and ash, and then when that was rejected rewrote it in C, and when Andrew Morton went around him to take my patches THEN he piped up with a patch to keep the build complex. Circa 2018 or so when they made kconfig turing complete (so make oldconfig on a new kernel can "rm -rf ~" if it wants to) they added flex and bison as dependencies needed to run kconfig, when previously kconfig had .shipped versions of those files so as NOT to require that. I just bisected the v5.14 regression where building x86-64 breaks trying to #include "gelf.h" (from Jim Henson's Dark Crystal package), which I already personally fought off in 2018 for my own builds: https://twitter.com/landley/status/1064994639487426560 And the commit I just bisected it to (http://lkml.iu.edu/hypermail/linux/kernel/2110.3/00009.html) EXPLICITLY broke x86-64 (and only x86-64) to have a unique build-time dependency. In a patch that did NOTHING ELSE. Because why not? > although there is the occasional > patch to address a micro-symptom of the problem. But no one > is riding herd over the entire kernel to make sure that it doesn't > get too big, or boot too slow (or use too much power). Because the lkml clique is circling the wagons tighter and tighter until they achieve a black hole via proctology? There doesn't seem to be any actual malice, just a whole lot of territoriality and disdain for outsiders. It's not a thing that somebody's gonna do for fun, a topic you and I emailed about earlier this year if I recall. > This entry, and the linux-embedded mailing list itself, have not > functioned as originally intended in years, and I doubt anyone > uses this information. The tools don't use it > (e.g. get_maintainers.pl is never going to use this entry to > recommend someone be CC'ed on an "embedded" patch). Because that perl script matches files and the maintainers entry has no files. (Not that cc-ing random patches to lists strikes me as particularly useful. It usually just drives down the signal to noise ratio of the list in my experience. Patch 22/47 applies to arch/sh and thus the whole series is cc'd there...) > So, I guess I'd vote to get rid of it as well. > > But, I'm a little sad to see it go... :-( > I'll probably never see Linux on a cereal box. Oh there's plenty of people doing good work. I talk to Jeff Dionne daily, he's working on that sort of thing. I email Elliott Hughes (basically the android maintainer) multiple times per week. I talk to Rich Felker by voice every week (we're on the same wednesday call), and email or irc more often. (I feel guilty about dragging Elliott and Rich into https://www.mail-archive.com/austin-group-l@xxxxxxxxxxxxx/msg08569.html because I underestimated the amount of bikeshedding on a list that's primarily posts from the bug tracker and meeting announcements/minutes.) None of them particularly participate in linux-kernel (despite Rich being arch/sh maintainer, and yes I poke him about that every wednesday) because that community comes across to us outsiders as a toxic insular clique that does not remotely understand any of our needs, and acts threatened if we try to explain them. Not because we CAN'T, but because it DOESN'T HELP WHEN WE TRY. I'm the one who's considered weird for still (occasionally) engaging. Mostly as bug reports like the above, or patches I post so when somebody sues I can go "here it is in the list archives, not my fault they didn't merge it", or one-offs I expect to be ignored (ala http://lkml.iu.edu/hypermail/linux/kernel/2110.1/03713.html) although sometimes there's a discussion that peters out without resolution instead (ala http://lkml.iu.edu/hypermail/linux/kernel/2110.1/09327.html). *shrug* Just stubborn I guess. > -- Tim Rob
