On 24/11/2023 13.15, Borislav Petkov wrote: > On Fri, Nov 24, 2023 at 09:49:27AM +0100, Antonio Feijoo wrote: >> As Linus said, the `check_kernel_config` stuff was implemented in 2014 and this >> is not the only kernel config option that it's being checked by dracut >> (CONFIG_ACPI_TABLE_UPGRADE, CONFIG_ACPI_INITRD_TABLE_OVERRIDE, CONFIG_RD_ZSTD), >> although I agree that it's fragile if something changes. But adding in CC the >> initramfs list (like you did), would be enough to prepare a simple fix in time. > > Right, how about we give you a more reliable way to check functionality > built into the kernel instead of grepping the .config file? > > Like the ELF note thing, for example: > > https://lore.kernel.org/r/20231122132419.GBZV4BA399sG2JRFAJ@fat_crate.local > > The current thing is not ABI and will break everytime we change > something and even if you fix it on time, older dracuts will still be > broken. The problem I see is having to add a new patch with a new note every time a user space application requires new information to query. And also new dracuts will be broken with older kernels that do not contain this info. But (from a user space application point of view) if you (the kernel devs) are ok with this approach, I don't see why we can at least get some info from there. > >> The only problem I see in your patch is that we should also remove the >> `--early-microcode` option, and dracut will fail if someone pass an option >> available since 2013 (5f2c30d9bcd614d546d5c55c6897e33f88b9ab90) that would not >> be recognized now (and by failing, I mean it will not build an initramfs if an >> unrecognized option is passed). > > Ah ok, --early-microcode becomes a no-op with my change. Sure. > >> Please, submit it to https://github.com/dracutdevs/dracut, so more people can >> see it and discuss it. Thank you. > > I presume I should read this first: > > https://github.com/dracutdevs/dracut/blob/master/docs/HACKING.md > > and send a github pull request? Yes, that would be enough. > Anything else I need to pay attention to when sending dracut patches? Just follow the Conventional Commit style for the commit messages, but that's also specified in the HACKING.md doc. > Or is there also an old school mailing list where I can send the patch > to? > > :-) Unfortunately no. All the development process was moved to github. > > Thx. > Thank you, Best regards. -- Antonio Álvarez Feijoo System Boot and Init SUSE
