tech-userlevel archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: CVS commit: src

In article 
Justin Cormack  <> wrote:
>On Wed, Dec 25, 2013 at 2:09 PM, Thor Lancelot Simon <> 
>> 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

You could make shm_open to statvfs and print a warning or exit with an
error the first time it is used if it is not on tmpfs.


Home | Main Index | Thread Index | Old Index