Messages in this thread | | | Date | Tue, 19 Apr 2022 18:30:02 +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 > > 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
| |