12:50 <sjg1> marex: There is a MaintainersDatabase in buildman, but at present it just looks for defconfig files. It could be expanded, I suppose. What are you wanting?

14:46 <Tartarus> marex: just using get_maintainers.pl, for better or worse

14:47 <Tartarus> sjg1: See, that's why I think you're totally off-base about LMB. The need for a unified reservation system is required when EFI_LOADER=n

14:48 <marex> Tartarus: I added debug prints into it in the end

14:48 <Tartarus> There is I think still discussion between sng, apalos and xypron as to if the event part makes more sense than something else, yes, but I think they all might have agreed, give the variety of use cases that in the end, no, really, event is less work and code than making the half dozen possible places that need to care, care.

14:48 <Tartarus> marex: ok

14:48 <marex> Tartarus: luckily it was not WO perl, just barely

14:49 <marex> btw

14:49 <marex> $ ./scripts/get_maintainer.pl --self-test

14:49 <marex> ./scripts/get_maintainer.pl: using --self-test does not allow any other option or argument

14:49 <marex> sigh

14:49 <Tartarus> reading our .get_maintainer.conf file i bet

14:52 <marex> Tartarus: oh, quite likely

16:03 <sjg1> Tartarus: Here's how I see it. When bootstd has decided to boot a bootflow, it sets up an lmb, loads the images and then does the boot. So definitely lmb needs to be persistent across that process. If the boot fails, we want to drop the lmb and perhaps try another bootflow

16:04 <sjg1> Tartarus: The way things are now, lmb is persistent, but that's OK because I can add something to un-reserve all the images that were loaded. Some of them might be hidden in bootm methods, but I plan to keep a track of them, so that will be fine

16:04 <Tartarus> sjg1: That's totally wrong

16:04 <Tartarus> You must not drop the lmb

16:05 <Tartarus> It's not about images

16:05 <Tartarus> it's about protecting memory contents

16:05 <sjg1> I want to see EFI_LOADER following the normal memory-management rules of U-Boot, and fix that before we go any further. It is a very simple thing to fix

16:07 <sjg1> I already dropped my objection to having a global lmb, so we don't really need to talk about that. I'm just trying to lay out my understanding of how bootstd will use a global, persistent lmb

16:07 <sjg1> What is in the memory that needs protecting?

16:07 <Tartarus> U-Boot, to start with

16:07 <Tartarus> And bootstd should load images with the flag that says the area can be re-used, like happens today when you tftp/wget/whatever a file

16:09 <sjg1> Right, so U-Boot's region is protected using lmb. When I said 'drop the lmb', perhaps I should have said 'recreate it'. Of course when set up an lmb we add an exclusion for U-Boot's region

16:10 <sjg1> As I said, I dropped my objection to the global, persistent lmb. But bootstd is not necessarily going to reuse the same address. That seems like a hack to me. Once we get rid of the kernel_addr_r stuff (which I admit might be a while) bootstd will actually call lmb_alloc() to find a place to use. It won't specify an address itself

16:11 <sjg1> So a failed boot must free the things that were alloced

16:12 <sjg1> These are the kind of discussions that we need to have, because I feel there has not been a clear design of where it is all heading. I have a lot of it in my head though, because I have been thinking about it alot as part of the bootstd design-process

16:24 <Tartarus> sjg1: I wanna change topics, did you see my email about that patch in vbe part E?

16:25 <sjg1> Tartarus: Er, sorry I haven't had much time this week...hang on

16:25 <Tartarus> No big rush, I need to go do some cleaning now

16:28 <sjg1> Can you give me a link? I found an old email but nothing recent

16:34 <Tartarus> https://patchwork.ozlabs.org/project/uboot/patch/20240920081309.140426-4-sjg@chromium.org/

16:36 <sjg1> OK, got it. I did see it but haven't had time to get back to it. I should get some time tomorrow. I need to go through my pending series as well, to see what needs respinning next, etc. I also saw your mmc comment so will do a patch for that, assuming that it is what I think it is

16:42 <marex> now running final R-Car tests before release ... everything works ... that's just awesome

17:32 <Crofton> Racing Car?

17:36 <Forty-Bot> renesas car

17:43 <marex> I knew if I write something like that, I will successfully jinx it and find some last minute issue

17:43 <marex> oh well