Re: RFC: New userspace fetch/store API

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

On Sat, 23 Feb 2019 at 18:26, Jason Thorpe <thorpej%me.com@localhost> wrote:

> A project I’m working on has a need for a proper “int” size fetch / store on all platforms, and it seems best to just tidy the whole mess up.  So, I am proposing a new replacement user fetch/store API.

Can you be more specific on why "int" rather than a more abstract type
(we've things like size_t ptrdiff_t et.al. all kicking around) - I'm
curious.

> I have implemented the new API for alpha and amd64, and am putting together a test harness to exercise all aspects of the new API.  Once that is done, I’ll tackle the remaining architectures.

> The implementation is entirely in architecture-dependent code.  The following fetch primitives must be supplied:

As a corollary to KRE's point, why?

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.

> int     ufetch_8(const uint8_t *uaddr, uint8_t *valp);

To follow through with Edgar Fuß's point.  If I were looking for a
function to transfer a uint8_t I'd expect it to be called
fetch_uint8().

> int     ufetch_16(const uint16_t *uaddr, uint16_t *valp);
> int     ufetch_32(const uint32_t *uaddr, uint32_t *valp);
> #ifdef _LP64
> int     ufetch_64(const uint64_t *uaddr, uint64_t *valp);
> #endif
>
> The following aliases must also be provided, mapped to the appropriate fixed-size primitives:
>
> int     ufetch_char(const unsigned char *uaddr, unsigned char *valp);
> int     ufetch_short(const unsigned short *uaddr, unsigned short *valp);
> int     ufetch_int(const unsigned int *uaddr, unsigned int *valp);
> int     ufetch_long(const unsigned long *uaddr, unsigned long *valp);
> int     ufetch_ptr(const void **uaddr, void **valp);

I do find passing pointers as both the addr and the dest confusing;
but you've added a const which should help get the order right.