For those who don't want to read everything, my questions are at the bottom.
Why my questions :
I'm in the process of understanding kernel adaptation to different boards or SoC. So my best bet is to play with RPi3
And Orange Pi2 
but without any decent support, this will only be for testing my knowledges.(then I'll later be in the process of understanding how Android HAL and HIDL are done - even if I'm not planning to do it myself in the future, I need a crystal clear understanding of what it means and implies).
My level of understanding :
I've already reached some steps : I've already played with buildroot and successfully customized settings of the 64bits kernel for the RPi3 using "make menuconfig", (also on Debian few month ago, in order to add GPIO sysfs and driver into some pico-ITX board in the past, that exists into the Linux Kernel available drivers code but wasn't enabled into the standard Debian kernel builds).
What I believe to know about existing differences :
As far as I understand, for each SoC, in addition of choosing a compatible architecture, there is functionalities that aren't into the mainline/vanilla kernel that could be added to the Kernel sources before building it, or after. CPU architecture can also be tuned : instead of using "generic x86_64" you can use the one that contains all of your last generation AMD CPU instructions for example, that would be used inside your Kernel instead of "being ignored for better compatibility".
Also, I believe I understood that, for drivers, what is the only available choice on Windows, can also be done one Linux : drivers can be loaded after the Kernel has been loaded to memory, using "insmod", or "/etc/modules". There is only one thing that is requiered : the kernel must be able to work enough, without those modules, to access the disk/partition that contains those modules, and load them (if not, game over - they should be statically included).
As the Kernel is perpetually changing, those Loadable Kernel Modules should be compiled against the currently used kernel, using "Kernel Headers", and then, they can be loaded at startup using "insmod", or "/etc/modules".
About drivers whose code is inside the Linux source code, make menuconfig also gives the possibility to disable, or enable them, with sometimes, the choice to build it into separated modules or permanently loaded modules.
Innocent question
Does it means that almost any system using Linux would be able to use the one and only one same build of the kernel ? (of course it must be some variants about CPU architectures and available instructions, and some isolated particular cases)
EDIT : obviously yes, in the personal computers world at least.
All my questions :
- Can someone correct me if I'm wrong into what I believe I understood ?
- What are the differences between Vanilla Kernel 4.14.67 and current Raspberry Pi Kernel 4.14.67 ? Is there a list ?
- Is it possible to put all of those differences into a "patch" that can be applied into the current vanilla kernel before building it ?
- If so, would it be possible for this patch to be applied on a previous or future Linux vanilla release ?
- Would it be possible to apply it on Android 4.14 kernel ?
- Are those differences into Kernel Modules only ?
- If so, is it possible to build it only as "Loadable Kernel Modules"
- Are "proprietary firmwares" a kind of plugins for Kernel Modules ? Or just binary blobs that should be sent to the hardware ?
Thank you (very, very) much in advance
