/proc/vc-mem

[nomis]

/proc/vc-mem won't be accepted into the mainline kernel because it's not what /proc is for - this could become a problem if userspace libraries need to access it and it disappears in a future kernel.

It's a mix of textual information and a memory mmap device, so the text/ioctl information can be moved to sysfs attributes.

These are virtual text files in /sys that contain a single value, e.g. /sys/devices/vc_mem.N/mem_base, /sys/devices/vc_mem.N/mem_size, /sys/devices/vc_mem.N/mem_phys_addr (the name "vc_mem.N" would vary based on how it's specified in the device tree, e.g. "vc_mem.2" if it's the third device without an io/memory base). They could be populated from device tree so the GPU bootloader could change them, although making them properly addressable when it's not simply overlapping the ARM memory could be complicated.

Could mmapping /dev/mem be used instead of mmapping /proc/vc-mem?
If you know the memory base you know where to access it in /dev/mem.

[GrayGirling]

No one has responded to this, so I'll provide what is probably a very poor-quality comment.

It's a mix of textual information and a memory mmap device

I hadn't realized this - I'd assumed it was just the former. The device aspect might better be represented as another memory device. It seems that this driver is an old version of one present elsewhere internally to Broadcom. The "new" version does represent it as /dev/vc-mem.

Could mmapping /dev/mem be used instead of mmapping /proc/vc-mem?

Part of the rationale for its provision was security:
"Since the driver memory maps the videocore memory, it can present a potential security risk. This is mitigated by the setting the correct permissions of the character device /dev/vc-mem. If the device is only given root access, then only user apps started by root will have access to the device, and in turn to the memory mapped videocore memory. It is no more or less safe than the /dev/mem device, which allows memory mapping access to all system memory."

But, otherwise, I think the answer is "yes".

It has already been noted elsewhere in the forum that this implementation should be considered vestigial and be allowed to atrophy: the values it uses are not correctly maintained ... the size, for example, does not vary with the actual amount of memory allocated to the ARM.

My understanding is that:

echo connect > /proc/vc-mem

is supposed to retrieve the correct values. But, in fact, we just get a write error: Bad address. Making this work properly might be a useful precursor to splitting out the /dev functionality.