[Xenomai] Raspberry Pi - 3.10.34

[Xenomai] Raspberry Pi - 3.10.34

[Gregory Dymarek]

To get kernel 3.10.34 to work the ipipe patch needs updating.
(ipipe-3.8.x does not apply cleanly).

What is the process to release a new ipipe patch for 3.10.34?

Or what is the alternative?


Thanks,
Gregory

Re: [Xenomai] Raspberry Pi - 3.10.34

[Lowell Gilbert]

Gregory Dymarek <gregd72002@gmail.com> writes:

> To get kernel 3.10.34 to work the ipipe patch needs updating.
> (ipipe-3.8.x does not apply cleanly).
>
> What is the process to release a new ipipe patch for 3.10.34?
>
> Or what is the alternative?

The source control trees are easily available, so there are a lot of
options.

I did a "git merge" to bring the ipipe-3.10 branch into my 3.10 kernel
branch. If I didn't have a lot of my own (evolving) hardware to deal
with, I might not have needed to merge at all, so the ipipe-3.10 branch
itself might be good enough for some people. 

Producing the patch may be as simple as a simple "git diff" operation.

Re: [Xenomai] Raspberry Pi - 3.10.34

[Gilles Chanteperdrix]

On 03/27/2014 04:33 PM, Lowell Gilbert wrote:
> Gregory Dymarek <gregd72002@gmail.com> writes:
>
>> To get kernel 3.10.34 to work the ipipe patch needs updating.
>> (ipipe-3.8.x does not apply cleanly).
>>
>> What is the process to release a new ipipe patch for 3.10.34?
>>
>> Or what is the alternative?
>
> The source control trees are easily available, so there are a lot of
> options.
>
> I did a "git merge" to bring the ipipe-3.10 branch into my 3.10 kernel
> branch. If I didn't have a lot of my own (evolving) hardware to deal
> with, I might not have needed to merge at all, so the ipipe-3.10 branch
> itself might be good enough for some people.
>
> Producing the patch may be as simple as a simple "git diff" operation.

It is a bit more complicated than that:
- git diff will produce a huge patch with all the architectures in, for 
this reason, there is a script in the I-pipe git to output only the 
changes for arm, scripts/ipipe/genpatches.sh
- if you want your patch to be distributed with Xenomai, we do not take 
a complete patch for the forked kernel, which would duplicate a lot of 
the contents of the vanilla patch, and lead to a maintenance nightmare 
every time we want to update the generic parts of the patch.

So, we use -pre and -post patches, which contain only the changes 
necessary for the forked kernel. The -pre patch is applied on the forked 
kernel sources so that the mainline patch applies, then the -post patch 
is applied after to revert the changes made by the -pre patch, and add 
the changes specific to the forked kernel.

In order to generate a -pre and -post patch. Start by merging the 
ipipe-3.10 branch with your forked kernel, as Gilbert says. This will be 
your reference branch.

Create a branch which contains only the forked kernel. Try and apply the 
mainline patch in "dry-run" mode. Reset every file which causes a 
conflict with the patch to the contents of the mainline kernel. The 
difference between the result of this operation and the forked kernel is 
the -pre patch.

Apply the mainline patch, which should apply without conflicts.

The difference between the reference branch and the result of this 
operation is the -post patch.

You can then verify that starting from the forked kernel, and applying, 
in this order, the -pre, the mainline, and the -post patches leads to 
the same result as your reference branch.

>
> _______________________________________________
> Xenomai mailing list
> Xenomai@xenomai.org
> http://www.xenomai.org/mailman/listinfo/xenomai
>


-- 
					    Gilles.

Re: [Xenomai] Raspberry Pi - 3.10.34

[Gregory Dymarek]

Ok, I think I'm on top of it. Will post all the patches once I test
them properly.

Another question on the topic of PRE and POST patches. Is there a
reason why prepare-kernel.sh cannot invoke PRE and POST patches
automatically?

I'm trying to get this into a buildroot and it does not support pre
and post patches. Also, I'm getting a push back on adding the support
for pre- and post- ipipe patches into buildroot.

On 27 March 2014 18:37, Gilles Chanteperdrix
<gilles.chanteperdrix@xenomai.org> wrote:
> On 03/27/2014 04:33 PM, Lowell Gilbert wrote:
>>
>> Gregory Dymarek <gregd72002@gmail.com> writes:
>>
>>> To get kernel 3.10.34 to work the ipipe patch needs updating.
>>> (ipipe-3.8.x does not apply cleanly).
>>>
>>> What is the process to release a new ipipe patch for 3.10.34?
>>>
>>> Or what is the alternative?
>>
>>
>> The source control trees are easily available, so there are a lot of
>> options.
>>
>> I did a "git merge" to bring the ipipe-3.10 branch into my 3.10 kernel
>> branch. If I didn't have a lot of my own (evolving) hardware to deal
>> with, I might not have needed to merge at all, so the ipipe-3.10 branch
>> itself might be good enough for some people.
>>
>> Producing the patch may be as simple as a simple "git diff" operation.
>
>
> It is a bit more complicated than that:
> - git diff will produce a huge patch with all the architectures in, for this
> reason, there is a script in the I-pipe git to output only the changes for
> arm, scripts/ipipe/genpatches.sh
> - if you want your patch to be distributed with Xenomai, we do not take a
> complete patch for the forked kernel, which would duplicate a lot of the
> contents of the vanilla patch, and lead to a maintenance nightmare every
> time we want to update the generic parts of the patch.
>
> So, we use -pre and -post patches, which contain only the changes necessary
> for the forked kernel. The -pre patch is applied on the forked kernel
> sources so that the mainline patch applies, then the -post patch is applied
> after to revert the changes made by the -pre patch, and add the changes
> specific to the forked kernel.
>
> In order to generate a -pre and -post patch. Start by merging the ipipe-3.10
> branch with your forked kernel, as Gilbert says. This will be your reference
> branch.
>
> Create a branch which contains only the forked kernel. Try and apply the
> mainline patch in "dry-run" mode. Reset every file which causes a conflict
> with the patch to the contents of the mainline kernel. The difference
> between the result of this operation and the forked kernel is the -pre
> patch.
>
> Apply the mainline patch, which should apply without conflicts.
>
> The difference between the reference branch and the result of this operation
> is the -post patch.
>
> You can then verify that starting from the forked kernel, and applying, in
> this order, the -pre, the mainline, and the -post patches leads to the same
> result as your reference branch.
>
>>
>> _______________________________________________
>> Xenomai mailing list
>> Xenomai@xenomai.org
>> http://www.xenomai.org/mailman/listinfo/xenomai
>>
>
>
> --
>                                             Gilles.

Re: [Xenomai] Raspberry Pi - 3.10.34

[Gilles Chanteperdrix]

On 03/28/2014 03:22 PM, Gregory Dymarek wrote:
> Ok, I think I'm on top of it. Will post all the patches once I test
> them properly.
>
> Another question on the topic of PRE and POST patches. Is there a
> reason why prepare-kernel.sh cannot invoke PRE and POST patches
> automatically?
>
> I'm trying to get this into a buildroot and it does not support pre
> and post patches. Also, I'm getting a push back on adding the support
> for pre- and post- ipipe patches into buildroot.

No reason except the fact that -pre and -post patches are a temporary 
solution while the support for the board is integrated into the mainline 
kernel. Now, given the evolution pace of ARM platforms, it seems we will 
always have -pre and -post patches, so it would make sense to add this 
support to prepare-kernel.sh. So, the answer to your question is "patch 
welcome".


-- 
					    Gilles.

Re: [Xenomai] Raspberry Pi - 3.10.34

[Gregory Dymarek]

Thanks Gilles.

Before I start messing around with the prepare-kernel.sh can someone
review the proposal please?


add --board flag:
   tells the script about the target board. If unspecified, no board
specific patches will be applied.

suggest to modify prepare-kernel.sh in the following way:
- construct pre ipipe patch name:
patches/$board/ipipe-core-$linux_version-$board-pre-*
- construct post ipipe patch name similar to above
- if pre patch exist - apply before ipipe_patch
- if post patch exist - apply after ipipe_patch



