[Xenomai] 4.x merge

[Xenomai] 4.x merge

[Henning Schild]

Hi,

i am about to merge ipipe into a more recent kernel and would like to
discuss the approach with you guys. As far as i have seen and been told
i should merge and not rebase.

My current plan:
1 choose release (4.1 since its LTS)
2 merge it into ipipe
3 resolve obvious conflicts
4 commit broken merge
5 repair common bits and x86
6 publish my tree for others to repair other archs

Steps 2,3 and 4 might become iterations stepping over 3.19 and 4.0. The
merges will not work but the smaller steps will result in less
conflicts at a time.

What do you guys think of the approach? Are my version choices sane or
are there any reasons to consider other releases as well?

Henning

Re: [Xenomai] 4.x merge

[Jorge Ramirez Ortiz]

On 09/09/2015 05:31 AM, Henning Schild wrote:
> Hi,
> 
> i am about to merge ipipe into a more recent kernel and would like to
> discuss the approach with you guys. As far as i have seen and been told
> i should merge and not rebase.
> 
> My current plan:
> 1 choose release (4.1 since its LTS)

Sounds good to me.
We are working on 3.18 for [0] - SMP still not functional
If you take lead on 4.0 I can then validate the arm64 bit port we do on this [1]
 SoC as well

[0] https://www.96boards.org/products/ce/hikey/
[1] https://www.96boards.org/products/ce/dragonboard410c/


> 2 merge it into ipipe
> 3 resolve obvious conflicts
> 4 commit broken merge
> 5 repair common bits and x86
> 6 publish my tree for others to repair other archs
> 
> Steps 2,3 and 4 might become iterations stepping over 3.19 and 4.0. The
> merges will not work but the smaller steps will result in less
> conflicts at a time.
> 
> What do you guys think of the approach? Are my version choices sane or
> are there any reasons to consider other releases as well?
> 
> Henning
> 

-- 
jro

Re: [Xenomai] 4.x merge

[Henning Schild]

Hey guys,

i now have a working 3.19 kernel that passed basic testing on x86. I
guess it is ready to be tested on other archs, where it might not even
compile. I did my best to resolve conflicts and hope it is pretty close
to working.

I actually decided to merge mainline step by step. When i got merge
conflicts i aborted big merges and narrowed down the conflicts to
merging single commits/series. That resulted in about 180 commits,
mostly merges. 

I think that big amount of commits is actually useful for others too,
so i would like to share it somehow. When testing arm or powerpc you
can bisect in that and when you find a broken merge commit you will
know exactly which patches from mainline caused the problem.

Whether we want hundreds of merge commits in the main ipipe-repo in the
end is something we could discuss. The merge could be condensed down to
one commit to clean up. But i am generally all for keeping history.

Please let me know where i could best push my changes. As we speak here
i am already using the same partial-merge technique for 4.0 until i
arrive at 4.1. It seems to be a pretty good way of keeping up with
mainline.

Henning

On Wed, 9 Sep 2015 09:01:36 -0400
Jorge Ramirez Ortiz <jro@xenomai.org> wrote:

> On 09/09/2015 05:31 AM, Henning Schild wrote:
> > Hi,
> > 
> > i am about to merge ipipe into a more recent kernel and would like
> > to discuss the approach with you guys. As far as i have seen and
> > been told i should merge and not rebase.
> > 
> > My current plan:
> > 1 choose release (4.1 since its LTS)
> 
> Sounds good to me.
> We are working on 3.18 for [0] - SMP still not functional
> If you take lead on 4.0 I can then validate the arm64 bit port we do
> on this [1] SoC as well
> 
> [0] https://www.96boards.org/products/ce/hikey/
> [1] https://www.96boards.org/products/ce/dragonboard410c/
> 
> 
> > 2 merge it into ipipe
> > 3 resolve obvious conflicts
> > 4 commit broken merge
> > 5 repair common bits and x86
> > 6 publish my tree for others to repair other archs
> > 
> > Steps 2,3 and 4 might become iterations stepping over 3.19 and 4.0.
> > The merges will not work but the smaller steps will result in less
> > conflicts at a time.
> > 
> > What do you guys think of the approach? Are my version choices sane
> > or are there any reasons to consider other releases as well?
> > 
> > Henning
> > 
> 

