From: Luca Ceresoli via buildroot <buildroot@buildroot.org>
To: "Frager, Neal" <neal.frager@amd.com>
Cc: "Erkiaga Elorza, Ibai" <ibai.erkiaga-elorza@amd.com>,
"arnout@mind.be" <arnout@mind.be>,
"brandon.maier@collins.com" <brandon.maier@collins.com>,
"ju.o@free.fr" <ju.o@free.fr>,
"thomas.petazzoni@bootlin.com" <thomas.petazzoni@bootlin.com>,
"buildroot@buildroot.org" <buildroot@buildroot.org>,
"romain.naour@smile.fr" <romain.naour@smile.fr>,
"Simek, Michal" <michal.simek@amd.com>
Subject: Re: [Buildroot] [PATCH v4 1/3] boot/xilinx-embeddedsw: rename toolchain vendor to buildroot
Date: Tue, 8 Apr 2025 12:09:10 +0200 [thread overview]
Message-ID: <20250408120910.5dc50b98@booty> (raw)
In-Reply-To: <SA1PR12MB56151490BEC4B0D5D05E8991F0B52@SA1PR12MB5615.namprd12.prod.outlook.com>
On Tue, 8 Apr 2025 06:40:55 +0000
"Frager, Neal" <neal.frager@amd.com> wrote:
> [AMD Official Use Only - AMD Internal Distribution Only]
>
> Hi Luca,
>
> > This patch renames the bare-metal toolchain vendor used by the
> > xilinx-embeddedsw package from Xilinx to Buildroot to be consistent with all
> > other toolchains built by Buildroot.
> >
> > To build the Microblaze applications available with the xilinx-embeddedsw
> > package, the following config is now needed:
> >
> > BR2_TOOLCHAIN_BARE_METAL_BUILDROOT_ARCH="microblazeel-buildroot-elf"
> >
> > This change keeps backwards compatibility for users already using the
> > following architecture tuple:
> >
> > BR2_TOOLCHAIN_BARE_METAL_BUILDROOT_ARCH="microblazeel-xilinx-elf"
> >
> > Either vendor name is now valid, but the documentation will describe using
> > the Buildroot vendor name.
> >
> > Signed-off-by: Neal Frager <neal.frager@amd.com>
>
> > I don't have a strong opinion about this series. Definitely the
> > "buildroot" vendor name is more appropriate than "xilinx", and the
> > patches look clean enough, but I'll let the maintainers decide whether
> > it's worth the extra effort.
>
> > If this is accepted, however, I think we should remove the "xilinx"
> > vendor support after 1y~1.5y and not carry the maintenance burden
> > indefinitely. Do you think this can be handled by Config.in.legacy, so
> > in the transition phase users of the old tuple are notified?
>
> Yes, I agree with this. Probably the sooner we transition over the better,
> in order to limit the number of users of the xilinx vendor name.
I don't think the number of users is very relevant, and we cannot
control or even know that anyway. If a kconfig value was valid in a
Buildroot release, then we need to handle the transition before it is
made invalid.
Config.in.legacy is the primary tool for this, but I'm not sure it will
work for this specific change which is not removing a kconfig symbol
but rather one of the possible entries within its value.
Maybe you could emit a warning in case the old vendor string is used,
suggesting to switch to the new vendor string, and after 1y+ make it an
error.
Luca
--
Luca Ceresoli, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot
next prev parent reply other threads:[~2025-04-08 10:09 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-27 11:16 [Buildroot] [PATCH v4 1/3] boot/xilinx-embeddedsw: rename toolchain vendor to buildroot Neal Frager via buildroot
2025-03-27 11:16 ` [Buildroot] [PATCH v4 2/3] toolchain/toolchain-bare-metal-buildroot: rename example " Neal Frager via buildroot
2025-03-27 11:16 ` [Buildroot] [PATCH v4 3/3] configs/versal|zynqmp: migrate to microblazeel-buildroot-elf tuple Neal Frager via buildroot
2025-04-08 6:35 ` [Buildroot] [PATCH v4 1/3] boot/xilinx-embeddedsw: rename toolchain vendor to buildroot Luca Ceresoli via buildroot
2025-04-08 6:40 ` Frager, Neal via buildroot
2025-04-08 10:09 ` Luca Ceresoli via buildroot [this message]
2025-04-08 12:19 ` Frager, Neal via buildroot
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=20250408120910.5dc50b98@booty \
--to=buildroot@buildroot.org \
--cc=arnout@mind.be \
--cc=brandon.maier@collins.com \
--cc=ibai.erkiaga-elorza@amd.com \
--cc=ju.o@free.fr \
--cc=luca.ceresoli@bootlin.com \
--cc=michal.simek@amd.com \
--cc=neal.frager@amd.com \
--cc=romain.naour@smile.fr \
--cc=thomas.petazzoni@bootlin.com \
/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.