General TC > Remasters / Remixes - Unofficial
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 :)
Navigation
[0] Message Index
[#] Next page
Go to full version