On Thu, Dec 05, 2024 at 03:17:57PM -0800, John Stultz wrote: > 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 sounds reasonable to me too. However, I'm not sure how to create a symlink in devtmpfs from the kernel. Or maybe we should create a second device file with the same major / minor? > 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 certainly don't want to spark *that* discussion again, but it's exactly why I wasn't convinced about the names providing the guarantees back in Plumbers. I definitely agree with you there that the situation is kind of messy already, and it will only get worse. It will be really hard to document, and if we can't document it, userspace can't rely on guarantees either. > 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. That might work for Android, but it really doesn't for anything more generic than that. > 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. Ack :) Maxime
Attachment:
signature.asc
Description: PGP signature
