Re: [RFC] Provide in-kernel headers for making it easy to extend the kernel

[Enrico Weigelt, metux IT consult]

On 07.03.19 02:42, Joel Fernandes wrote:


Speaking as an embedded linux architect, who's daily job for a large
part is to getting bootloader, kernel, userland and customer
applications play nice together, in a stable, secure and easily
maintainable way:


> They would include the module because we can enforce that certain> config options in the kernel need to be enabled for Android features
to work.

Ok, but then you could also enforce them to simply put a tarball to the
module directory.

The modules need to built and deployed together with the kernel image
itself anyways, as well as they need to live on some filesystem that
has to be mounted at runtime. So, putting a tarball there is obvious
and trivial. No need to invent extra tools to build and use that stuff,
don't even need to touch the kernel source for that.

> As I said in previous posts, some people want to boot a kernel image without> any update to FS, for debug purposes.

So, it's just a workaround for your weird build/deployment mechanisms ?
(sorry, but I've got a hard time containing myself from starting a
really big rant against the Android architecture and build/deployment)

> In the Android/embedded world,> developers want to build and boot a single binary blob (for debugging).

Maybe in Android world (I didn't touch this for aeons - I'm just too
lazy add another hdd for it and wait days for everything pulled and
compiled), but in embedded world (speaking of: industrial machinery,
power plants, freighter ships, locomotives, medical devices or even
TV sets - that's the stuff I'm doing all the day), we usually either
build and deploy full system images (including the whole userland)
or use package management (eg. dpkg, ipkg, etc).

For me, as an embedded linux architect, the whole idea of having the
kernel have a completely different lifecycle process (even from a
completely different vendor) than the userland, is a really weird idea.

[ Yes: I've sometimes got customers with similar weird ideas (like BSP
coming from the board vendor, as a binary image, and they "just" put
their application ontop), but sooner or later this heavily crashes
against the wall, and then I can teach them how to do it right. ]

> Once they are done debugging, they can switch the CONFIG option back to> module instead of building it in and consuming memory, so that it is
not> loaded into memory until needed.
Okay, if it's just for debugging (in the lab, not in the field), then
why not fixing your development environment ? Why do you need that very
android specific stuff mainlined ?

Quite frankly: the whole thing really reminds me to the folks who wanna
push desktop bus into the kernel, just because their strange init system
is entirely based on that and they've created some nasty circular
dependencies. Please not yet another flamewar of that kind.

IMHO, you've got a serious architectural userland and development
environment problem (the massive problem of many millions completely
unmaintained and insecure devices in the field comes from exactly
that. Begins with the same fundamental mistakes which MS also still
refused learn, over decades - lack of a decent package management).

I doubt that workarounds in the kernel are good solution to that.

>> 3. Use a squashfs image instead of an archive.>
> This point number 3 sounds like a non-starter because it will make the kernel
> build system fail if squashfs-tools is not available. 

apt-get install squashfs-tools ?

Sorry, but the whole Android build machinery is so *extremly* huge,
that adding yet another tiny tool, which is in all relevant distros
for  aeons, really shouldn't be a problem worth even talking about.


--mtx

-- 
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
info@xxxxxxxxx -- +49-151-27565287