search

jlelli / sched-deadline-archive

An implementation of the popular Earliest Deadline First (EDF) scheduling algorithm or the Linux kernel. It is still experimental code, and it is still continuously being improved, but it already is a fully-working solution for supporting typical real-time applications in GNU/Linux environments.
Other
49 stars 31 forks source link

cross compile for powerpc #7

Open choudhariashish opened 11 years ago

choudhariashish commented 11 years ago

I was wondering if a patch of sched-deadline kernel is available to use with linux-3.0.34-rt55

linux-3.0.34-rt55 we use for booting freescale's p4080 platform, it would be great if we could add support for EDF scheduling in this kernel.

Thank You

jlelli commented 11 years ago

Unfortunately, the latest available -rt branch is based on 3.2.13-rt23.

I don't have available time to work on a back-port right now, but if are willing to attempt it I can provide support.

On 01/30/2013 03:14 PM, choudhariashish wrote:

I was wondering if a patch of sched-deadline kernel is available to use with linux-3.0.34-rt55

linux-3.0.34-rt55 we use for booting freescale's p4080 platform, it would be great if we could add support for EDF scheduling in this kernel.

Thank You

— Reply to this email directly or view it on GitHub https://github.com/jlelli/sched-deadline/issues/7.

avasu commented 11 years ago

Hello jlelli, Thanks for your support. I am also working on the same project with choudhariashish. I would like to know more details about how I can port it back to linux-3.0.34-rt55. Could you please share some details about how to back-port it to linux-3.0.34-rt55? Thanks, A Vasu

jlelli commented 11 years ago

I fear this would require a massive effort. The only way I know (and did in the past) is to take the last version of the patchset (git format-patch on the last patch before the series) and then try to apply the patches one after the other to the Linux version you're using. This will generate lot of rejects, especially with a 3.0.x kernel version.

Best,

dfaggioli commented 11 years ago

On Tue, 2013-02-05 at 15:45 -0800, Juri Lelli wrote:

I fear this would require a massive effort.

I completely agree with Juri. Back in the days when I was "in charge" I did/tied many of these backports, and it always was a massive pain!

The only way I know (and did in the past) is to take the last version of the patchset (git format-patch on the last patch before the series) and then try to apply the patches one after the other to the Linux version you're using. This will generate lot of rejects, especially with a 3.0.x kernel version.

Indeed. The procedure is also what I think works best but, believe me, even trying such a backport will "cost" you much more than using a different (more recent!) kernel for whatever it is that you want to achieve!

Regards, Dario

<<This happens because I choose it to happen!>> (Raistlin Majere)

Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)

avasu commented 11 years ago

Hello,

I understand the difficulties involved in backporting the patchset to an older version. Since the project requirement is to use the older version of kernel, we have no other option. If there are any documentation on the backporting, can you please share it with me? It would be of great help to us.

Thanks Aishwarya

jlelli commented 11 years ago

Hi, the process itself is pretty easy, something like:

git format-patch HEAD~(before first patch)
git apply --reject 000x-some-patch.patch
find . -name *.rej

and then try to fix problems one after the other.

The arduous part is figuring out where "things" were several years ago, be sure to not introduce bugs during the porting process and also be sure that the mechanism behaves as expected in the end. :)

Best,