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
