Shared memory Master/Slave process to access single serial port - shared-memory

I am creating a Daemon in Unix that will have exclusive access to a serial port "/dev/tty01". I am planning to create a Master - Slave process paradigm where there is one master (the daemon) and multiple slaves.
I was thinking of having a structure in "Shared memory" where the slaves can access, and there is only one writer to the memory so I most likely wont need a semaphore. The data will be updated fairly slowly, once every minute for example.
I was looking into what would be the best possible way to do this, also if I have a structure in shared memory, how can I guarantee that the structure will be contiguous in memory? It is a requirement I must have.
The master program will have its own internal data structure that is being updated from the serial port, and then it will modify the data and send it out to a global structure that is in shared memory for the clients to use.
I dont have much experience in Unix IPC, but what would be the easiest way to do this? By the way the clients will all be different processes ran by other users locally on the system
It must used shared memory it is a requirement of the project. Also, is it possible to copy one structure into another if the second structure has different data types?

A shared memory segment is a contiguous piece of memory from your process' view.
The calls to create and handle shared memory are rather simple (shmctl/shmat/shmdt)
The layout of the structures in the memory is up to you. Best is a fixed header like a type field and the rest as an union.
For your client processes you could provide a little lib (static or shared) with a set of functions to retrieve data, thereby hiding the shared memory and the structures.

Related

Interprocess sharing of persistent buffers with GL_EXT_memory_object

I am trying to understand GL_EXT_memory_object and the Vulkan equivalents. And I want to know if it is possible to share OpenGL persistent buffers across processes somehow? For example to allow different processes to write data to the same buffer for upload without needing interprocess memory copying or mapping (ie each process writes to an allocated region, somehow synchronise, and one process then renders using the data).
So far I came across persistent buffers not working in a case mentioned here:
https://www.khronos.org/registry/OpenGL/extensions/NV/NV_memory_attachment.txt
"Client-mappable resources are supported but not when they are persistent. When memory is attached resource must be unmapped."
Also I am not sure what that may imply regards different processes mapping the same resource for writing with glMapBuffer() etc.
If this isn't possible in OpenGL, is it possible in Vulkan or in an nVidia specific way?

Should pointers to memory mapped files be consistent across processes?

I am doing some work that requires interprocess communication. I created a memory-mapped file using CreateFileMapping (using windows API) in one process. In another process I used OpenFileMapping and MapViewOfFile to access the (supposedly) same data. I found that the address of these data are different in each process, is this expected or have I done something wrong?
This is completely expected and normal behavior.
Different processes have different address spaces. A pointer in one process is not valid in another process. What is important is that each process obtains its own local valid pointer to your shared mapping object. When each process wants to access the data inside of the shared mapping object, the access needs to be done using pointers and addresses that are relative to each process.
This is covered in more detail in Microsoft's own documentation: File Mapping

Shared Memory in windows for sharing objects (which contain members which are pointers)

I am working on a windows system. I need to create a shared memory for inter process communication to share objects (containing pointers as members). Or some equivalent way for fast transfer of objects from a generator process to a receiver process. the size of the objects are also huge. How do i do that? The porblem is that even if i share the objects I need a way so that the other process gets the access to the locations pointed by the pointers in the objects. And sharing each of those locations for each object is not feasible.
It's difficult to say without more details, but I would consider a memory mapped file. How you create the file depends on whether you need to communicate between sessions or not. You would also need a notification mechanism when new data was posted. You could do that with a registered message, but again that's only possible if your processes are in the same session/desktop.
I can't really be more specific without knowing the details of the requirement.

which driver is the owner of a handle?

is there any way to determine which driver is the owner of the hanlde?
I mean is it stored any where is Windows objects?
I can see handles via volatilty but all kernel handles are assigned to System.exe pid:4, I need to know exactly which driver is using this system handle?
thanks
Is there any way to determine which driver is the owner of the
handle?
When kernel modules (or thread in kernel space) call Kernel API (NtCreateFile, for example), the handles are allocated from handle table of System process. In this case, the answer is: no.
I mean is it stored any where is Windows objects?
I guess no
I need to know exactly which driver is using this system handle?
Depend on analisys you're doing. If you need to associate an object back to the driver that owns it, you can try to analize _POOL_HEADER structure to obtain information about who produced the allocation. BUT if you need to analyze an executive object (_FILE object, for example), the PoolTag field in this header will be equal to ObjectType.Key, so this way is not very useful for your purpose.
In general, if you're looking for which resources a process can access (i.e. memory-mapped files), you can analyze with memmap volatility's plugin the process' page tables and so the memory area of the process. I suggest you to use VAD structures' dedicated plugin so that you can gather an high-level information about virtual address space of the process.

Controlling read/writes to memory mapped files (windows)

Are you meant to protect against simultanously reads/writes to file mapped memory that is open by multiple processes?
For example if a string in the memory is "hello" and one process writes "hi..." over it, am I correct to say that another process that reads at the same time may get an intermittant value like "hi.lo"?
Basically what I am asking is how do people protect again these sorts of things. Are you meant to use semaphores? Do these work across processes?
Yes, if you need to protect against multiple writers or avoid reading partial updates then a shared Mutex / Semaphore used by each process would work to control access to the shared data.
There is some sample code which does this at the bottom of this MSDN article: Memory-Mapped Files in .NET 4.0

Resources