Re: [Xenomai] 4.x merge

[Henning Schild]

On Tue, 15 Sep 2015 10:48:54 +0200
Henning Schild <henning.schild@siemens.com> wrote:

> Hey guys,
> 
> i now have a working 3.19 kernel that passed basic testing on x86. I
> guess it is ready to be tested on other archs, where it might not even
> compile. I did my best to resolve conflicts and hope it is pretty
> close to working.
> 
> I actually decided to merge mainline step by step. When i got merge
> conflicts i aborted big merges and narrowed down the conflicts to
> merging single commits/series. That resulted in about 180 commits,
> mostly merges. 
> 
> I think that big amount of commits is actually useful for others too,
> so i would like to share it somehow. When testing arm or powerpc you
> can bisect in that and when you find a broken merge commit you will
> know exactly which patches from mainline caused the problem.
> 
> Whether we want hundreds of merge commits in the main ipipe-repo in
> the end is something we could discuss. The merge could be condensed
> down to one commit to clean up. But i am generally all for keeping
> history.
> 
> Please let me know where i could best push my changes. As we speak
> here i am already using the same partial-merge technique for 4.0
> until i arrive at 4.1. It seems to be a pretty good way of keeping up
> with mainline.

I did push my current state to github. Check out 
https://github.com/siemens/linux-ipipe
branches ipipe-3.19 and -4.0

The xenomai repos also require patching if you want to use these newer
kernels. I will send the required patches as a reply to this mail.

Henning

[Xenomai] [PATCH xenomai2 1/2] adopt to kernel change c0371da6047abd261bc483c744dbc7d81a116172

[Henning Schild]

Signed-off-by: Henning Schild <henning.schild@siemens.com>
---
 include/rtdm/rtdm.h | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/include/rtdm/rtdm.h b/include/rtdm/rtdm.h
index d907f08..5da5687 100644
--- a/include/rtdm/rtdm.h
+++ b/include/rtdm/rtdm.h
@@ -49,6 +49,8 @@
 
 #ifdef __KERNEL__
 
+#include <linux/fs.h>
+#include <linux/uio.h>
 #include <linux/types.h>
 #include <linux/fcntl.h>
 #include <linux/ioctl.h>
@@ -295,8 +297,12 @@ static inline ssize_t rt_dev_recvfrom(int fd, void *buf, size_t len, int flags,
 
 	msg.msg_name = from;
 	msg.msg_namelen = from ? *fromlen : 0;
+#ifdef __KERNEL__
+	iov_iter_init(&msg.msg_iter, READ, &iov, 1, len);
+#else
 	msg.msg_iov = &iov;
 	msg.msg_iovlen = 1;
+#endif
 	msg.msg_control = NULL;
 	msg.msg_controllen = 0;
 
@@ -351,8 +357,12 @@ static inline ssize_t rt_dev_sendto(int fd, const void *buf, size_t len,
 
 	msg.msg_name = (struct sockaddr *)to;
 	msg.msg_namelen = tolen;
+#ifdef __KERNEL__
+	iov_iter_init(&msg.msg_iter, WRITE, &iov, 1, len);
+#else
 	msg.msg_iov = &iov;
 	msg.msg_iovlen = 1;
+#endif
 	msg.msg_control = NULL;
 	msg.msg_controllen = 0;
 
-- 
2.4.6

[Xenomai] [PATCH xenomai2 2/2] scripts: make kernel 4.x ready

[Henning Schild]

Signed-off-by: Henning Schild <henning.schild@siemens.com>
---
 scripts/prepare-kernel.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/prepare-kernel.sh b/scripts/prepare-kernel.sh
index 021c650..ac438c6 100755
--- a/scripts/prepare-kernel.sh
+++ b/scripts/prepare-kernel.sh
@@ -456,7 +456,7 @@ case $linux_VERSION.$linux_PATCHLEVEL in
     #  Linux v2.6 and 3.x section
     #
 
-    2.6|3.*)
+    2.6|3.*|4.*)
 
     config_file=Kconfig
 
