On Tue, Dec 3, 2024 at 11:04 AM Andrew Davis <afd@xxxxxx> wrote: > On 12/3/24 1:44 AM, Maxime Ripard wrote: > > On Mon, Dec 02, 2024 at 11:12:23AM -0800, John Stultz wrote: > >> Hrm. I'm not sure I see the value in enumerating things in this way, > >> it seems like it will be a nuisance to keep current? Maybe something > >> like: > >> > >> On most systems the default cma region is named "linux, cma" or > >> "reserved", with a few exceptions: > >> - Allwinner sun4i, sun5i and sun7i families: ``default-pool`` > > > > I'm a bit worried about doing so. What if, on a "linux,cma" system, we > > have another "reserved" heap created with different semantics? > > > > Having the "default CMA" heap get its dev name based on the method that > created it was arguably a mistake made when first upstreaming this heap. > We should fix this, then maybe add the old name as a link just for > backwards compat as needed. > > exp_info.name = "default_cma"; > > All other CMA and carveout heaps will have names based on their > method of creation as there may be multiple of them, but there > will only every be one "default CMA" area, and its heap should > be named to match. This seems reasonable to me. Maybe putting the link creation behind a compatibility config so they can be later deprecated? That said, while I understand the impulse to want to fix the heap names so applications can depend on them, I also want to caution it's a little bit like trying to hard code eth0 as a network device name in your scripts. There are too many potential configurations, and any fixed mapping is going to break in some cases. I think there is just going to have to be some (gralloc-like) device-specific configuration glue to map a pipeline/use-case to the memory type (similar to fstab for filesystem to mount points) in order to handle every case. So if I'm being a little squirrely on fixed names, it's mostly due to wanting to avoid anyone getting the mistaken impression that fixed mappings will generally work. thanks -john
