Re: RFC: New userspace fetch/store API

[Andrew Cagney <andrew.cagney%gmail.com@localhost>]

On Sun, 24 Feb 2019 at 10:38, Jason Thorpe <thorpej%me.com@localhost> wrote:
>
>
> > 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.

Right.. But can it be done once in generic code using information
available while compiling?

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

And that's a hard requirement.  What of the other way around - copy*()
implemented using fetch_*().



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