-- 
2.4.6

[Xenomai] [PATCH xenomai3 1/2] adopt to kernel change c0371da6047abd261bc483c744dbc7d81a116172

[Henning Schild]

Signed-off-by: Henning Schild <henning.schild@siemens.com>
---
 include/cobalt/kernel/compat.h    |  3 ++-
 include/cobalt/kernel/rtdm/rtdm.h |  8 ++++----
 kernel/cobalt/posix/compat.c      | 14 ++++++++------
 kernel/cobalt/posix/syscall32.c   |  5 +++--
 4 files changed, 17 insertions(+), 13 deletions(-)

diff --git a/include/cobalt/kernel/compat.h b/include/cobalt/kernel/compat.h
index b0ef81e..c21ee31 100644
--- a/include/cobalt/kernel/compat.h
+++ b/include/cobalt/kernel/compat.h
@@ -136,7 +136,8 @@ int sys32_put_siginfo(void __user *u_si, const struct siginfo *si,
 		      int overrun);
 
 int sys32_get_msghdr(struct msghdr *msg,
-		     const struct compat_msghdr __user *u_cmsg);
+		     const struct compat_msghdr __user *u_cmsg,
+		     int direction);
 
 int sys32_put_msghdr(struct compat_msghdr __user *u_cmsg,
 		     const struct msghdr *msg);
diff --git a/include/cobalt/kernel/rtdm/rtdm.h b/include/cobalt/kernel/rtdm/rtdm.h
index 7b1b33a..e269231 100644
--- a/include/cobalt/kernel/rtdm/rtdm.h
+++ b/include/cobalt/kernel/rtdm/rtdm.h
@@ -19,6 +19,8 @@
 #ifndef _COBALT_RTDM_RTDM_H
 #define _COBALT_RTDM_RTDM_H
 
+#include <linux/fs.h>
+#include <linux/uio.h>
 #include <linux/types.h>
 #include <linux/fcntl.h>
 #include <linux/ioctl.h>
