Hi,
Here is a patchset about the IPC, which proposes to consolidate some
part of the existing code and to add some functionalities.
* Patches 1 to 8 don't change the existing behavior, but propose to rewrite
some parts of the existing code. In fact, the three kinds of IPC (semaphores,
message queues and shared memory) have some common commands (IPC_SET, IPC_RMID,
etc...) but they are mainly handled in three different ways. These patches
propose to consolidate this, by handling these commands the same way and try
to use, as much as possible, some common code. This should increase
readability and maintainability of the code, making them probably good
candidate for the -mm tree, I think.
* Patches 9 to 15 propose to add some functionalities, and thus are
submitted here for RFC, about both the interest and their implementation.
These functionalities are:
- Two new control-commands:
. IPC_SETID: to change an IPC's id.
. IPC_SETALL: behaves as IPC_SET, except that it also sets all time
and pid values)
- add a /proc/<pid>/semundo file to read and write the undo values of
some semaphores for a given process.
As the namespaces and the "containers" are being integrated in the
kernel, these functionalities may be a first step to implement the
checkpoint/restart of an application: in fact the existing API does not allow
to specify or to change an ID when creating an IPC, when restarting an
application, and the times/pids values of each IPCs are also altered. May be
someone may find another interest about this ?
So again, comments are welcome.
Thanks.
--
Pierre
Hi!
> * Patches 9 to 15 propose to add some functionalities, and thus are
> submitted here for RFC, about both the interest and their implementation.
> These functionalities are:
> - Two new control-commands:
> . IPC_SETID: to change an IPC's id.
> . IPC_SETALL: behaves as IPC_SET, except that it also sets all time
> and pid values)
> - add a /proc/<pid>/semundo file to read and write the undo values of
> some semaphores for a given process.
>
> As the namespaces and the "containers" are being integrated in the
> kernel, these functionalities may be a first step to implement the
> checkpoint/restart of an application: in fact the existing API does not allow
> to specify or to change an ID when creating an IPC, when restarting an
> application, and the times/pids values of each IPCs are also altered. May be
> someone may find another interest about this ?
>
> So again, comments are welcome.
Checkpoint/restart is nice, but... sysV ipc is broken by design, do we
really want to extend it?
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Pavel Machek wrote:
> Hi!
>
>> * Patches 9 to 15 propose to add some functionalities, and thus are
>> submitted here for RFC, about both the interest and their implementation.
>> These functionalities are:
>> - Two new control-commands:
>> . IPC_SETID: to change an IPC's id.
>> . IPC_SETALL: behaves as IPC_SET, except that it also sets all time
>> and pid values)
>> - add a /proc/<pid>/semundo file to read and write the undo values of
>> some semaphores for a given process.
>>
>> As the namespaces and the "containers" are being integrated in the
>> kernel, these functionalities may be a first step to implement the
>> checkpoint/restart of an application: in fact the existing API does not allow
>> to specify or to change an ID when creating an IPC, when restarting an
>> application, and the times/pids values of each IPCs are also altered. May be
>> someone may find another interest about this ?
>>
>> So again, comments are welcome.
>
> Checkpoint/restart is nice, but... sysV ipc is broken by design, do we
> really want to extend it?
If we want to support all kind of applications, yes, we must also support
SysVipc. We must support all kernel subsystems at the end.
I've started with IPC, because it's relatively simple and isolated.
--
Pierre
Pavel Machek wrote:
> Hi!
>
>> * Patches 9 to 15 propose to add some functionalities, and thus are
>> submitted here for RFC, about both the interest and their implementation.
>> These functionalities are:
>> - Two new control-commands:
>> . IPC_SETID: to change an IPC's id.
>> . IPC_SETALL: behaves as IPC_SET, except that it also sets all time
>> and pid values)
>> - add a /proc/<pid>/semundo file to read and write the undo values of
>> some semaphores for a given process.
>>
>> As the namespaces and the "containers" are being integrated in the
>> kernel, these functionalities may be a first step to implement the
>> checkpoint/restart of an application: in fact the existing API does not allow
>> to specify or to change an ID when creating an IPC, when restarting an
>> application, and the times/pids values of each IPCs are also altered. May be
>> someone may find another interest about this ?
>>
>> So again, comments are welcome.
>
> Checkpoint/restart is nice, but... sysV ipc is broken by design, do we
> really want to extend it?
> Pavel
For my personal culture, what do you mean by "broken by design"?
Even if it's broken, don't you think some people could be interested in
checkpointing "legacy" applications that use SysV IPC?
Benjamin
--
B e n j a m i n T h e r y - BULL/DT/Open Software R&D
http://www.bull.com
Hi!
>>> As the namespaces and the "containers" are being integrated in the
>>> kernel, these functionalities may be a first step to implement the
>>> checkpoint/restart of an application: in fact the existing API does not allow
>>> to specify or to change an ID when creating an IPC, when restarting an
>>> application, and the times/pids values of each IPCs are also altered. May be
>>> someone may find another interest about this ?
>>>
>>> So again, comments are welcome.
>>
>> Checkpoint/restart is nice, but... sysV ipc is broken by design, do we
>> really want to extend it?
>
> For my personal culture, what do you mean by "broken by design"?
int shmget(key_t key, size_t size, int shmflg);
....so how do you produce key in a way that is guaranteed not to
interfere with other uses?
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html