On Fri Oct 30, 2026 at 3:18 PM JST, David Airlie wrote: >> This is related to the comment made by Sashiko, but in which cases are >> we expecting `total_fb_end` to be `None` here? Is this the same set of >> systems for which `buddy_params` will be `None`? If so both arguments >> should be merged into a new type to remove the ability to represent >> invalid state where one is `Some` and the other is `None`. > > Indeed I've been working on a patchset to better define the concept > for total_fb_end, so this patchset can work on top in a proper manner. > > The question of whether total_fb_end == Some(0) or total_fb_end == > None is a sufficient indicator for no framebuffer, and I suppose we > have to make a choice before we can land this patch, anyone got an opinion?
I don't have a definitive answer to that, only a similar question [1] for a hypothetical FB HAL method that might also cover this? [1] https://lore.kernel.org/all/[email protected]/ <...> >> > @@ -120,7 +120,7 @@ fn ensure_single_pte_path( >> > for _ in 0..max_iter { >> > let result = self >> > .walker >> > - .walk_pde_levels(mm.pramin_mut(), vfn, |install_addr| { >> > + .walk_pde_levels(mm.pramin_mut()?, vfn, |install_addr| { >> > pt_pages.get(&install_addr).and_then(|p| { >> > p.alloc >> > .iter() >> > @@ -197,7 +197,7 @@ pub(super) fn install_mappings( >> > writable: bool, >> > ) -> Result { >> > { >> > - let pramin = mm.pramin_mut(); >> > + let pramin = mm.pramin_mut()?; >> > >> > // Drain prepared PT pages, install all pending PDEs. >> > let mut cursor = pt_pages.cursor_front_mut(); >> > @@ -255,7 +255,7 @@ pub(super) fn invalidate_ptes( >> > let invalid_pte = M::Pte::invalid(); >> > >> > { >> > - let pramin = mm.pramin_mut(); >> > + let pramin = mm.pramin_mut()?; >> >> I'll let Eliot comment on this in more depth as I am not very familiar >> with this module, but I'd like to avoid these runtime checks if >> possible. On systems without a framebuffer, we should not even be able >> to call these methods, so I'd like to enforce it at that level. >> >> Ideally, we would consolidate all the state requiring a framebuffer into >> a new type (i.e. my first comment, but pushed further), and put it >> behind a single `Option` that solely tells us whether the system has a >> framebuffer or not. Then methods requiring a framebuffer can be passed a >> reference to that type and work without runtime checking its presence. > > I think we have to get to handling instmem maps in bar2 properly > before we can completely encapsulate everything. > > Ideally instmem would have one API for allocation and it would be > backed on systems with VRAM with vram allocations, and with dma > allocations on 0-fb systems. > > Then we would have to store the instmem backing in some sort of > encapsulation that hides the pramin/vram buddy/bar2 handling and > device handle for dma alloc handling > > Does that make sense? Yes, and especially after Eliot's comment my suggestion seems to be moot anyway. As long as we have an idea of where we want to take this to minimize unneeded runtime checks, I think these kind of temporary workarounds are ok while the correct design comes together.