@@ -91,8 +93,7 @@ ssize_t rtdm_recvfrom(int s, void *buf, size_t len, int flags,
 	iov.iov_len = len;
 	msg.msg_name = from;
 	msg.msg_namelen = from ? *fromlen : 0;
-	msg.msg_iov = &iov;
-	msg.msg_iovlen = 1;
+	iov_iter_init(&msg.msg_iter, READ, &iov, 1, len);
 	msg.msg_control = NULL;
 	msg.msg_controllen = 0;
 
@@ -122,8 +123,7 @@ static inline ssize_t rtdm_sendto(int s, const void *buf, size_t len,
 	iov.iov_len = len;
 	msg.msg_name = (struct sockaddr *)to;
 	msg.msg_namelen = tolen;
-	msg.msg_iov = &iov;
-	msg.msg_iovlen = 1;
+	iov_iter_init(&msg.msg_iter, WRITE, &iov, 1, len);
 	msg.msg_control = NULL;
 	msg.msg_controllen = 0;
 
diff --git a/kernel/cobalt/posix/compat.c b/kernel/cobalt/posix/compat.c
index 6118f8a..1aaa374 100644
--- a/kernel/cobalt/posix/compat.c
+++ b/kernel/cobalt/posix/compat.c
@@ -15,6 +15,7 @@
  * along with this program; if not, write to the Free Software
  * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
  */
+#include <linux/uio.h>
 #include <linux/err.h>
 #include <linux/module.h>
 #include <cobalt/kernel/compat.h>
@@ -338,17 +339,19 @@ int sys32_put_siginfo(void __user *u_si, const struct siginfo *si,
 EXPORT_SYMBOL_GPL(sys32_put_siginfo);
 
 int sys32_get_msghdr(struct msghdr *msg,
-		     const struct compat_msghdr __user *u_cmsg)
+		     const struct compat_msghdr __user *u_cmsg,
+		     int direction)
 {
 	compat_uptr_t tmp1, tmp2, tmp3;
+	compat_size_t tmp4;
 
 	if (u_cmsg == NULL ||
 	    !access_rok(u_cmsg, sizeof(*u_cmsg)) ||
 	    __xn_get_user(tmp1, &u_cmsg->msg_name) ||
 	    __xn_get_user(msg->msg_namelen, &u_cmsg->msg_namelen) ||
 	    __xn_get_user(tmp2, &u_cmsg->msg_iov) ||
-	    __xn_get_user(msg->msg_iovlen, &u_cmsg->msg_iovlen) ||
 	    __xn_get_user(tmp3, &u_cmsg->msg_control) ||
+	    __xn_get_user(tmp4, &u_cmsg->msg_iovlen) ||
 	    __xn_get_user(msg->msg_controllen, &u_cmsg->msg_controllen) ||
 	    __xn_get_user(msg->msg_flags, &u_cmsg->msg_flags))
 		return -EFAULT;
@@ -357,9 +360,8 @@ int sys32_get_msghdr(struct msghdr *msg,
 		msg->msg_namelen = sizeof(struct sockaddr_storage);
 
 	msg->msg_name = compat_ptr(tmp1);
-	msg->msg_iov = compat_ptr(tmp2);
 	msg->msg_control = compat_ptr(tmp3);
-
+	iov_iter_init(&msg->msg_iter, direction, compat_ptr(tmp2), 1, tmp4);
 	return 0;
 }
 EXPORT_SYMBOL_GPL(sys32_get_msghdr);
@@ -371,8 +373,8 @@ int sys32_put_msghdr(struct compat_msghdr __user *u_cmsg,
 	    !access_wok(u_cmsg, sizeof(*u_cmsg)) ||
 	    __xn_put_user(ptr_to_compat(msg->msg_name), &u_cmsg->msg_name) ||
 	    __xn_put_user(msg->msg_namelen, &u_cmsg->msg_namelen) ||
-	    __xn_put_user(ptr_to_compat(msg->msg_iov), &u_cmsg->msg_iov) ||
-	    __xn_put_user(msg->msg_iovlen, &u_cmsg->msg_iovlen) ||
+	    __xn_put_user(ptr_to_compat(msg->msg_iter.iov), &u_cmsg->msg_iov) ||
+	    __xn_put_user(msg->msg_iter.nr_segs, &u_cmsg->msg_iovlen) ||
 	    __xn_put_user(ptr_to_compat(msg->msg_control), &u_cmsg->msg_control) ||
 	    __xn_put_user(msg->msg_controllen, &u_cmsg->msg_controllen) ||
 	    __xn_put_user(msg->msg_flags, &u_cmsg->msg_flags))
diff --git a/kernel/cobalt/posix/syscall32.c b/kernel/cobalt/posix/syscall32.c
index b3ce8a7..7cfe3bb 100644
--- a/kernel/cobalt/posix/syscall32.c
+++ b/kernel/cobalt/posix/syscall32.c
@@ -15,6 +15,7 @@
  * along with this program; if not, write to the Free Software
  * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
  */
+#include <linux/fs.h>
 #include <linux/types.h>
 #include <linux/err.h>
 #include <cobalt/uapi/syscall.h>
@@ -736,7 +737,7 @@ COBALT_SYSCALL32emu(recvmsg, probing,
 	struct msghdr m;
 	ssize_t ret;
 
-	ret = sys32_get_msghdr(&m, umsg);
+	ret = sys32_get_msghdr(&m, umsg, READ);
 	if (ret)
 		return ret;
 
@@ -753,7 +754,7 @@ COBALT_SYSCALL32emu(sendmsg, probing,
 	struct msghdr m;
 	int ret;
 
-	ret = sys32_get_msghdr(&m, umsg);
+	ret = sys32_get_msghdr(&m, umsg, WRITE);
 
 	return ret ?: rtdm_fd_sendmsg(fd, &m, flags);
 }
-- 
2.4.6

[Xenomai] [PATCH xenomai3 2/2] adopt to kernel change 3a161d99c43ce74c76aecff309be4c3ba455e823

[Henning Schild]

Signed-off-by: Henning Schild <henning.schild@siemens.com>
---
 kernel/cobalt/trace/cobalt-posix.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/cobalt/trace/cobalt-posix.h b/kernel/cobalt/trace/cobalt-posix.h
index 2382615..07e5e92 100644
--- a/kernel/cobalt/trace/cobalt-posix.h
+++ b/kernel/cobalt/trace/cobalt-posix.h
@@ -92,7 +92,7 @@ DECLARE_EVENT_CLASS(syscall_exit,
 
 #define cobalt_print_sched_params(__policy, __p_ex)			\
 ({									\
-  	const char *__ret = p->buffer + p->len;				\
+	const char *__ret = p->buffer + p->seq.len;			\
 	switch (__policy) {						\
 	case SCHED_QUOTA:						\
 		trace_seq_printf(p, "priority=%d, group=%d",		\
-- 
2.4.6

Re: [Xenomai] 4.x merge

[Jorge Ramirez Ortiz]

On 09/17/2015 08:39 AM, Henning Schild wrote:
> I did push my current state to github. Check out 
> https://github.com/siemens/linux-ipipe
> branches ipipe-3.19 and -4.0
> 
> The xenomai repos also require patching if you want to use these newer
> kernels. I will send the required patches as a reply to this mail.
> 
> Henning

Thanks Henning.
I will use this as a base for the DragonBoard 410 (runs mainstream) in a couple
of weeks.


-- 
jro

Re: [Xenomai] 4.x merge

[Jorge Ramirez Ortiz]

On 09/17/2015 08:39 AM, Henning Schild wrote:
> I did push my current state to github. Check out 
> https://github.com/siemens/linux-ipipe
> branches ipipe-3.19 and -4.0
> 
> The xenomai repos also require patching if you want to use these newer
> kernels. I will send the required patches as a reply to this mail.
> 

ok for me to clone your repo and start adding on the aarch64 support?


-- 
jro

Re: [Xenomai] 4.x merge

[Henning Schild]

On Wed, 14 Oct 2015 09:11:49 -0400
Jorge Ramirez Ortiz <jro@xenomai.org> wrote:

> On 09/17/2015 08:39 AM, Henning Schild wrote:
> > I did push my current state to github. Check out 
> > https://github.com/siemens/linux-ipipe
> > branches ipipe-3.19 and -4.0
> > 
> > The xenomai repos also require patching if you want to use these
> > newer kernels. I will send the required patches as a reply to this
> > mail.
> > 
> 
> ok for me to clone your repo and start adding on the aarch64 support?

Sorry for the late reply.

Sure, go ahead. You might have to rebase it later since i am not sure
how much of that work will be merged.
I pushed 4.1 a couple of days ago. And Philippe is also working on 4.1.

Henning 

Re: [Xenomai] 4.x merge

[Jorge Ramirez Ortiz]

> 
> I did push my current state to github. Check out 
> https://github.com/siemens/linux-ipipe
> branches ipipe-3.19 and -4.0



I just noticed -while reusing some of your changes for aarch64 - that his needs
fixing (redeclaration of 'flags')
https://github.com/siemens/linux-ipipe/blob/ipipe-4.0/drivers/irqchip/irq-gic.c#L270

cheers
jorge

Re: [Xenomai] 4.x merge

[Jorge Ramirez Ortiz]

On 10/14/2015 06:16 PM, Jorge Ramirez Ortiz wrote:
> 
>>
>> I did push my current state to github. Check out 
>> https://github.com/siemens/linux-ipipe
>> branches ipipe-3.19 and -4.0
> 
> 
> 
> I just noticed -while reusing some of your changes for aarch64 - that his needs
> fixing (redeclaration of 'flags')
> https://github.com/siemens/linux-ipipe/blob/ipipe-4.0/drivers/irqchip/irq-gic.c#L270
> 

Hi Henning,

have you tried running the switchtest with the boot parameter
xenomai.supported_cpus=0x1?



-- 
jro

Re: [Xenomai] 4.x merge

[Philippe Gerum]

On 10/20/2015 05:07 PM, Jorge Ramirez Ortiz wrote:
> On 10/14/2015 06:16 PM, Jorge Ramirez Ortiz wrote:
>>
>>>
>>> I did push my current state to github. Check out 
>>> https://github.com/siemens/linux-ipipe
>>> branches ipipe-3.19 and -4.0
>>
>>
>>
>> I just noticed -while reusing some of your changes for aarch64 - that his needs
>> fixing (redeclaration of 'flags')
>> https://github.com/siemens/linux-ipipe/blob/ipipe-4.0/drivers/irqchip/irq-gic.c#L270
>>
> 
> Hi Henning,
> 
> have you tried running the switchtest with the boot parameter
> xenomai.supported_cpus=0x1?
> 
> 
> 

That won't work, switchtest attempts to spread the rt test load over all
online CPUs, which your kernel setting contradicts.

-- 
Philippe.

Re: [Xenomai] 4.x merge

[Gilles Chanteperdrix]

On Tue, Oct 20, 2015 at 05:35:12PM +0200, Philippe Gerum wrote:
> On 10/20/2015 05:07 PM, Jorge Ramirez Ortiz wrote:
> > On 10/14/2015 06:16 PM, Jorge Ramirez Ortiz wrote:
> >>
> >>>
> >>> I did push my current state to github. Check out 
> >>> https://github.com/siemens/linux-ipipe
> >>> branches ipipe-3.19 and -4.0
> >>
> >>
> >>
> >> I just noticed -while reusing some of your changes for aarch64 - that his needs
> >> fixing (redeclaration of 'flags')
> >> https://github.com/siemens/linux-ipipe/blob/ipipe-4.0/drivers/irqchip/irq-gic.c#L270
> >>
> > 
> > Hi Henning,
> > 
> > have you tried running the switchtest with the boot parameter
> > xenomai.supported_cpus=0x1?
> > 
> > 
> > 
> 
> That won't work, switchtest attempts to spread the rt test load over all
> online CPUs, which your kernel setting contradicts.

That will not work without passing any argument to switchtest, but
can work if you specify to switchtest a list of tasks to run on the
first cpu.

Such as:
# switchtest rtk0 rtk0 rtk_fp0 rtk_fp0 rtk_fp_ufpp0 rtkfp_ufpp0 rtup0 \
rtup0 rtup_ufpp0 rtup_ufpp0 rtus0 rtus0 rtus_ufps0 rtus_ufps0 \
rtuo0 rtuo0 rtuo_ufpp0 rtuo_ufpp0 rtuo_ufps0 rtuo_ufps0 \
rtuo_ufpp_ufps0 rtuo_ufpp_ufps0

-- 
					    Gilles.
https://click-hack.org

Re: [Xenomai] 4.x merge

[Gilles Chanteperdrix]

On Wed, Sep 09, 2015 at 11:31:51AM +0200, Henning Schild wrote:
> Hi,
> 
> i am about to merge ipipe into a more recent kernel and would like to
> discuss the approach with you guys. As far as i have seen and been told
> i should merge and not rebase.
> 
> My current plan:
> 1 choose release (4.1 since its LTS)
> 2 merge it into ipipe
> 3 resolve obvious conflicts
> 4 commit broken merge
> 5 repair common bits and x86
> 6 publish my tree for others to repair other archs
> 
> Steps 2,3 and 4 might become iterations stepping over 3.19 and 4.0. The
> merges will not work but the smaller steps will result in less
> conflicts at a time.
> 
> What do you guys think of the approach? Are my version choices sane or
> are there any reasons to consider other releases as well?

I did not answer because I am not sure my opinion really matters. I
am only maintaining one architecture, and have not even worked on it
for a long time. And have already expressed this opinion several
times. But since you are asking for it:

- merging with mainline to maintain the modifications made by the
I-pipe tree is a bad solution: 
. first because it is more time consuming than what we did before,
that is reapplying the I-pipe patch and fixing the conflicts:
. second because the I-pipe changes get lost in the middle of the
upstream commits, so the idea that by doing this we could keep the
history of changes in the I-pipe tree does not work;
. third because when you do the merge, you can not easily ignore the
conflicts for the other architecture than the one you are currently
working on.

- merging by iterating over releases is even more time consuming: it
is far from exceptional to see the same piece of code changed by
several consecutive releases, with your method you get one conflict
by iteration, if you skip all the releases with one big iteration,
that means fixing only one conflict.

- I believe the right solution is to maintain the changes made by
the I-pipe tree as a stack of commits applied on top of the upstream
kernel, maintained with git. That means using git rebase to switch
from one release to the next, and amend each commit to fix the
conflicts. This way, every patch becomes a meaningful change to the
upstream kernel, we keep the history of changes, and they all appear
on top of the upstream commits, making them easy to identify in the
git logs. Splitting architecture specific patches allows every
architecture maintainer to focus on his architecture, and not have
to care about the other architecture commits. Note that I have
maintained the FCSE patch (split in something like 7 or 8 commits)
for several kernel releases, and I noticed no particular difficulty
doing so.


-- 
					    Gilles.
https://click-hack.org

Re: [Xenomai] 4.x merge

[Henning Schild]

On Tue, 29 Sep 2015 20:03:45 +0200
Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org> wrote:

> On Wed, Sep 09, 2015 at 11:31:51AM +0200, Henning Schild wrote:
> > Hi,
> > 
> > i am about to merge ipipe into a more recent kernel and would like
> > to discuss the approach with you guys. As far as i have seen and
> > been told i should merge and not rebase.
> > 
> > My current plan:
> > 1 choose release (4.1 since its LTS)
> > 2 merge it into ipipe
> > 3 resolve obvious conflicts
> > 4 commit broken merge
> > 5 repair common bits and x86
> > 6 publish my tree for others to repair other archs
> > 
> > Steps 2,3 and 4 might become iterations stepping over 3.19 and 4.0.
> > The merges will not work but the smaller steps will result in less
> > conflicts at a time.
> > 
> > What do you guys think of the approach? Are my version choices sane
> > or are there any reasons to consider other releases as well?
> 
> I did not answer because I am not sure my opinion really matters. I
> am only maintaining one architecture, and have not even worked on it
> for a long time. And have already expressed this opinion several
> times. But since you are asking for it:
> 
> - merging with mainline to maintain the modifications made by the
> I-pipe tree is a bad solution: 
> . first because it is more time consuming than what we did before,
> that is reapplying the I-pipe patch and fixing the conflicts:
> . second because the I-pipe changes get lost in the middle of the
> upstream commits, so the idea that by doing this we could keep the
> history of changes in the I-pipe tree does not work;
> . third because when you do the merge, you can not easily ignore the
> conflicts for the other architecture than the one you are currently
> working on.
>
> - merging by iterating over releases is even more time consuming: it
> is far from exceptional to see the same piece of code changed by
> several consecutive releases, with your method you get one conflict
> by iteration, if you skip all the releases with one big iteration,
> that means fixing only one conflict.

I found the approach to work OK and surprisingly fast. In some series i
had to resolve conflicts on the same files, but it was different
conflicts. Not particularly time consuming or annoying.

I did not ignore the other archs when merging, i just did not test
them. 4.0 is currently at a state as if i had applied the big patch on
it and merged to my best knowledge.

> - I believe the right solution is to maintain the changes made by
> the I-pipe tree as a stack of commits applied on top of the upstream
> kernel, maintained with git. That means using git rebase to switch
> from one release to the next, and amend each commit to fix the
> conflicts. This way, every patch becomes a meaningful change to the
> upstream kernel, we keep the history of changes, and they all appear
> on top of the upstream commits, making them easy to identify in the
> git logs. Splitting architecture specific patches allows every
> architecture maintainer to focus on his architecture, and not have
> to care about the other architecture commits. Note that I have
> maintained the FCSE patch (split in something like 7 or 8 commits)
> for several kernel releases, and I noticed no particular difficulty
> doing so.

That also does not sound too bad. At the moment we are probably >30
commits away from mainline, with 95% of the code in one big change that
does have a broken history. But sorting that into a nice queue of
independantly working commits will also take a lot of time. And
maintaining that feature will also cost.

Using a queue has the problem that changing the history (rebasing)
becomes an essential part of your workflow. I know a lot of people like
doing that to keep things nice and clean but i am not a big fan. My
experience is that you end up investing a lot of work to alter
history that could be useful later.

Henning

Re: [Xenomai] 4.x merge

[Gilles Chanteperdrix]

On Fri, Oct 02, 2015 at 03:36:32PM +0200, Henning Schild wrote:
> On Tue, 29 Sep 2015 20:03:45 +0200
> Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org> wrote:
> 
> > On Wed, Sep 09, 2015 at 11:31:51AM +0200, Henning Schild wrote:
> > > Hi,
> > > 
> > > i am about to merge ipipe into a more recent kernel and would like
> > > to discuss the approach with you guys. As far as i have seen and
> > > been told i should merge and not rebase.
> > > 
> > > My current plan:
> > > 1 choose release (4.1 since its LTS)
> > > 2 merge it into ipipe
> > > 3 resolve obvious conflicts
> > > 4 commit broken merge
> > > 5 repair common bits and x86
> > > 6 publish my tree for others to repair other archs
> > > 
> > > Steps 2,3 and 4 might become iterations stepping over 3.19 and 4.0.
> > > The merges will not work but the smaller steps will result in less
> > > conflicts at a time.
> > > 
> > > What do you guys think of the approach? Are my version choices sane
> > > or are there any reasons to consider other releases as well?
> > 
> > I did not answer because I am not sure my opinion really matters. I
> > am only maintaining one architecture, and have not even worked on it
> > for a long time. And have already expressed this opinion several
> > times. But since you are asking for it:
> > 
> > - merging with mainline to maintain the modifications made by the
> > I-pipe tree is a bad solution: 
> > . first because it is more time consuming than what we did before,
> > that is reapplying the I-pipe patch and fixing the conflicts:
> > . second because the I-pipe changes get lost in the middle of the
> > upstream commits, so the idea that by doing this we could keep the
> > history of changes in the I-pipe tree does not work;
> > . third because when you do the merge, you can not easily ignore the
> > conflicts for the other architecture than the one you are currently
> > working on.
> >
> > - merging by iterating over releases is even more time consuming: it
> > is far from exceptional to see the same piece of code changed by
> > several consecutive releases, with your method you get one conflict
> > by iteration, if you skip all the releases with one big iteration,
> > that means fixing only one conflict.
> 
> I found the approach to work OK and surprisingly fast. In some series i
> had to resolve conflicts on the same files, but it was different
> conflicts. Not particularly time consuming or annoying.
> 
> I did not ignore the other archs when merging, i just did not test
> them. 4.0 is currently at a state as if i had applied the big patch on
> it and merged to my best knowledge.

That is a problem. It is easier to find bugs in something you
merged, than in something someone else merged.

> 
> > - I believe the right solution is to maintain the changes made by
> > the I-pipe tree as a stack of commits applied on top of the upstream
> > kernel, maintained with git. That means using git rebase to switch
> > from one release to the next, and amend each commit to fix the
> > conflicts. This way, every patch becomes a meaningful change to the
> > upstream kernel, we keep the history of changes, and they all appear
> > on top of the upstream commits, making them easy to identify in the
> > git logs. Splitting architecture specific patches allows every
> > architecture maintainer to focus on his architecture, and not have
> > to care about the other architecture commits. Note that I have
> > maintained the FCSE patch (split in something like 7 or 8 commits)
> > for several kernel releases, and I noticed no particular difficulty
> > doing so.
> 
> That also does not sound too bad. At the moment we are probably >30
> commits away from mainline, with 95% of the code in one big change that
> does have a broken history. But sorting that into a nice queue of
> independantly working commits will also take a lot of time. And
> maintaining that feature will also cost.
> 
> Using a queue has the problem that changing the history (rebasing)
> becomes an essential part of your workflow. I know a lot of people like
> doing that to keep things nice and clean but i am not a big fan. My
> experience is that you end up investing a lot of work to alter
> history that could be useful later.

I was talking about rebasing only when switching from one mainline
release to the next. An I-pipe branch for a mainline release would
never been rebased. You would use the opportunity of the rebase to
the next release to clean up the history.

-- 
					    Gilles.
https://click-hack.org