Understanding Linux Kernel Inter-process Communication: Pipes, FIFO & IPC (Part 2)

Before we go on to look at different inter-process communication facilities in more detail, there is one very important topic I think I should cover. So, let's discuss the ipc_perm data structure; the structure associated with each and every 'IPC Resource'. But all readers must realize, that beyond a certain point, understanding the ipc_perm data structure and it's functionality becomes very difficult and complicated, and I really feel uncomfortable myself dealing with it. The fields in the ipc_perm data structure are:

Thus, when represented in its natural form, the ipc_perm data structure would look like this:

#include <sys/types.h>
#include <sys/ipc.h>

key_t ftok(char *pathname, char proj);

IPC_PRIVATE

struct ipc_perm
{

key_t key;
ushort uid;
ushort gid;
ushort cuid;
ushort cgid;
ushort mode;
ushort seq;

};

IPC_CREAT
IPC_EXCL

Readers should note the importance of ftok(char *pathname, char proj) function. The ftok() function attempts to create a new key from a file pathname and an 8-bit project identifier passed as parameters. It does not guarantee, however, a unique key number, since there is a small chance that it will return the same IPC key to two different applications using different pathnames and project identifiers. As mentioned earlier, each IPC resource is associated with an ipc_perm data structure. The uid, gid, cuid and cgid fields store the user and group identifiers of the resource's creator and the user and group identifiers of the current resource's owner, respectively. The "mode" bit mask includes six flags, which store the read and write access permissions for the resource's owner, the resource's group and other users. The "key" field (of type int) contains the IPC Key (which we have had earlier discussed) of the corresponding resource, and a "seq" field which stores the slot sequence number 's' used to compute the IPC Identifier of the resource. Now, the question that readers might be asking is: Hey, Subhasish, okay we understand the ipc_perm data structure. But what on earth does it do?

There exists a set of functions named semctl(), msgctl() and shmctl() functions, depending on whether the new resource is a semaphore, a message queue or a shared memory segment; which may be used tp handle IPC Resources. The IPC_SET subcommand allows a process to change the owner's user and group identifiers and the permission bit mask in the ipc_perm data structure. The IPC_STAT and IPC_INFO subcommands retrieve some information concerning a resource. Finally, the IPC_RMID subcommand releases an IPC resource. Thus, different subcommands, a few of which have been mentioned above, act on different fields of the ipc_perm data structure which in turn directly affects how IPC resources act, which in turn affects IPC facilities at its core. How, why and in what way exactly these subcommands act and thus affect the Linux Kernel is out of scope of this topic. Moreover it really gets very complicated from here on, and discussing it would mean a lot of problems for me (and you, the readers!). Trust me, I know it! Okay, now that we have seen what is an IPC Resource and studied a few things related to them, let's move on to the next section, where we would discuss all the three IPC Resources one by one, namely, semaphores, message queues and shared memory segments and see a few code segments in action. So, catch your breath and move on...