[Buildroot] [PATCH v4 1/3] boot/xilinx-embeddedsw: rename toolchain vendor to buildroot

[Luca Ceresoli]

On Tue, 8 Apr 2025 06:40:55 +0000
"Frager, Neal" <neal.frager at 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 at 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