> You can not use file descriptors for shared memory since they sync to
Except when you map /dev/zero, for example. However, I don't know if it
is possible to share a mapping of /dev/zero, maybe by creating a new
device node for it which is only used by the sharing processes, or if you
open /dev/zero only once and pass on the file descriptor to the other
processes (either through fork() or using unix-domain sockets).
I still see the concern of synchronising the procs to all to the unmap
which might add additional overhead.
> file on unmap. This would be possible if we had shm_open which
I don't use shared memory much myself. But I can't believe shm_open is not
available under linux.
> Also we are not able to change the general implementation of the R/3
> kernel, but have to choose between several given options.
Now this is an interesting concept ;-) . Porting an application to a new
OS by modifying the new OS so much that no porting is possible.
I think there are two choices here:
a) Every/most flavour(s) of Unix has one or the other way to do this (and
you already use all them), and it gives a significant amount of speedup
rather then just page in the pages and overwrite them and linux has no
way to this good thing (TM). Then I think the linux community will
happily implement this (well, someone needing it like you will do so
and the community will adopt it for the mainstream kernel) using the
API defined in whatever ISO OSI Xopen standard applies, or common sense
(read: what the majority does) lacking any other standard.
b) There are ways to do this as efficiently under linux. Maybe ways
already portable to the majority of Unix flavours (something with
passing on mmaped filedescriptors, for example). It maybe that your
application can not do this right now, but making a real port of it
would then actually be a major advantage for you as it will allow to
use it on almost all Unix flavours then as well.
Anyway, in this situation I doubt you'll be able to make the mainstream
linux kernel to support a broken API of your broken application. Even
when it is SAP, which is not just an application in Germany, but I
don't know about worldwide relevance.
So, if linux were a German OS, IC you might have chances to port linux
to your application rather than vice versa. Which does not mean it were
the right thing to do (TM) there either.
All this does not mean you aren't able to ship a special, own, linux
kernel with your application, of course. Or maybe a simple kernel-module
suffices. Most SAP installations will run on dedicated machines anyway.
Maybe people are even happy when you hand them a specific linux
distribution which installs your kernel modifications and SAP at the
same time.
--Michael Weller: eowmob@exp-math.uni-essen.de, eowmob@ms.exp-math.uni-essen.de, or even mat42b@spi.power.uni-essen.de. If you encounter an eowmob account on any machine in the net, it's very likely it's me.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/