[cip-dev] How to develop on the RT version

[cip-dev] How to develop on the RT version

[Chris Brandt]

Hello CIP members,

As I look at the git repository, there are multiple PREEMPT_RT branches:

 * linux-4.4.y-cip-rt-rebase
 * linux-4.4.y-cip-rt
 * linux-4.4.y-cip-rt-patches

I'm trying to understand if I want to develop a product using RT, what branch should I be tracking and pulling into my local git repo?


I would think that locally, I would have some git repository that I will pull from CIP and merge into my own tree. I would also be pushing that to some local server to share with the other team members in my group.

Therefore, the 'rebase' thing doesn't make sense to me because if you are pushing a rebased tree, that means you are changing the existing parent history and doing a simple 'git pull' doesn't work so well (like what you have with the linux-next tree).


Do I just fetch and merge from 'linux-4.4.y-cip-rt' periodically as I develop my product, and that will play nicely with the local commits that I am also making and pushing locally to my repository?

Thank you,
Chris

[cip-dev] How to develop on the RT version

[Daniel Sangorrin]

Hi Chris,

> -----Original Message-----
> From: cip-dev-bounces at lists.cip-project.org [mailto:cip-dev-bounces at lists.cip-project.org] On Behalf Of Chris Brandt
> Sent: Friday, February 09, 2018 11:37 PM
> To: cip-dev at lists.cip-project.org
> Subject: [cip-dev] How to develop on the RT version
> 
> Hello CIP members,
> 
> As I look at the git repository, there are multiple PREEMPT_RT branches:
> 
>  * linux-4.4.y-cip-rt-rebase
>  * linux-4.4.y-cip-rt
>  * linux-4.4.y-cip-rt-patches
> 
> I'm trying to understand if I want to develop a product using RT, what branch should I be tracking and pulling into my local git repo?

This one: linux-4.4.y-cip-rt

> I would think that locally, I would have some git repository that I will pull from CIP and merge into my own tree. I would also be
> pushing that to some local server to share with the other team members in my group.
> 
> Therefore, the 'rebase' thing doesn't make sense to me because if you are pushing a rebased tree, that means you are changing the
> existing parent history and doing a simple 'git pull' doesn't work so well (like what you have with the linux-next tree).

The rebase branch is something complimentary, the maintainer may decide not to prepare it (the same with the patches).
# The rebase branch might useful to see clearly which patches come from the cip kernel and which ones are from PREEMPT RT.

> Do I just fetch and merge from 'linux-4.4.y-cip-rt' periodically as I develop my product, and that will play nicely with the local commits
> that I am also making and pushing locally to my repository?

That should work unless your local commits create some conflict. You can also rebase your local commits at the same time so that you
have them on the top of the git log for convenience.

Thank you,
Daniel 

[cip-dev] How to develop on the RT version

[Chris Brandt]

Hi Daniel,

Thank you for the reply!

On Wednesday, February 21, 2018, Daniel Sangorrin wrote:
> The rebase branch is something complimentary, the maintainer may decide
> not to prepare it (the same with the patches).
> # The rebase branch might useful to see clearly which patches come from
> the cip kernel and which ones are from PREEMPT RT.

OK, that was the info that I needed.

Thanks again,
Chris

[cip-dev] How to develop on the RT version

[Daniel Wagner]

Hi Chris,

On 22.02.2018 03:36, Chris Brandt wrote:
> On Wednesday, February 21, 2018, Daniel Sangorrin wrote:
>> The rebase branch is something complimentary, the maintainer may decide
>> not to prepare it (the same with the patches).
>> # The rebase branch might useful to see clearly which patches come from
>> the cip kernel and which ones are from PREEMPT RT.
> 
> OK, that was the info that I needed.

Sorry for the late response.

In short: linux-4.4.y-cip-rt wont be rebased. linux-4.4.y-cip-rt-rebase
tree contains the extracted patches from linux-4.4.y.cip-rt. Some people
like to get a patchset which they can apply on top of some tree. But it
looks no one here around is particular interested in this.

