Messages in this thread | | | Date | Fri, 20 Aug 1999 18:26:46 +0200 (MESZ) | From | "Dr. Michael Weller" <> | Subject | Re: AIX disclaim() or Tru64 madvise (MADV_DONTNEED) needed |
| |
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).
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/
| |