Re: RFC: New userspace fetch/store API

[Jason Thorpe <thorpej%me.com@localhost>]

> On Feb 24, 2019, at 7:05 AM, Andrew Cagney <andrew.cagney%gmail.com@localhost> wrote:
> 
> Can there be an inefficient default, implemented using something like
> copy{in,out}() (yes I note the point about alignment).  I sometimes
> wonder of NetBSD's lost its way in terms of portability - it seems to
> be accumulating an increasing number of redundant yet required
> primitives.

Honestly, it’s not adding that many — most of the ones specified in my proposal were required before (to varying degrees) just with different names and return semantics.  And most of the “new” ones in my proposal as simple aliases.  Furthermore, on the two implementations I’ve done so far, a great deal of the code is macro-ized to reduce the redundant typing, and even the “intrsafe” ones share most of the code by using a different (macro-ized) prologue and then jumping into the body of the non-intrsafe variant.  It’s really not that much code.

As far as “inefficient default” … depending on how copyin / copyout are implemented, it’s also an issue of correctness.  At least the 32-bit and 64-bit variants would need to be atomic with respect to other loads / stores to the same address.  This is one property that I need for my own use.

If there really is a concern about the number of operations here,I would be more than happy to drop the _8 and _16 (and thus char and short) widths from the formal API… but then other MI code would need to change to lose that functionality (in the case of the profiling code that uses fuswintr() and suswintr()), or to use heavier means of doing the same thing (e.g. copyin or copyout of a single byte).

-- thorpej