On Sat, 23 Feb 2019 at 18:26, Jason Thorpe <thor...@me.com> 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.