The existing fetch(9) / store(9) APIs have some problems. Specifically:
==> Their return semantics mean that fuword() cannot disambiguate between an
error condition (-1) and a legitimate fetch of -1 from user space.
==> “word” is poorly defined. For all practical purposes, it means “long”, and
i like this. the current API is ... odd.
can you add alignment documentation? eg, if only to say that it
must support aligned or unaligned accesses for the relevant
datatypes. not sure what we need currently, ie, if unaligned is
needed because that happens today, or we can define it as wrong
in
> On Feb 23, 2019, at 4:04 PM, matthew green wrote:
>
> i like this. the current API is ... odd.
Oh… any thoughts on “have intrsafe or not”?
-- thorpej
> On Feb 23, 2019, at 4:04 PM, matthew green wrote:
>
> i like this. the current API is ... odd.
>
> can you add alignment documentation? eg, if only to say that it
> must support aligned or unaligned accesses for the relevant
> datatypes. not sure what we need currently, ie, if unaligned
> On Feb 23, 2019, at 4:19 PM, Jason Thorpe wrote:
>> On Feb 23, 2019, at 4:04 PM, matthew green wrote:
>>
>> i like this. the current API is ... odd.
>>
>> can you add alignment documentation? eg, if only to say that it
>> must support aligned or unaligned accesses for the relevant
>> data
fuword/fuiword/suword/suiword (etc) are all ancient, and I would
have expected, largely deprecated these days - but what's wrong
with copyin/copyout ?Those could be optimised for particular
data sizes if there was some real need for that.
kre
> On Feb 23, 2019, at 6:35 PM, Robert Elz wrote:
>
> fuword/fuiword/suword/suiword (etc) are all ancient, and I would
> have expected, largely deprecated these days - but what's wrong
> with copyin/copyout ?Those could be optimised for particular
> data sizes if there was some real need fo
> 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, un
> On Feb 24, 2019, at 2:34 AM, Edgar Fuß wrote:
>
>> 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 shor
On Sat, 23 Feb 2019 at 18:26, Jason Thorpe 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
> On Feb 24, 2019, at 7:05 AM, Andrew Cagney 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 increa
[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 wrote:
>
> On Sat, 23 Feb 2019 at 18:26, Jason Thorpe wrote:
>
>> A project I’m working on has a need for a proper “int” size fetch / sto
On Sat, Feb 23, 2019 at 04:40:40PM -0800, Jason Thorpe wrote:
> >> i like this. the current API is ... odd.
> >>
> >> can you add alignment documentation? eg, if only to say that it
> >> must support aligned or unaligned accesses for the relevant
> >> datatypes. not sure what we need curre
> On Feb 24, 2019, at 8:22 AM, David Holland wrote:
>
> Given that the predominant use of these is to fetch from user-supplied
> pointers, which can be crap, it would best to include an alignment
> check; otherwise ~all call sites will require explicit checks, which
> in addition to being error
On Sun, Feb 24, 2019 at 08:39:53AM -0800, Jason Thorpe wrote:
> > Given that the predominant use of these is to fetch from user-supplied
> > pointers, which can be crap, it would best to include an alignment
> > check; otherwise ~all call sites will require explicit checks, which
> > in additio
> On Feb 24, 2019, at 8:42 AM, David Holland wrote:
>
> Given that the alignment check _is_ free on some architectures, and
> that dealing with alignment in machine-independent C is problematic,
> that doesn't seem like the right way…
If we’re concerned about portability of the things using th
On Sat, Feb 23, 2019 at 03:26:34PM -0800, Jason Thorpe 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.
I'm far more inclined to jus
> On Feb 24, 2019, at 9:12 AM, Joerg Sonnenberger wrote:
>
> I'm far more inclined to just want the limited API with as many
> constraints as reasonable, e.g. an atomic 32bit fetch or store and
> that's it. Maybe add 64bit variants, but no more. No point really in
> having a lot of dead weight
> On Feb 24, 2019, at 9:40 AM, Jason Thorpe wrote:
>
> 32-bit on every platform, and 64-bit on LP64 platforms (for pointers).
>
> I’m fine with that, so long as we’re willing to “give up” on the other things
> that use byte / short / in-interrupt.
I will note, however, that some platforms ar
hello. It strikes me that if you've already written the code to fetch
and store 8, 16, 32 and sometimes 64 bit values, it should be committed.
If other OS's have this functionality, then it means applications wil use
it and subsequent porting of such applications to NetBSD will be easier i
> On Feb 24, 2019, at 10:07 AM, Brian Buhrow wrote:
>
> hello. It strikes me that if you've already written the code to fetch
> and store 8, 16, 32 and sometimes 64 bit values, it should be committed.
I am pretty sure most platforms already have the 8- and 16-bit variants, just
under
On Sun, Feb 24, 2019 at 08:47:12AM -0800, Jason Thorpe wrote:
>
> > On Feb 24, 2019, at 8:42 AM, David Holland
> > wrote:
> > Given that the alignment check _is_ free on some architectures, and
> > that dealing with alignment in machine-independent C is problematic,
> > that doesn't seem l
> On Feb 24, 2019, at 10:28 AM, David Holland wrote:
>
> No, even if you know what the alignment's supposed to be, you can't
> legally check it. Or maybe you can, but it's in any event tangled in a
> bunch of language-lawyering.
>
> Also, these days you can expect the compiler to simply remov
Jason Thorpe wrote:
> The existing fetch(9) / store(9) APIs have some problems. Specifically:
>
> ==> Their return semantics mean that fuword() cannot disambiguate between
> an error condition (-1) and a legitimate fetch of -1 from user space.
>
> ==> “word” is poorly defined. For all practica
> On Feb 24, 2019, at 8:26 PM, matthew green wrote:
>
>>> On Feb 23, 2019, at 4:04 PM, matthew green wrote:
>>>
>>> i like this. the current API is ... odd.
>>
>> Oh any thoughts on have intrsafe or not?
>
> if we can get away without it, that would be best. how hard is
> the single(?) c
> On Feb 24, 2019, at 1:42 PM, Mindaugas Rasiukevicius wrote:
>
>> Outstanding question before I go too far down the rabbit hole: should I
>> bother with the “intrsafe” variants? The only application for it in the
>> tree right now is in the profiling code, as an optimization to avoid
>> taki
On Sun, 24 Feb 2019 at 10:38, Jason Thorpe wrote:
>
>
> > On Feb 24, 2019, at 7:05 AM, Andrew Cagney 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
> > On Feb 23, 2019, at 4:04 PM, matthew green wrote:
> >
> > i like this. the current API is ... odd.
>
> Oh any thoughts on have intrsafe or not?
if we can get away without it, that would be best. how hard is
the single(?) caller to fix? :-)
.mrg.
[thorpej]
> 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.
C does not have a `pointer' type; what it has is a `pointer to
OTHER-TYPE' for each type OTHER-TYP
On Sat, 23 Feb 2019, Jason Thorpe wrote:
> int ufetch_8(const uint8_t *uaddr, uint8_t *valp);
> 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);
> #en
On Mon, 25 Feb 2019 at 11:35, Eduardo Horvath wrote:
>
> On Sat, 23 Feb 2019, Jason Thorpe wrote:
>
> > int ufetch_8(const uint8_t *uaddr, uint8_t *valp);
> > int ufetch_16(const uint16_t *uaddr, uint16_t *valp);
> > int ufetch_32(const uint32_t *uaddr, uint32_t *valp);
> > #ifdef _LP6
On Mon, 25 Feb 2019, Andrew Cagney wrote:
> On Mon, 25 Feb 2019 at 11:35, Eduardo Horvath wrote:
> >
> > On Sat, 23 Feb 2019, Jason Thorpe wrote:
> >
> > > int ufetch_8(const uint8_t *uaddr, uint8_t *valp);
> > > int ufetch_16(const uint16_t *uaddr, uint16_t *valp);
> > > int ufetch_3
> On Feb 25, 2019, at 9:18 AM, Andrew Cagney wrote:
>
> So the out-of-band error check becomes the slow memory write?
> I don't see it as a problem as the data would presumably be written to
> the write-back cached's stack (besides, if the function is short, LTO
> will eliminate it).
>
>
> On Feb 24, 2019, at 3:48 PM, Mouse wrote:
>
> C does not have a `pointer' type; what it has is a `pointer to
> OTHER-TYPE' for each type OTHER-TYPE.
>
> On all NetBSD ports I'm aware of, this is a distinction without a
> difference, since all memory is the same and all pointers are just
> m
On Mon 25 Feb 2019 at 18:10:20 +, Eduardo Horvath wrote:
> I'd do something like:
>
> uint64_t ufetch_64(const uint64_t *uaddr, int *errp);
>
> where *errp needs to be initialized to zero and is set on fault so you can
> do:
>
> int err = 0;
> long hisflags = ufetch_64(flag1p, &
On Tue, Feb 26, 2019 at 01:59:42PM +0100, Rhialto wrote:
> On Mon 25 Feb 2019 at 18:10:20 +, Eduardo Horvath wrote:
> > I'd do something like:
> >
> > uint64_t ufetch_64(const uint64_t *uaddr, int *errp);
> >
> > where *errp needs to be initialized to zero and is set on fault so you can
> >
>>> int err = 0;
>>> long hisflags = ufetch_64(flag1p, &err) | ufetch_64(flag2p, &err);
>>> if (err) return EFAULT;
>>> do_something(hisflags);
>> I like this, because it swaps the cost of the value that is always
>> needed (which was expensive) versus the one that isn't expected
> On Feb 26, 2019, at 7:58 AM, Mouse wrote:
>
int err = 0;
long hisflags = ufetch_64(flag1p, &err) | ufetch_64(flag2p, &err);
>
if (err) return EFAULT;
>
do_something(hisflags);
>
>>> I like this, because it swaps the cost of the value that is always
>>> need
> Memory store to initialize error
Heh. Well spotted.
> Itâ??s 2 loads and a store in either case, [...]
...though one does better when there _are_ multiple calls whose error
checks can be collapsed.
> and the second pattern is contrary to just about everything else in
> the kernel.
True, tho
> On Feb 26, 2019, at 9:41 AM, Mouse wrote:
>
>> Memory store to initialize error
>
> Heh. Well spotted.
>
>> Itâ??s 2 loads and a store in either case, [...]
>
> ...though one does better when there _are_ multiple calls whose error
> checks can be collapsed.
...and having personally audit
Jason Thorpe wrote:
> ... whether or not disc
> brakes are appropriate for road racing bicycles.
Having recently converted, the answer is "yes". No debate needed :)
Back to the function names...
Cheers,
Simon.
> On Feb 26, 2019, at 2:03 PM, Simon Burge wrote:
>
> Jason Thorpe wrote:
>
>> ... whether or not disc
>> brakes are appropriate for road racing bicycles.
>
> Having recently converted, the answer is "yes". No debate needed :)
I guess I'm just a luddite, but I do have disc brakes on my tand
Jason Thorpe wrote:
> > Please prefix the size with 'u' if you operate on unsigned types:
> >
> > ufetch_u{8,16,32,64} and the same for ustore_*
>
> Even at the expense of being different from atomic_ops(3)?
>
atomic_ops(3) has atomic_cas_u{int,long}; ufetch_32() vs ufetch_u32()
is less of the
> On Feb 27, 2019, at 3:01 PM, Jason Thorpe wrote:
>
> I've made a bunch of progress on this, so far converting every architecture
> except for ia64 at this point ... I may punt on that and let someone else
> worry about fixing it up (i.e. I'll add stubs that just error out) .. I
> refreshe
On Sat, Feb 23, 2019 at 03:26:34PM -0800, Jason Thorpe 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.
Cool. For completeness'
> On Mar 7, 2019, at 2:59 AM, Klaus Klein wrote:
>
> On Sat, Feb 23, 2019 at 03:26:34PM -0800, Jason Thorpe 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 n
On Thu, Mar 07, 2019 at 10:56:04AM -0800, Jason Thorpe wrote:
>
>
> > On Mar 7, 2019, at 2:59 AM, Klaus Klein wrote:
> >
> > On Sat, Feb 23, 2019 at 03:26:34PM -0800, Jason Thorpe wrote:
> >
> >> A project I’m working on has a need for a proper “int” size fetch / store
> >> on all platforms,
> On Mar 7, 2019, at 11:21 AM, Klaus Klein wrote:
>
>> No, I'm removing the old API completely.
>
> Let me rephrase. :-) Your proposal didn't mention any header file;
> I guess that means it'll remain then.
Oh, yes, :-)
-- thorpej
48 matches
Mail list logo