Hi,
I have some patches now (that I have to clean up and further test)
that do sysv shm to the extent which is required by applications
(except those rare ones which check nattch == 1 or something).
The requirements for the underlying filesystem are:
* Use of --inherit-dir-group to get SysV semantics of group ownership
of the created files. If this is not used, SHM will still work, but the
group ID of the created files will be wrong.
* Report of the new IMMAP0 stat mode bit. If this is not available,
SHM will still work, but nattch will never be 0, which will cause a
small but significant number of programs to fail.
So far, I have done tests with ext2fs as the underlying store. tmpfs
is reportedly broken, which means we have a good incentive to fix it
now. However, there is a problem:
tmpfs uses memory objects provided by the default pager. This
duplicates the problem finding out how many users there are at a
deeper level: There is always at least one "user", namely tmpfs
itself. If there are more users than just tmpfs we don't know. The
default pager could provide this information, testing for == 1 (in
this case, it would be tmpfs) or > 1 (more than tmpfs).
Adding such an interface to the default pager would be possible, I
guess, and it would have the desired effect. It's still a bit awkward.
An alternative would be to never hand out the default pager provided
memory object directly, but a proxy object. This is not as horrible
as it first sounds: Specifically, we need to do it anyway at least for
read-only memory objects for permission control. This would require
the memory proxy object feature in Mach, which would simply be used
for read _and_ for read-write access.
This needs probably a bit more thought (and tmpfs needs more testing,
as reportedly it is "broken"). But it's a real showstopper for using
tmpfs. Until we have worked something out, ext2fs could be used with
a ramdisk though (with the usual problem that a ramdisk needs
initialization).
Thanks,
Marcus