On Sun, Feb 24, 2019, 11:33 AM David Holland
wrote:
> On Sat, Feb 23, 2019 at 02:05:39PM -0700, Warner Losh wrote:
> > On Sat, Feb 23, 2019 at 12:40 PM David Holland <
> dholland-t...@netbsd.org>
> > wrote:
> >
> > > Do we have docs for the object nandemulator is supposed to be
> > >
[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 Sat, Feb 23, 2019 at 02:05:39PM -0700, Warner Losh wrote:
> On Sat, Feb 23, 2019 at 12:40 PM David Holland
> wrote:
>
> > Do we have docs for the object nandemulator is supposed to be
> > emulating? Some questions have arisen about how complete it is and
> > nobody I've talked to seems
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,
20 matches
Mail list logo
