"Dr. Michael Weller" <eowmob@exp-math.uni-essen.de> writes:
> On 20 Aug 1999, Christoph Rohland wrote:
>
> > 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).
1) You can only inherit the mapping over fork
2) Linux does not implement shared anonymous mappings.
> 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.
I am sorry, it is not available. Eric Biedermann started shmfs long
time ago which would make this possible but 'til this is ready...
> > 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.
One call supported on two other platforms is 'modifying the new OS so
much that no porting is possible'? Further on one of the syntactical
variants is commonplace on UNIX platforms.
SAP has a common implementation which runs on many Unixes (including
Linux) but it has its limitations. The other would be much better and
would help Linux to compete with the other platforms.
> 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.
It is running on AIX, HP-UX, Reliant, Solaris, Tru64 et.al.
> 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.
Calm down. As said before we can run on Linux without this, but:
I think I have two possibilities for making Linux work better together
with R/3:
1) Implement this one call
2) Waiting for shmfs which would make another implementation possible
choice 1) seems to me the only way in the short term since I did not
see anything from Eric for a long time.
But I do not want an ugly kludge and also no special R/3 module. I
simply want to have good result for Linux :-)
Greetings
Christoph
-- ______________________________________________ Christoph Rohland, LinuxLab, SAP-AG, Germany- 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/