> 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
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 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
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 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
>
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
> 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
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 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
> 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,
> On Feb 26, 2019, at 7:58 AM, Mouse wrote:
>
int err = 0;
long hisflags = ufetch_64(flag1p, ) | ufetch_64(flag2p, );
>
if (err) return EFAULT;
>
do_something(hisflags);
>
>>> I like this, because it swaps the cost of the value that is always
>>> needed
>>> int err = 0;
>>> long hisflags = ufetch_64(flag1p, ) | ufetch_64(flag2p, );
>>> 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 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
> >
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 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
>
> 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 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
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
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);
>
[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
> > 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.
> 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
>>
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 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(?)
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
> 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
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
> 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
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
> 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
> 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
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
[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 /
> 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
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
> 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
> 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,
> 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
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 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
>>
> 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
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
43 matches
Mail list logo
