On Sun, 24 Feb 2019 at 10:38, Jason Thorpe <[email protected]> wrote: > > > > On Feb 24, 2019, at 7:05 AM, Andrew Cagney <[email protected]> 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 >
