ShabbyX / RTAI

(NO LONGER MAINTAINED) Clone of RTAI from https://www.rtai.org
28 stars 17 forks source link

RTAI updates? #23

Closed zultron closed 9 years ago

zultron commented 9 years ago

I'm looking at updating the Dovetail Automata kernel packages. There's a 3.18.12 ipipe patch and a matching patch in the magma branch. Looks like this repo hasn't been had a merge for a few months.

No urgency whatsoever, is there a plan to pull magma changes at some point?

ShabbyX commented 9 years ago

@zultron, Actually yes, there is a plan. You might know already, but now there are two sets of patches. One with suffix x and one without. The current magma branch doesn't work with the patches without x, even though there are a lot of #ifs on older non-x versions . What I have been waiting so far was to see whether the development will eventually go back to supporting those patches as well or not. I will ask this to clarify.

In other words, if I pull from magma (which in this repo is up-to-date, well up to 6 days ago) into dev, then RTAI wouldn't work unless you upgrade your kernel to one of the x versions as well. I was not sure whether I should go ahead and make this breaking change or not. You are the package maintainer though, so you should have a better judgement in this. For myself, I already have an x kernel built, so the update is not an issue. I would even prefer to install from your package and delete the one I built.

Anyway, if you think it's better to go ahead with the merge, I would do it quickly.

zultron commented 9 years ago

Wow, you're maintaining a lot of branches, not an easy job! Apologies for not noticing. My packages have always been based on master.

I'm actually working on 3.16.7, and there do appear to be HAL patches 1 in themagma branch designated with x for both 3.16.7 and 3.18.12.

I don't have any preference, likely because I don't understand the issues. I created 3.16.7 branches for the kernel packaging and the build scripts, and 3.0-rc4 branches for Xenomai. Making extra work makes NO sense, period. ;) Does it make any sense to do something similar for this case?

ShabbyX commented 9 years ago

Hahaha, no actually the magma branch is just updates from upstream (no changes by me), then there are a couple of old ones I kept "just in case", and two used by Alec. I'm really just taking care of master, and dev is not particularly especial. No need for apologies!

So, you have switched to the x suffix, is that right? I'm not sure if I understood your solution, but let me explain the situation more clearly. There are two series of patches for the kernel now. One with x suffix and one without. The ones without the x suffix work with the current state of this repo. To be more precise, commit a416758174f0077cd9fe56723e184f35c373fcdd is the last commit that would work on a kernel patched with a non-x patch. If I merge magma in right now, then the master branch would only work with the x patches.

So, I could branch out (although a tag seems sufficient also) the current master, and have the master support the x patches (the latest magma developments), and the tag (or branch) show which was the latest revision where a non-x patch had worked.

Would that work for you? To recap, I can merge in magma and you would have to switch over to x patches completely.

zultron commented 9 years ago

It's fine by me to switch to x patches. I have no plans to build new 3.8.13 kernels, but just in case that were needed, a branch or tag would be a useful bookmark. Otherwise, full steam ahead!

ShabbyX commented 9 years ago

I'm on it!

ShabbyX commented 9 years ago

Yesterday I merged magma into dev, but didn't get a chance to test it. I wouldn't be in the lab for a day or two, so if you felt like it, feel free to give dev a spin. You have write access to the repo, so you could fix obvious errors if there are any.

Otherwise I could do this maybe tomorrow or the day after.

ShabbyX commented 9 years ago

I just merged magma into master (there was only a minor build error) and things seem to work ok here. Please give it a try!

Also, I tagged the last commit that worked with non-x patch versions with 4.1, which should approximate the 4.1 release of RTAI.

zultron commented 9 years ago

Woo hoo, thank you! I'll give it a whirl ASAP.

zultron commented 9 years ago

Whoops, a bunch of merge markers in this file:

https://github.com/ShabbyX/RTAI/blob/master/base/arch/x86/defconfig

I'm a bit useless here, can you take a look? Thanks!

zultron commented 9 years ago

Also, in the case where there are two patches for a single kernel version (esp. 3.16.7), just use the higher-numbered patch?

https://github.com/ShabbyX/RTAI/tree/master/base/arch/x86/patches

zultron commented 9 years ago

As for the defconfig merge markers, my temporary solution was to make a guess at the config, then run it through make oldconfig. Probably not helpful to you, but just in case.

This also relates to issue #24, regarding the CONFIG_RTAI_SCHED_LATENCY_SELFCALIBRATE setting.

ShabbyX commented 9 years ago

Thanks for the fixes. I would suggest though, to use the master's defconfig instead of magma's as you have, and run it through make oldconfig. The master's defconfig includes what we had discussed in points from #17, such as enabling RTDM etc.

zultron commented 9 years ago

Ok, tried again: use master's defconfig and run through make oldconfig.

Appreciate the hand-holding, I just need it sometimes. ;)

ShabbyX commented 9 years ago

I merged in your commits, thanks! Now to try and see if I can fix the selfcalibration problem...