On 2025-01-17 11:38:39, Niklas Schnelle wrote: >On Fri, 2025-01-17 at 10:13 +0800, Dust Li wrote: >> > >---8<--- >> > Here are some of my thoughts on the matter: >> > > > >> > > > Naming and Structure: I suggest we refer to it as SHD (Shared Memory >> > > > Device) instead of ISM (Internal Shared Memory). >> > >> > >> > So where does the 'H' come from? If you want to call it Shared Memory _D_evice? >> >> Oh, I was trying to refer to SHM(Share memory file in the userspace, see man >> shm_open(3)). SMD is also OK. >> >> > >> > >> > To my knowledge, a >> > > > "Shared Memory Device" better encapsulates the functionality we're >> > > > aiming to implement. >> > >> > >> > Could you explain why that would be better? >> > 'Internal Shared Memory' is supposed to be a bit of a counterpart to the >> > Remote 'R' in RoCE. Not the greatest name, but it is used already by our ISM >> > devices and by ism_loopback. So what is the benefit in changing it? >> >> I believe that if we are going to separate and refine the code, and add >> a common subsystem, we should choose the most appropriate name. >> >> In my opinion, "ISM" doesn’t quite capture what the device provides. >> Since we’re adding a "Device" that enables different entities (such as >> processes or VMs) to perform shared memory communication, I think a more >> fitting name would be better. If you have any alternative suggestions, >> I’m open to them. > >I kept thinking about this a bit and I'd like to propose yet another >name for this group of devices: Memory Communication Devices (MCD) > >One important point I see is that there is a bit of a misnomer in the >existing ISM name in that our ISM device does in fact *not* share >memory in the common sense of the "shared memory" wording. Instead it >copies data between partitions of memory that share a common >cache/memory hierarchy while not sharing the memory itself. loopback- >ism and a possibly future virtio-ism on the other hand would share >memory in the "shared memory" sense. Though I'd very much hope they >will retain a copy mode to allow use in partition scenarios. > >With that background I think the common denominator between them and >the main idea behind ISM is that they facilitate communication via >memory buffers and very simple and reliable copy/share operations. I >think this would also capture our planned use-case of devices (TTYs, >block devices, framebuffers + HID etc) provided by a peer on top of >such a memory communication device. Make sense, I agree with MCD. Best regard, Dust
