Re: [PATCHv4 3/8] efi/x86: Implement support for unaccepted memory

Kirill A. Shutemov
2022-04-19T15:28:27Z

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
>
> I *have* been working towards that but it's a losing whack-a-mole game
> when you and others keep adding new stuff.
>
> So no, we won't take a pile of changes and let the maintainer clean it
> up afterwards.
>
> > What do you want me to do here?
>
> I think the stuff coming from the linux/ namespace you can simply copy
> into a header in compressed/, like I've done with efi.h.

Hm. Dave was worried about having copies of _find_next_bit() and
__bitmap_*() inside compressed/.

How do we rectify code duplication and making decompresser self-contained?
Do we care about multiple copies of the same code in the kernel?
Do we care about keeping them in sync?

> > // <asm/bitops.h>
>
> The asm/ stuff can be put into a shared/ namespace header like the io
> stuff you did.
>
> > As 1 bit represents 2M, not all chunks can be represented in the bitmap
> > and they have to be accepted. But the *goal* is to record unaccepted
> > memory into bitmap. Some accepting is a side effect.
> >
> > The early_accept_memory() name is just wrong.
>
> Ok, how about process_unaccepted_memory(). It should be generic enough.

Sounds good.

--
Kirill A. Shutemov