On Tue, Jan 7, 2020 at 6:19 PM John Garry <john.garry@xxxxxxxxxx> wrote:
On 06/01/2020 18:04, Masahiro Yamada wrote:
On Mon, Jan 6, 2020 at 6:18 PM John Garry <john.garry@xxxxxxxxxx> wrote:
On 10/12/2019 12:09, John Garry wrote:
Hi Masahiro,
Could you please consider this patch?
Thanks,
John
Recently there has been some work in reporting and fixing bugs in booting
an allmodconfig kernel - here are a few examples:
https://lore.kernel.org/linux-edac/304df85b-8b56-b77e-1a11-aa23769f2e7c@xxxxxxxxxx/T/#t
https://lore.kernel.org/linux-ide/bdf02e03-86a1-3d35-2908-28187f504495@xxxxxxxxxx/T/#t
https://lore.kernel.org/netdev/CADYN=9LCPfbpwdTWKw03B22-y3Text=RWXW7XP7wJBHYsMOgrA@xxxxxxxxxxxxxx/
https://sourceforge.net/p/openipmi/mailman/message/36871567/
If we want to boot an allmodconfig kernel we may still want to force some
loadable modules built-in, like UART drivers. Or just still turn off some
configs.
I do not understand why you need to use merge_config.sh
for this purpose.
KCONFIG_ALLCONFIG=<path-to-your-config-fragment> make allmodconfig
should work.
Right, I could use that. But generally some people like to use
merge_config.sh directly:
./scripts/kconfig/merge_config.sh [-a] fragment
so nice to have -a option for completeness.
Honestly, I am getting scared
about people extending this script more and more
to do what they want.
Since allmodconfig works enough for this usecase,
I do not see a good reason to add the new option.