This calls for board patch standards. Is there a standard for patch
names currently in place?
My I suggest ipipe-core-$linux_version-$board-{pre,post}-*

This above might not work if custom adeos patch is specified. Should we care?


Thanks,
Gregory

On 28 March 2014 14:34, Gilles Chanteperdrix
<gilles.chanteperdrix@xenomai.org> wrote:
> On 03/28/2014 03:22 PM, Gregory Dymarek wrote:
>>
>> Ok, I think I'm on top of it. Will post all the patches once I test
>> them properly.
>>
>> Another question on the topic of PRE and POST patches. Is there a
>> reason why prepare-kernel.sh cannot invoke PRE and POST patches
>> automatically?
>>
>> I'm trying to get this into a buildroot and it does not support pre
>> and post patches. Also, I'm getting a push back on adding the support
>> for pre- and post- ipipe patches into buildroot.
>
>
> No reason except the fact that -pre and -post patches are a temporary
> solution while the support for the board is integrated into the mainline
> kernel. Now, given the evolution pace of ARM platforms, it seems we will
> always have -pre and -post patches, so it would make sense to add this
> support to prepare-kernel.sh. So, the answer to your question is "patch
> welcome".
>
>
> --
>                                             Gilles.

Re: [Xenomai] Raspberry Pi - 3.10.34

[Gregory Dymarek]

Hi,

Included patch that adds support for --board parameter to the
prepare_kernel.sh script.

When --board is provided the script will look for optional board
patches in the folder that ipipe patch is and in $board subfolder if
exsists.
It expects the patch name to be: {ipipe_base_name}-{board_name}-{pre,post}-*
Where {ipipe_base_name} is the ipipe name before the last '-'.

Example:
For ipipe-core-3.10.18-arm-1.patch and board=raspberry it will look for:
- ipipe-core-3.10.18-arm-raspberry-{pre,post}-*.patch

Regards,
Gregory


On 28 March 2014 15:00, Gregory Dymarek <gregd72002@gmail.com> wrote:
> Thanks Gilles.
>
> Before I start messing around with the prepare-kernel.sh can someone
> review the proposal please?
>
>
> add --board flag:
>    tells the script about the target board. If unspecified, no board
> specific patches will be applied.
>
> suggest to modify prepare-kernel.sh in the following way:
> - construct pre ipipe patch name:
> patches/$board/ipipe-core-$linux_version-$board-pre-*
> - construct post ipipe patch name similar to above
> - if pre patch exist - apply before ipipe_patch
> - if post patch exist - apply after ipipe_patch
>
>
>
> This calls for board patch standards. Is there a standard for patch
> names currently in place?
> My I suggest ipipe-core-$linux_version-$board-{pre,post}-*
>
> This above might not work if custom adeos patch is specified. Should we care?
>
>
> Thanks,
> Gregory
>
> On 28 March 2014 14:34, Gilles Chanteperdrix
> <gilles.chanteperdrix@xenomai.org> wrote:
>> On 03/28/2014 03:22 PM, Gregory Dymarek wrote:
>>>
>>> Ok, I think I'm on top of it. Will post all the patches once I test
>>> them properly.
>>>
>>> Another question on the topic of PRE and POST patches. Is there a
>>> reason why prepare-kernel.sh cannot invoke PRE and POST patches
>>> automatically?
>>>
>>> I'm trying to get this into a buildroot and it does not support pre
>>> and post patches. Also, I'm getting a push back on adding the support
>>> for pre- and post- ipipe patches into buildroot.
>>
>>
>> No reason except the fact that -pre and -post patches are a temporary
>> solution while the support for the board is integrated into the mainline
>> kernel. Now, given the evolution pace of ARM platforms, it seems we will
>> always have -pre and -post patches, so it would make sense to add this
>> support to prepare-kernel.sh. So, the answer to your question is "patch
>> welcome".
>>
>>
>> --
>>                                             Gilles.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pre_post_prepare_kernel.patch
Type: text/x-patch
Size: 3060 bytes
Desc: not available
URL: <http://www.xenomai.org/pipermail/xenomai/attachments/20140331/d8469c53/attachment.bin>