All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
To: buildroot@busybox.net
Subject: [Buildroot] [EXT] Re: [PATCH] boot/mv-ddr-marvell: support custom GIT settings
Date: Wed, 26 Dec 2018 14:30:03 +0100	[thread overview]
Message-ID: <20181226143003.551c63b5@windsurf.home> (raw)
In-Reply-To: <20181226112502.GE14286@scaer>

Hello,

On Wed, 26 Dec 2018 12:25:02 +0100, Yann E. MORIN wrote:

> What we recommend in this case, is that said "scripting":
> 
>   - does a git-clone (or whatvere VCS one is using) to a temporary
>     location (and since those CI jobs more often than not, use a
>     docker or docker-like container to run the job, this is by nature
>     ephemeral and temporary), e.g. something not unlike:
>         git clone ${CI_JOB_URL} /path/to/temp/git/clone/${CI_JOB_NAME}
> 
>   - create a local.mk file in the Buildroot build directory, that
>     contains the definition for a package override-srcdir, like:
>         ${CI_JOB_NAME_UPPER}_OVERRIDE_SRCDIR = /path/to/temp/git/clone/${CI_JOB_NAME}

Not ${CI_JOB_NAME_UPPER}_OVERRIDE_SRCDIR, but <pkg>_OVERRIDE_SRCDIR.

> As you also said eralier, you plan on using Buildroot as your "SDK" (not
> sure I grok all you said).

Marvell doesn't use the term "SDK" in the same sense as we do in the
upstream Buildroot:

 - In upstream Buildroot, what we call the "SDK" is what is generated
   by "make sdk", i.e the cross-compilation toolchain + all the
   libraries and headers that are needed to build code for the target,
   matching a given Buildroot configuration.

 - In Marvell-speak, the "SDK" is basically an entire build system +
   set of source code tarballs that will allow you to build a Linux
   system for your target. Basically, Marvell SDK is a customized
   Buildroot + external trees + source code tarballs.


> This is a kind of justification that would make us accept a version
> choice, though. If there are reasons that people have to have a local
> modified tree because they are porting it to their own devices, then it
> makes sense we allow them to use a custom git tree, as Thomas said.
> 
> So, before reposting a new version:
> 
>   - I'd like Thomas to confirm we want to use a choice, like for the
>     others where we allow using a custom VCS tree,

I'm still unsure whether people making custom Marvell boards generally
need to change mv-ddr-marvell code. However, it is true that the
mv-ddr-marvell code version needs to be in sync with the ATF version in
use (last time I updated the Macchiatobin defconfigs in upstream
Buildroot, I had to update both ATF and mv-ddr-marvell at the same
time). It is also highly HW-related low-level code, so I think it is OK
to have a version selection.

>   - update your commit log to use the per-device customisation
>     requirement as a justification for this change, not the CI
>     testing. ;-)
> 
> Thomas, is that OK with you, in the end?

Yes, provided the code is changed to use a version selection more
similar to what we use in other packages *and* the commit log is
adjusted, I'm fine with merging something like this.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

      parent reply	other threads:[~2018-12-26 13:30 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-24 13:18 [Buildroot] [PATCH] boot/mv-ddr-marvell: support custom GIT settings kostap at marvell.com
2018-12-24 18:57 ` Yann E. MORIN
2018-12-25  9:09   ` [Buildroot] [EXT] " Kostya Porotchkin
2018-12-26 10:31     ` Thomas Petazzoni
2018-12-26 10:59       ` Kostya Porotchkin
2018-12-26 11:25         ` Yann E. MORIN
2018-12-26 12:33           ` Kostya Porotchkin
2018-12-26 13:24             ` Thomas Petazzoni
2018-12-26 13:30           ` 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=20181226143003.551c63b5@windsurf.home \
    --to=thomas.petazzoni@bootlin.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.