Re: CVS commit: src

[Justin Cormack <justin%specialbusservice.com@localhost>]

On Wed, Dec 25, 2013 at 2:09 PM, Thor Lancelot Simon <tls%panix.com@localhost> 
wrote:
> On Tue, Dec 24, 2013 at 04:19:18PM +0200, Mindaugas Rasiukevicius wrote:
>>
>> Hence, I leaned towards not supporting the interface, instead of providing
>> one which does not meet the expectations.  What do you think?
>
> This is consistent with what Kirk McKusick and Keith Bostic told me many
> years ago about CSRG's thinking on this issue (though of course at the
> time the primitives in question were the System V, not the POSIX ones):
> that the API is optional and is expected to be memory-backed, and that
> users of the API would surely not expect disk-like latencies when it was
> called; so if there was no memory filesystem available, the API should
> not be provided.
>
> However, this conflicts with the modern "portability" paradigm of doing
> all feature tests at compile rather than runtime, so I'm a bit torn;
> perhaps better to always mount a tmpfs on /var/shm at install time (or
> even explicitly from an independent RC script?) but constrain its size
> severely by system memory size at install time?

This seems to be what the other OSs do, there is no code to test
whether the filesystem is tmpfs, just assume that if you use the
feature you have it mounted correctly.

You could probably make usage fail by making the mount point have no
read write permissions, so if nothing was mounted there it would fail.
I notice Ubuntu Linux makes /dev/shm (which is what shmopen looks for)
a symlink to /run/shm where /run is a tmpfs filesystem too, so if you
haven't mounted the standard tmpfs filesystems all access will fail
completely.

Justin