| Message ID | 1536782312-12240-1-git-send-email-michael@amarulasolutions.com |
|---|---|
| State | Rejected |
| Headers | show |
| Series | [RFC] linux: let to work with xenomai in override mode | expand |
Hello, On Wed, 12 Sep 2018 21:58:32 +0200, Michael Trimarchi wrote: > We would like to patch xenomai in override mode. Xenomai create > symlink in order to build the kernel and those links are absolute > one. The adeos patch is not applied if it is found so we > can change the connect hook from PRE_PATCH to PRE_CONFIGURE. > The xenomi dependence should be explicit set > > Change-Id: Idc5189047451bb9ac3019d3f35674d5332159918 > Signed-off-by: Michael Trimarchi <michael@amarulasolutions.com> As I explained in our previous e-mail discussion, when you use <pkg>_OVERRIDE_SRCDIR, you should handle any needed patching yourself. Doing what you suggest here means that all patches from Linux kernel extensions will be applied in the configure step, which is: (1) Contrary to common sense: why should patching happen outside of the patching step ? (2) Completely inconsistent with what happens in all other packages that use <pkg>_OVERRIDE_SRCDIR. (3) Inconsistent with the initial principle of <pkg>_OVERRIDE_SRCDIR, which is that the user *controls* the source code, and Buildroot will not touch it all. Best regards, Thomas
Hi Thomas On Wed, Sep 12, 2018 at 10:08 PM Thomas Petazzoni <thomas.petazzoni@bootlin.com> wrote: > > Hello, > > On Wed, 12 Sep 2018 21:58:32 +0200, Michael Trimarchi wrote: > > We would like to patch xenomai in override mode. Xenomai create > > symlink in order to build the kernel and those links are absolute > > one. The adeos patch is not applied if it is found so we > > can change the connect hook from PRE_PATCH to PRE_CONFIGURE. > > The xenomi dependence should be explicit set > > > > Change-Id: Idc5189047451bb9ac3019d3f35674d5332159918 > > Signed-off-by: Michael Trimarchi <michael@amarulasolutions.com> > > As I explained in our previous e-mail discussion, when you use > <pkg>_OVERRIDE_SRCDIR, you should handle any needed patching yourself. > > Doing what you suggest here means that all patches from Linux kernel > extensions will be applied in the configure step, which is: > > (1) Contrary to common sense: why should patching happen outside of > the patching step ? > Xenomai create symlinks, and it's not only a patch by provide links to the package. Adeos patch xenomai but another part is connect to those symlinks. Now you can not let to have a complete developement project without move this is a patching step. Xenomai check if the patch applied correspond to the one that you are going to apply and if they are the same the symlink are created. Now suppose to have a manifest and repo describe your buildroot project and your override and you want to have the kernel already patched but with symlink not created. I don't going to git commit symlink but I want them created automatic. Is now more clear? Michael > (2) Completely inconsistent with what happens in all other packages > that use <pkg>_OVERRIDE_SRCDIR. > > (3) Inconsistent with the initial principle of <pkg>_OVERRIDE_SRCDIR, > which is that the user *controls* the source code, and Buildroot > will not touch it all. > > Best regards, > > Thomas > -- > Thomas Petazzoni, CTO, Bootlin > Embedded Linux and Kernel engineering > https://bootlin.com
Hi Michael, On 12/09/2018 21:15, Michael Nazzareno Trimarchi wrote: > Hi Thomas > > On Wed, Sep 12, 2018 at 10:08 PM Thomas Petazzoni > <thomas.petazzoni@bootlin.com> wrote: >> >> Hello, >> >> On Wed, 12 Sep 2018 21:58:32 +0200, Michael Trimarchi wrote: >>> We would like to patch xenomai in override mode. Xenomai create >>> symlink in order to build the kernel and those links are absolute >>> one. The adeos patch is not applied if it is found so we >>> can change the connect hook from PRE_PATCH to PRE_CONFIGURE. >>> The xenomi dependence should be explicit set >>> >>> Change-Id: Idc5189047451bb9ac3019d3f35674d5332159918 >>> Signed-off-by: Michael Trimarchi <michael@amarulasolutions.com> >> >> As I explained in our previous e-mail discussion, when you use >> <pkg>_OVERRIDE_SRCDIR, you should handle any needed patching yourself. >> >> Doing what you suggest here means that all patches from Linux kernel >> extensions will be applied in the configure step, which is: >> >> (1) Contrary to common sense: why should patching happen outside of >> the patching step ? >> > > Xenomai create symlinks, and it's not only a patch by provide links to > the package. Adeos > patch xenomai but another part is connect to those symlinks. Now you > can not let to have > a complete developement project without move this is a patching step. > Xenomai check if the > patch applied correspond to the one that you are going to apply and if > they are the same > the symlink are created. > > Now suppose to have a manifest and repo describe your buildroot > project and your override > and you want to have the kernel already patched but with symlink not > created. I don't going to > git commit symlink but I want them created automatic. > > Is now more clear? Your intention is fairly clear, but we still disagree :-) The problem is that when you have an OVERRIDE_SRCDIR (or local site method), it is impossible for Buildroot to know what you intend to do with each patching step. One person may already have the adeos stuff applied in their repo, another one may not. To be consistent, we have chosen to never do any patching when OVERRIDE_SRCDIR is used. Whatever the patching step is doing, you can always do that manually, either in a script that is called before running Buildroot, or just committing the patched/modified/symlinked tree into your repo. In case of the Adeos patch, it is not even a problem to do it this way, because Xenomai is fairly independent of the Adeos patch (i.e. you can have a different version of the Adeos patch and Xenomai usually still works). Therefore, we've marked your patch as Rejected in patchwork. Regards, Arnout
Hi On Sun., 21 Oct. 2018, 6:26 pm Arnout Vandecappelle, <arnout@mind.be> wrote: > Hi Michael, > > On 12/09/2018 21:15, Michael Nazzareno Trimarchi wrote: > > Hi Thomas > > > > On Wed, Sep 12, 2018 at 10:08 PM Thomas Petazzoni > > <thomas.petazzoni@bootlin.com> wrote: > >> > >> Hello, > >> > >> On Wed, 12 Sep 2018 21:58:32 +0200, Michael Trimarchi wrote: > >>> We would like to patch xenomai in override mode. Xenomai create > >>> symlink in order to build the kernel and those links are absolute > >>> one. The adeos patch is not applied if it is found so we > >>> can change the connect hook from PRE_PATCH to PRE_CONFIGURE. > >>> The xenomi dependence should be explicit set > >>> > >>> Change-Id: Idc5189047451bb9ac3019d3f35674d5332159918 > >>> Signed-off-by: Michael Trimarchi <michael@amarulasolutions.com> > >> > >> As I explained in our previous e-mail discussion, when you use > >> <pkg>_OVERRIDE_SRCDIR, you should handle any needed patching yourself. > >> > >> Doing what you suggest here means that all patches from Linux kernel > >> extensions will be applied in the configure step, which is: > >> > >> (1) Contrary to common sense: why should patching happen outside of > >> the patching step ? > >> > > > > Xenomai create symlinks, and it's not only a patch by provide links to > > the package. Adeos > > patch xenomai but another part is connect to those symlinks. Now you > > can not let to have > > a complete developement project without move this is a patching step. > > Xenomai check if the > > patch applied correspond to the one that you are going to apply and if > > they are the same > > the symlink are created. > > > > Now suppose to have a manifest and repo describe your buildroot > > project and your override > > and you want to have the kernel already patched but with symlink not > > created. I don't going to > > git commit symlink but I want them created automatic. > > > > Is now more clear? > > Your intention is fairly clear, but we still disagree :-) > No problem. Right now I'm using buildroot as an element on more complex bsp build where is a part of continue integration process connected to repo and multi project. Even the patch was having a minor problem. I will keep only on my private tree Thanks for kind answer Michael > > The problem is that when you have an OVERRIDE_SRCDIR (or local site > method), it > is impossible for Buildroot to know what you intend to do with each > patching > step. One person may already have the adeos stuff applied in their repo, > another > one may not. > > To be consistent, we have chosen to never do any patching when > OVERRIDE_SRCDIR > is used. Whatever the patching step is doing, you can always do that > manually, > either in a script that is called before running Buildroot, or just > committing > the patched/modified/symlinked tree into your repo. > > In case of the Adeos patch, it is not even a problem to do it this way, > because > Xenomai is fairly independent of the Adeos patch (i.e. you can have a > different > version of the Adeos patch and Xenomai usually still works). > > Therefore, we've marked your patch as Rejected in patchwork. > > Regards, > Arnout > <div dir="auto"><div>Hi<div dir="auto"><br></div><br><br><div class="gmail_quote"><div dir="ltr">On Sun., 21 Oct. 2018, 6:26 pm Arnout Vandecappelle, <<a href="mailto:arnout@mind.be">arnout@mind.be</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Hi Michael,<br> <br> On 12/09/2018 21:15, Michael Nazzareno Trimarchi wrote:<br> > Hi Thomas<br> > <br> > On Wed, Sep 12, 2018 at 10:08 PM Thomas Petazzoni<br> > <<a href="mailto:thomas.petazzoni@bootlin.com" target="_blank" rel="noreferrer">thomas.petazzoni@bootlin.com</a>> wrote:<br> >><br> >> Hello,<br> >><br> >> On Wed, 12 Sep 2018 21:58:32 +0200, Michael Trimarchi wrote:<br> >>> We would like to patch xenomai in override mode. Xenomai create<br> >>> symlink in order to build the kernel and those links are absolute<br> >>> one. The adeos patch is not applied if it is found so we<br> >>> can change the connect hook from PRE_PATCH to PRE_CONFIGURE.<br> >>> The xenomi dependence should be explicit set<br> >>><br> >>> Change-Id: Idc5189047451bb9ac3019d3f35674d5332159918<br> >>> Signed-off-by: Michael Trimarchi <<a href="mailto:michael@amarulasolutions.com" target="_blank" rel="noreferrer">michael@amarulasolutions.com</a>><br> >><br> >> As I explained in our previous e-mail discussion, when you use<br> >> <pkg>_OVERRIDE_SRCDIR, you should handle any needed patching yourself.<br> >><br> >> Doing what you suggest here means that all patches from Linux kernel<br> >> extensions will be applied in the configure step, which is:<br> >><br> >> (1) Contrary to common sense: why should patching happen outside of<br> >> the patching step ?<br> >><br> > <br> > Xenomai create symlinks, and it's not only a patch by provide links to<br> > the package. Adeos<br> > patch xenomai but another part is connect to those symlinks. Now you<br> > can not let to have<br> > a complete developement project without move this is a patching step.<br> > Xenomai check if the<br> > patch applied correspond to the one that you are going to apply and if<br> > they are the same<br> > the symlink are created.<br> > <br> > Now suppose to have a manifest and repo describe your buildroot<br> > project and your override<br> > and you want to have the kernel already patched but with symlink not<br> > created. I don't going to<br> > git commit symlink but I want them created automatic.<br> > <br> > Is now more clear?<br> <br> Your intention is fairly clear, but we still disagree :-)<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">No problem. Right now I'm using buildroot as an element on more complex bsp build where is a part of continue integration process connected to repo and multi project. Even the patch was having a minor problem. I will keep only on my private tree</div><div dir="auto"><br></div><div dir="auto">Thanks for kind answer</div><div dir="auto"><br></div><div dir="auto">Michael</div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <br> The problem is that when you have an OVERRIDE_SRCDIR (or local site method), it<br> is impossible for Buildroot to know what you intend to do with each patching<br> step. One person may already have the adeos stuff applied in their repo, another<br> one may not.<br> <br> To be consistent, we have chosen to never do any patching when OVERRIDE_SRCDIR<br> is used. Whatever the patching step is doing, you can always do that manually,<br> either in a script that is called before running Buildroot, or just committing<br> the patched/modified/symlinked tree into your repo.<br> <br> In case of the Adeos patch, it is not even a problem to do it this way, because<br> Xenomai is fairly independent of the Adeos patch (i.e. you can have a different<br> version of the Adeos patch and Xenomai usually still works).<br> <br> Therefore, we've marked your patch as Rejected in patchwork.<br> <br> Regards,<br> Arnout<br> </blockquote></div></div></div>
diff --git a/linux/linux.mk b/linux/linux.mk index 675e790..2303923 100644 --- a/linux/linux.mk +++ b/linux/linux.mk @@ -351,6 +351,10 @@ define LINUX_KCONFIG_FIXUP_CMDS $(call KCONFIG_DISABLE_OPT,CONFIG_MXC_GPU_VIV,$(@D)/.config)) endef +ifneq ($(BR2_LINUX_KERNEL_EXT_XENOMAI_ADEOS_PATCH),) +LINUX_DEPENDENCIES += xenomai +endif + ifeq ($(BR2_LINUX_KERNEL_DTS_SUPPORT),y) # Starting with 4.17, the generated dtc parser code is no longer # shipped with the kernel sources, so we need flex and bison. For @@ -485,7 +489,7 @@ include $(sort $(wildcard linux/linux-ext-*.mk)) LINUX_PATCH_DEPENDENCIES += $(foreach ext,$(LINUX_EXTENSIONS),\ $(if $(BR2_LINUX_KERNEL_EXT_$(call UPPERCASE,$(ext))),$(ext))) -LINUX_PRE_PATCH_HOOKS += $(foreach ext,$(LINUX_EXTENSIONS),\ +LINUX_PRE_CONFIGURE_HOOKS += $(foreach ext,$(LINUX_EXTENSIONS),\ $(if $(BR2_LINUX_KERNEL_EXT_$(call UPPERCASE,$(ext))),\ $(call UPPERCASE,$(ext))_PREPARE_KERNEL))
We would like to patch xenomai in override mode. Xenomai create symlink in order to build the kernel and those links are absolute one. The adeos patch is not applied if it is found so we can change the connect hook from PRE_PATCH to PRE_CONFIGURE. The xenomi dependence should be explicit set Change-Id: Idc5189047451bb9ac3019d3f35674d5332159918 Signed-off-by: Michael Trimarchi <michael@amarulasolutions.com> --- linux/linux.mk | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-)