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

[Frager, Neal]

[AMD Official Use Only - AMD Internal Distribution Only]

Hi Luca,

>
> 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.

Good point.  Yes, I agree.

> 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.

Yes, I could already add a build time warning message with v5 that emits
whenever someone uses the xilinx vendor name.  This is a good idea.

Would it be standard practice to add a deprecation date in this warning
message?

Best regards,
Neal Frager
AMD