[GSOC] System V IPC in userspace week4 report

Hi everyone,

This week I have implemented the shared memory support in userland. I used
the actual kernel implementation and moved all structures and functions
needed by daemon in userspace.

Each shm function is described below:
- *shmget:*
  - userland
     - sends a message to the daemon with key, size and shmflags;
     - the daemon will search for the existing segment
     - if the segment already exists, some checks are made on permissions,
size, flags and the segment id is returned*
*
     - else allocates a new segment
     - the daemon replies with the segment identifier
  - kernel
     - tells the kernel to allocate a new vm_object_t if the segment does
not exist

- *shmctl*
  - userland
     - IPC_STAT - sends a request to the daemon and waits for information
needed; daemon has all information so it only sends them through pipe;
     - IPC_SET - sends request to the daemon and waits for the error code;
     - IPC_RMID - sends request to the daemon and waits for the error code;
  - kernel
     - for IPC_SET and IPC_RMID,  the daemon informs kernel about the state
of the segment; The kernel is informed because shmat calls directly ioctl,
without the daemon intervention.

- *shmat* - calls ioctl() function that will do mostly the same operations
as the current shm implementation (permission checks, add the *vm_object_t* in
the process address space); the driver mmap announces the daemon that
another process mapps the shared memory object;
*- shmdt* - same as in *shmat* case

Because, in the actual kernel implementation, more threads can access same
data, some states describing each segment are used. I kept those because I
think the daemon must use a poll of threads to handle the clients requests
for performances reasons.

Tomorrow I will do a code refactoring (including splitting daemon, library
and client code), following that next days I will start implement support
for semaphores.

Thanks,
Larisa