Kernel Upgrades...

[CentralWare]

I'm tinkering with a concept I'd like a bit of input on (programmatically) to see if this is even possible.

I'm currently utilizing TC4 within a VM (3.0.21) and am experimenting with an idea, but I figured it best to ask the experts before diving too deep.

I downloaded the latest stable (3.19) kernel a little while ago and ran through make config by just holding down the ENTER key in order to get into menuconfig.  I changed things around a little more "TC" oriented (probably not exact) which is the cause for this post.

Considering the 4.x tinycore config file is going to be lacking a good deal of items found in the higher, vanilla (unpatched) kernel, can you think of any way to update the new .config based on the older tinycore specific .config?

In my way of thinking, updating the patches could be done by simply scanning the source tree looking for the file(s) needing to be patched, scan through the file(s) looking for the old identifiers from the patch files and if found, update line numbers, etc. as needed and move onto the next.  This is not likely a "perfect" method but should do the job in at least some of the areas being updated.  For patch files that weren't able to find the content, we'd simply have to go through the sources manually (unless deprecated) but it should at least cut down on the leg-work.

If this could be done with the .config files as well, this would be awesome.  (Update the basic/default .config with the items used in a given release of TC and note those not found, again, cutting down on manual intervention quite a bit.)  Even the make config could be automated by simply sending a pipe to it from a file with nothing more than a few hundred line feeds (unless there's a command line variable that could be sent in which tells it to configure based on defaults, such as --no-prompt or what-not.)

Most importantly (regarding this post) Can anyone see any caveats upgrading a kernel, compiled with similar features, being implemented into an existing TC?
(ie: Kernel x.x.x crashes when trying to do (some extension) under TC.)

Thoughts/suggestions are appreciated!


EDIT: I missed the part in the documentation regarding make oldconfig and just now tripped over it.  LOL...  I haven't come across anything such as patch oldpatchfiles but if anyone has ideas I'd love to hear them!

[Juanito]

"make oldconfig" will automate "make config" as long as the tinycore config is copied into the top level of the source as .config.

Why not use tc-6.x?

[CentralWare]

@Juanito: When I was going back 'n forth between versions I kept finding pieces missing from 5.x/6.x needed to run the show for the test servers here, so I've stuck with 4.x as my sandbox with the thought of "...if something was built for 4.x, theoretically it should work up-stream as long as the dependencies are available or can easily be accommodated/compiled."  If the kernel upgrades were to be "universal" so to speak, in a sense, there wouldn't "be" much of a versioning system (4.x, 6.x, etc.) and upgrading software (extensions/firmware/drivers) would be a breeze from both a development side as well as a machine use.

Plus...  it seemed like a viable challenge!

[Juanito]

'be nice if you could have a go at contributing some of the missing pieces for 5.x/6.x then we could all move on 

What exactly are you missing?

[bmarkus]

I have a very bad experience with kernels. New minor versions released in every few weeks and main version completely disapear in a short time, see

https://www.kernel.org/

Usually x.y ... x.y.3 or even higher are full with errors, they look experimental and deeply untested. Also it happened few times in last monthes that a minor release was published few days after previous. If you read changelog, significant part of changes are fixing bugs in previous releases.

Choosing and testing a kernel which you can trust takes lot of time and testing. On the other hand playing with leading edge kernels, learning kernel through making own custom versions is a great and exciting challenge

[curaga]

You can use vanilla kernels with TC fine. Some features likely won't work, for example in 4.x we used compcache which is now zram.

[CentralWare]

@Béla: With a community-supported environment, that's not overly surprising.  (One dev makes a tweak to item "A" which breaks "B" and "C" in the process.)
* I started compiling 3.19 about 10 minutes ago in a VM...  I have a little time to burn

On the other hand...  that's the only way you find out what works and what doesn't (and in my opinion, ten revisions can be merged into one working version when necessary with the right version control system and a few scripts to strip out the working code for each area of interest.)

One of the biggest challenges we'll ever face (on a kernel level) is new hardware implementations.  If I saw correctly, ACPI support is still at 4.x...  and on a hardware level, I believe the specs for 5.x are already being implemented.  When someone takes on the task of putting spec into code...  I don't imagine it'll work "out of the box."  On the flip-side...  OLDER hardware is just as challenging as fewer people have access to it, thus testing is usually minimal.

Add this, to what I just read about the NSA and it makes me wonder quite a few things about "anything" being safe on the market.
http://arstechnica.com/security/2015/02/how-omnipotent-hackers-tied-to-the-nsa-hid-for-14-years-and-were-found-at-last

Regardless, thanks for your input and take care!

[CentralWare]

@Curaga: Yes...  I noticed when I ran the 4.x patches.  If Linus' rule about "never break anything backware compatible" is true, I imagine it should still be in there somewhere; it's just a matter of finding it.