> I don't like superlatives. I don't think it needs to be "completely
> separate". For instance, when somebody discusses coreboot for a new
> platform behind closed doors[1]. And they implement something on the
> same code base. If they did that according to spec, it would be more
> likely to get
Hey Mike,
I think you should be able to just append change the kconfig values when you
run make to override the current settings.
something like
`make menuconfig KCONFIG_WERROR=0 KCONFIG_WARN_UNKNOWN_SYMBOLS=0`
if we update where they're set in the makefile from := to ?=, you could even
just
On 28.11.23 19:04, Mike Banon wrote:
Are there any advantages of KCONFIG_STRICT / KCONFIG_WERROR that
outweigh these potential issues?
It ensures that we don't silently build with unknown symbols (typo in manual
editing, changes to the config, ...), and wonder why CONFIG_UART_DEBUG=y
doesn't
In my case, a csb_patcher.sh script [1] - among other things -
delivers the example config files for the opensource AGESA boards.
Although these configs haven't been updated for a while (i.e. a last
update of AMD Lenovo G505S config [2] is 1 year ago), I got away with
this: they are still working,
Hi Julius,
On 28.11.23 03:31, Julius Werner wrote:
> Sounds to me like what you're asking for is really documentation, not
> a spec?
well, yes and no. It would be documenting what we did all along.
But also serve as a blueprint for coreboot.
I'm not all set on the term. I think it fits, even if
Hi everybody,
I updated Kconfig to track latest Linux last week and that brought some
behavioral change with it. While these changes are appreciated in some respect,
they also complicate work in others.
I now proposed https://review.coreboot.org/79298, a change that exempts _all_
*config
6 matches
Mail list logo
