<div dir="ltr"><div>Hello, </div><div> </div><div>My name is Larisa Grigore and I am student in the second year at a master program "Internet  </div><div>Engineering" from Polytechnics University of Bucharest, Romania, Computer Science and  </div>
<div>Engineering Department.  </div><div> </div><div>Currently I am working at a research project for master program. The project is about "High Availability".  We try to keep a system, that runs over a microkernel </div>
<div>from L4 family, alive no matter what happens with its components. The detected faults are segmentation faults, deadlocks and killed threads. From the point of view of recovery, two possible options are provided: restarting an address space or restoring it from some checkpoint. The user can order classic and incremental checkpoint and use those two types in correlation with fork mechanism. In order to build the HA module, memory management and fork with copy-on-write mechanisms were implemented. </div>
<div>High Availability features, previously developed for native applications running on top of microkernel,  were extended for Linux operating system. A kernel module was implemented to support fault detection (deadlocks, segmentation faults and killed processes) and recovery. The process can be restarted from zero or from a specific checkpoint. </div>
<div>The project aims to cover cases where Android fails to restore properly an application. After studding frequent android application failures, we concluded that High Availability support can be useful for some classes of applications too.  </div>
<div> </div><div>From July 2013, I am Associated Teaching Assistant in University Polytechnics of Bucharest. I am teaching labs and develop lab material for Operating Systems classes. </div><div> </div><div>I am interested in "Userland System V Shared Memory / Semaphore / Message Queue implementation" project on  </div>
<div>GSOC page. Here are few ideas after some research in System V area:</div><div>- daemon </div><div>  - it will take care for the management of system v resources; all operations as creation/destruction will be implemented through messages sent  </div>
<div>  to it; </div><div>- communication with daemon </div><div>  - first step (registration)  </div><div>    - using a known named pipe to tell the daemon that the process wants to open a communication </div><div>  - second step (communication) </div>
<div>    - both client process and daemon will open another named pipe, based on client pid and will use it to talk each other </div><div> </div><div>- shared memory </div><div>  - daemon will create files in order to be mapped in the processes address space and will keep other information related </div>
<div> </div><div>- semaphores </div><div>  - an implementation similar to Posix Unnamed semaphores (memory-based semaphores) [1] </div><div>  - client will ask for a semaphore and the daemon will return a file and an offset for the semaphore </div>
<div>  - acquiring and releasing a semaphore will be done as sem_wait and sem_post posix implementation; atomic functions will be used in order  </div><div>  to test the semaphore value; umtx_sleep(2)/umtx_wakeup(2) will be used in case one process must block </div>
<div>  - the daemon is responsible for telling the clients where to find a semaphore </div><div>  - there are two approaches:  </div><div>    1. for each semaphore, a process must map a file with the size of PAGE_SIZE; the problem  </div>
<div>    with this approach is the big amount of memory used in case of multiple semaphores </div><div>    2. more semaphores corresponding to a file; here some security issues appear because an application may have access to  </div>
<div>    semaphores not opened by it</div><div> </div><div>- message queues </div><div>  - client will send a message to the daemon, asking for a message queue; the daemon will respond with a file to map in its address space </div>
<div>  - the queue size will depend on file size </div><div>  - the file will contain, beside messages written by processes, some control information (related to number of messages, the first message offset, etc)</div><div>
<br></div><div>Any feedback on this is welcome.</div><div><br></div><div>[1] <a href="http://linux.die.net/man/7/sem_overview">http://linux.die.net/man/7/sem_overview</a> </div></div>