[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: CVS commit: src
> 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.
Main Index |
Thread Index |