[no subject]

I am interested in "Userland System V Shared Memory / Semaphore / Message
Queue implementation" project on
GSOC page. Here are few ideas after some research in System V area:
- daemon
  - it will take care for the management of system v resources; all
operations as creation/destruction will be implemented through messages
sent
  to it;
- communication with daemon
  - first step (registration)
    - using a known named pipe to tell the daemon that the process wants to
open a communication
  - second step (communication)
    - both client process and daemon will open another named pipe, based on
client pid and will use it to talk each other

- shared memory
  - daemon will create files in order to be mapped in the processes address
space and will keep other information related

- semaphores
  - an implementation similar to Posix Unnamed semaphores (memory-based
semaphores) [1]
  - client will ask for a semaphore and the daemon will return a file and
an offset for the semaphore
  - acquiring and releasing a semaphore will be done as sem_wait and
sem_post posix implementation; atomic functions will be used in order
  to test the semaphore value; umtx_sleep(2)/umtx_wakeup(2) will be used in
case one process must block
  - the daemon is responsible for telling the clients where to find a
semaphore
  - there are two approaches:
    1. for each semaphore, a process must map a file with the size of
PAGE_SIZE; the problem
    with this approach is the big amount of memory used in case of multiple
semaphores
    2. more semaphores corresponding to a file; here some security issues
appear because an application may have access to
    semaphores not opened by it

- message queues
  - 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
  - the queue size will depend on file size
  - the file will contain, beside messages written by processes, some
control information (related to number of messages, the first message
offset, etc)

Any feedback on this is welcome.

[1] http://linux.die.net/man/7/sem_overview

--047d7bea431094c7b304db0a260f
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Hello,=A0</div><div>=A0</div><div>My name is Larisa G=
rigore and I am student in the second year at a master program &quot;Intern=
et =A0</div><div>Engineering&quot; from Polytechnics University of Buchares=
t, Romania, Computer Science and =A0</div>
<div>Engineering Department. =A0</div><div>=A0</div><div>Currently I am wor=
king at a research project for master program. The project is about &quot;H=
igh Availability&quot;. =A0We try to keep a system, that runs over a microk=
ernel=A0</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: restarti=
ng an address space or restoring it from some checkpoint. The user can orde=
r classic and incremental checkpoint and use those two types in correlation=
 with fork mechanism. In order to build the HA module, memory management an=
d fork with copy-on-write mechanisms were implemented.=A0</div>
<div>High Availability features, previously developed for native applicatio=
ns running on top of microkernel, =A0were extended for Linux operating syst=
em. 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.=A0</div>
<div>The project aims to cover cases where Android fails to restore properl=
y an application. After studding frequent android application failures, we =
concluded that High Availability support can be useful for some classes of =
applications too. =A0</div>
<div>=A0</div><div>From July 2013, I am Associated Teaching Assistant in Un=
iversity Polytechnics of Bucharest. I am teaching labs and develop lab mate=
rial for Operating Systems classes.=A0</div><div>=A0</div><div>I am interes=
ted in &quot;Userland System V Shared Memory / Semaphore / Message Queue im=
plementation&quot; project on =A0</div>
<div>GSOC page. Here are few ideas after some research in System V area:</d=
iv><div>- daemon=A0</div><div>=A0 - it will take care for the management of=
 system v resources; all operations as creation/destruction will be impleme=
nted through messages sent =A0</div>
<div>=A0 to it;=A0</div><div>- communication with daemon=A0</div><div>=A0 -=
 first step (registration) =A0</div><div>=A0 =A0 - using a known named pipe=
 to tell the daemon that the process wants to open a communication=A0</div>=
<div>=A0 - second step (communication)=A0</div>
<div>=A0 =A0 - both client process and daemon will open another named pipe,=
 based on client pid and will use it to talk each other=A0</div><div>=A0</d=
iv><div>- shared memory=A0</div><div>=A0 - daemon will create files in orde=
r to be mapped in the processes address space and will keep other informati=
on related=A0</div>
<div>=A0</div><div>- semaphores=A0</div><div>=A0 - an implementation simila=
r to Posix Unnamed semaphores (memory-based semaphores) [1]=A0</div><div>=
=A0 - client will ask for a semaphore and the daemon will return a file and=
 an offset for the semaphore=A0</div>
<div>=A0 - acquiring and releasing a semaphore will be done as sem_wait and=
 sem_post posix implementation; atomic functions will be used in order =A0<=
/div><div>=A0 to test the semaphore value; umtx_sleep(2)/umtx_wakeup(2) wil=
l be used in case one process must block=A0</div>
<div>=A0 - the daemon is responsible for telling the clients where to find =
a semaphore=A0</div><div>=A0 - there are two approaches: =A0</div><div>=A0 =
=A0 1. for each semaphore, a process must map a file with the size of PAGE_=
SIZE; the problem =A0</div>
<div>=A0 =A0 with this approach is the big amount of memory used in case of=
 multiple semaphores=A0</div><div>=A0 =A0 2. more semaphores corresponding =
to a file; here some security issues appear because an application may have=
 access to =A0</div>
<div>=A0 =A0 semaphores not opened by it</div><div>=A0</div><div>- message =
queues=A0</div><div>=A0 - client will send a message to the daemon, asking =
for a message queue; the daemon will respond with a file to map in its addr=
ess space=A0</div>
<div>=A0 - the queue size will depend on file size=A0</div><div>=A0 - the f=
ile will contain, beside messages written by processes, some control inform=
ation (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=3D"http://linux.die.net/man/7/sem_overview";>http://linux.die.net/=
man/7/sem_overview</a>=A0</div></div>

--047d7bea431094c7b304db0a260f--