alan@lxorguk.ukuu.org.uk (Alan Cox) wrote:
>Victor and for that matter a lot of the other folk. Have a good look at
>the DIPC patches before you judge them. They are relatively clean, they
>are very easy to program with and they definitely work. In fact I got
>bored enough to rebuild X11 with DIPC XShm objects to prove the point.
>
>Try it, use it, judge it...
>
>The argument for distributed shared memory objects isnt 'should we/shouldnt
>we' its 'can you take the DIPC shared memory objects and push them efficiently
>into user space without kernel support. That might be possible, though I
>dont think you can with the other objects it provides.
DIPC has to know about all the IPC keys in use in the cluster. An example to
show this is: application A1 uses key value 100 in computer M1 of the cluster
to create a "local" message queue. Now the attempt of application A2 in
computer M2 to create a "global" (distributed) message queue with the same
key value (100) should fail, because there will be a clash if A2 creates
a process in M1 that needs to use the message queue.
Older programs use local message queues (the default behaviour of DIPC).
As far as I know, unless we do some recompilations, there is no way to force
these programs to use a library when creating an IPC structure; they go
directly to the kernel.
If the kernel is not modified to inform DIPC's user space entities of the
creation of new IPC structures, then DIPC can not work. In short, the problem
is that the kernel has been the traditional service point for programs using
System V IPC. The practical way to keep total compatibility (very important
for me) is to continue using this interface. However, if there is a way to
make sure all programs pass through a library before going to the kernel,
then one can consider using it.
The case for shared memories is more complicated. Providing shared memory's
strict consistency needs direct support from the kernel's memory management
routines and structures. Shared memory is not used by calling a system call,
so using a library is not applicable here. Managing the memory protection
issues from the user space, and in a transparent way will be very awkward,
if at all possible.
Considering that transparency is very important for DIPC's ease of use, I
believe that any changes that damage this transparency should be avoided.
DIPC's small additions to the kernel are interleaved with the normal kernel
code in a simple and understandable way. Even if the backward compatibility
issues can be resolved, I think it is better, for the sake of the overall
simplicity of the system, that they remain there.
-Kamran Karimi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu