Re: CVS commit: src

[Mindaugas Rasiukevicius <rmind%netbsd.org@localhost>]

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).

-- 
Mindaugas