All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH] rtai: remove option BR2_LINUX_KERNEL_EXT_RTAI_PATCH
Date: Wed, 22 Apr 2015 22:13:16 +0200	[thread overview]
Message-ID: <20150422221316.5412b477@free-electrons.com> (raw)
In-Reply-To: <1429652188-11586-1-git-send-email-thomas.petazzoni@free-electrons.com>

Hello,

On Tue, 21 Apr 2015 23:36:28 +0200, Thomas Petazzoni wrote:
> This commit removes BR2_LINUX_KERNEL_EXT_RTAI_PATCH because this
> option never worked. It was added in commit
> 8797a9cd1fe6723db34b0c125d0d9d04e3483e8d, which added package/rtai/
> and RTAI as a Linux extension.
> 
> The option prompt says "Path for RTAI patch file", so let's say you
> specify /home/foo/bar/myrtai.patch as the value for
> BR2_LINUX_KERNEL_EXT_RTAI_PATCH.
> 
> Then the code does:
> 
> RTAI_PATCH = $(call qstrip,$(BR2_LINUX_KERNEL_EXT_RTAI_PATCH))
> 
> and we have a package called 'rtai', so the normal logic of
> <pkg>_PATCH applies. Since the <pkg>_PATCH value does not contain
> ftp://, http:// or https://, the package infrastructure will try to
> download $(RTAI_SITE)/$(RTAI_PATCH), i.e:
> 
>    https://www.rtai.org/userfiles/downloads/RTAI/home/foo/bar/myrtai.patch
> 
> Pretty clear that it has no chance of working.
> 
> Now, let's assume an URL is used as the value of
> BR2_LINUX_KERNEL_EXT_RTAI_PATCH, such as
> http://foo.com/bar/myrtai.patch. In this case, it will be properly
> downloaded by the package infrastructure. But then, the following code
> kicks in:
> 
> define RTAI_PREPARE_KERNEL
>        $(APPLY_PATCHES)                        \
>                $(LINUX_DIR)                    \
>                $(dir $(RTAI_PATCH))            \
>                $(notdir $(RTAI_PATCH))
> endef
> 
> The value of $(dir $(RTAI_PATCH)) will be http://foo.com/bar/. How
> can $(APPLY_PATCHES) make use of such a stupid patch location?
> 
> Bottom line is that this feature has never worked, so there is not
> even a point in adding Config.in.legacy support for it.
> 
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> ---
>  linux/Config.ext.in     |  6 ------
>  linux/linux-ext-rtai.mk | 11 -----------
>  2 files changed, 17 deletions(-)

I've applied, after adding Config.in.legacy handling as suggested by
Arnout.

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

      parent reply	other threads:[~2015-04-22 20:13 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-21 21:36 [Buildroot] [PATCH] rtai: remove option BR2_LINUX_KERNEL_EXT_RTAI_PATCH Thomas Petazzoni
2015-04-21 21:45 ` Arnout Vandecappelle
2015-04-21 21:47   ` Thomas Petazzoni
2015-04-21 21:59     ` Arnout Vandecappelle
2015-04-21 22:02       ` Yann E. MORIN
2015-04-21 22:02 ` Yann E. MORIN
2015-04-22 20:13 ` Thomas Petazzoni [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20150422221316.5412b477@free-electrons.com \
    --to=thomas.petazzoni@free-electrons.com \
    --cc=buildroot@busybox.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.