Messages in this thread | | | Date | Fri, 22 Apr 2022 03:21:24 +0300 | From | "Kirill A. Shutemov" <> | Subject | Re: [PATCHv4 3/8] efi/x86: Implement support for unaccepted memory |
| |
On Tue, Apr 19, 2022 at 09:39:53AM +0200, Borislav Petkov wrote: > On Tue, Apr 19, 2022 at 02:50:15AM +0300, Kirill A. Shutemov wrote: > > I find it strange that you go after <linux/bitmap.h> which has limited > > exposure while <linux/acpi.h> and <linux/efi.h> are there already. > > Funny you should mention that: > > https://lore.kernel.org/r/YlCKWhMJEMUgJmjF@zn.tnic
There's still #include <linux/efi.h> in misc.h. You removed one, but there's a second one for some reason.
Any plans for <linux/acpi.h>? It includes <linux/bitmap.h>:
In file included from ./include/linux/cpumask.h:12, from ./include/linux/smp.h:13, from ./include/linux/lockdep.h:14, from ./include/linux/mutex.h:17, from ./include/linux/kernfs.h:11, from ./include/linux/sysfs.h:16, from ./include/linux/kobject.h:20, from ./include/linux/of.h:17, from ./include/linux/irqdomain.h:35, from ./include/linux/acpi.h:13, from arch/x86/boot/compressed/misc.h:3
We will get name conflicts if we try to copy <linux/bitmap.h> stuff. Hm.
I also underesitmated what is required to be copied because of the indirect include. The list was only to compile bitmap.c. mem.c (former unaccepted_memory.c) would require more.
BTW, do we have a white list of linux/ includes that allowed? minmax.h? math.h? What is the line.
Maybe allow what is included directly or indirectly now? (Yes, it is my poor attempt to slide under closing door.)
-- Kirill A. Shutemov
| |