The linux-4.4.y-cip-patches is just a variation from the rebase branch.
Probably not really useful to anyone. I just archived all the a patches
in that branch. It was useful for me when I started with the scripting
to have a backup but I don't think I need it anymore. So if no one needs
I can drop it completely to avoid further confusion.

Thanks,
Daniel

[cip-dev] How to develop on the RT version

[Chris Brandt]

Hi Daniel,

On Thursday, February 22, 2018, Daniel Wagner wrote:
> In short: linux-4.4.y-cip-rt wont be rebased. linux-4.4.y-cip-rt-rebase
> tree contains the extracted patches from linux-4.4.y.cip-rt. Some people
> like to get a patchset which they can apply on top of some tree. But it
> looks no one here around is particular interested in this.
> 
> The linux-4.4.y-cip-patches is just a variation from the rebase branch.
> Probably not really useful to anyone. I just archived all the a patches
> in that branch. It was useful for me when I started with the scripting
> to have a backup but I don't think I need it anymore. So if no one needs
> I can drop it completely to avoid further confusion.


Thank you for this information.

I admit, I had 2 purposes for the question:

1. To be able to guild RZ/G customers on how to develop on the RT branch.

2. To get an idea of how to maintain the public repos for the RZ/A BSP with an RT branch. The 'rebase' branch thing didn't seem to make sense to me that anyone would want to follow that.

The current official RZ/A1 BSPs are 3.14, 4.9 and 4.14, although most of the drivers are mainlined at this point. So, maybe on the next CIP cycle, we'll support CIP for RZ/A as well.

Thanks,
Chris

[cip-dev] How to develop on the RT version

[Daniel Sangorrin]

> -----Original Message-----
> From: Daniel Sangorrin [mailto:daniel.sangorrin at toshiba.co.jp]
> Sent: Thursday, February 22, 2018 11:19 AM
> To: 'Chris Brandt' <Chris.Brandt@renesas.com>; 'cip-dev at lists.cip-project.org' <cip-dev@lists.cip-project.org>
> Subject: RE: [cip-dev] How to develop on the RT version
> 
> Hi Chris,
> 
> > -----Original Message-----
> > From: cip-dev-bounces at lists.cip-project.org [mailto:cip-dev-bounces at lists.cip-project.org] On Behalf Of Chris Brandt
> > Sent: Friday, February 09, 2018 11:37 PM
> > To: cip-dev at lists.cip-project.org
> > Subject: [cip-dev] How to develop on the RT version
> >
> > Hello CIP members,
> >
> > As I look at the git repository, there are multiple PREEMPT_RT branches:
> >
> >  * linux-4.4.y-cip-rt-rebase
> >  * linux-4.4.y-cip-rt
> >  * linux-4.4.y-cip-rt-patches
> >
> > I'm trying to understand if I want to develop a product using RT, what branch should I be tracking and pulling into my local git repo?
> 
> This one: linux-4.4.y-cip-rt
> 
> > I would think that locally, I would have some git repository that I will pull from CIP and merge into my own tree. I would also be
> > pushing that to some local server to share with the other team members in my group.
> >
> > Therefore, the 'rebase' thing doesn't make sense to me because if you are pushing a rebased tree, that means you are changing the
> > existing parent history and doing a simple 'git pull' doesn't work so well (like what you have with the linux-next tree).
> 
> The rebase branch is something complimentary, the maintainer may decide not to prepare it (the same with the patches).
> # The rebase branch might useful to see clearly which patches come from the cip kernel and which ones are from PREEMPT RT.
> 
> > Do I just fetch and merge from 'linux-4.4.y-cip-rt' periodically as I develop my product, and that will play nicely with the local commits
> > that I am also making and pushing locally to my repository?
> 
> That should work unless your local commits create some conflict. You can also rebase your local commits at the same time so that you
> have them on the top of the git log for convenience.

Of course, if you rebase the local changes, your team will have to do a hard reset after fetching the new changes.

> 
> Thank you,
> Daniel
>