Re: RFC: New userspace fetch/store API

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

[Sorry, I meant to respond to multiple points in my prior message, but the coffee hasn’t fully kicked in yet…]

> On Feb 24, 2019, at 7:05 AM, Andrew Cagney <andrew.cagney%gmail.com@localhost> wrote:
> 
> 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.

In my particular case, it’s the kernel portion of an API that on other platforms uses an “int” in this particular argument slot.  For the sake of not only API compatibility as well as COMPAT_* compatibility, “int” is what I decided to go with for my particular use case.

My intent was to cover the “natural”[*] fixed-size types for a particular arch, and then provide convenience aliases for the common basic C types: char, short, int, long, pointer.  The latter are aliases (and I wanted to place the aliases in a centralized location, subr_copy.c, but the assembler / linker doesn’t like aliasing symbols in a different compilation unit).

[*] pre-BWX alpha of course has to emulate 8- and 16-bit accesses.

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

As I mentioned in my reply to Edgar, this is to be consistent with atomic_ops(3), which in turn used the same names as Solaris.

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

Yes, well, one of the problems with the old fetch(9) API is that “error condition” and “value” are returned in the same place, and thus there are ambiguous cases.

-- thorpej