Re: CVS commit: src

[yamt%mwd.biglobe.ne.jp@localhost (YAMAMOTO Takashi)]

> 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.
> 
> Interesting to hear some earlier thoughts on this!
> 
> There is one aspect which is worthwhile to point out.  POSIX shared memory
> is a POSIX "real time extension" (not that it matters how is it labelled).
> However, UNIX was never designed with hard real-time systems in mind i.e.
> most facilities work on best-effort basis.
> 
> So my position is not very strong on this.  On the other hand, I would
> like to see NetBSD as a solid framework which could be used as a base for
> building, at least, soft real-time systems.  There is still a lot of work
> to do, but it is about the time to have discussions like this.
> 
>> 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?
> 
> It is my thinking as well.  I agree that ENOTSUP sucks, but it serves as
> a *guard* for missing tmpfs mount.  Otherwise, tmpfs is available on all
> ports and I see no reason why it could not be always provided (well, maybe
> not on acorn26, but who cares).

then please provide it regardless of the amount of memory a system
happens to have when installing OS.

and IMO requiring to build a custom librt is too strong guard for
things like this.

YAMAMOTO Takashi

> 
> -- 
> Mindaugas