Re: RFC: New userspace fetch/store API

2019-03-07 Thread Klaus Klein 
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, 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' sake, I suppose the new API is going to live
> > alongside the old fetch/store API (for the time being) in ?
> 
> 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.


- Klaus

Re: RFC: New userspace fetch/store API

2019-03-07 Thread Klaus Klein 
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' sake, I suppose the new API is going to live
alongside the old fetch/store API (for the time being) in ?


- Klaus

Re: svr4, again

2018-12-18 Thread Klaus Klein 
On Tue, Dec 18, 2018 at 06:20:12PM -, Michael van Elst wrote:
> thor...@me.com (Jason Thorpe) writes:
> 
> > AFAIK, none of our m68k platforms ever had a "native" SVR4.
> 
> http://en.wikipedia.org/wiki/Amiga_Unix

A donation of which is what made COMPAT_SVR4 on m68k possible. :-)
Not that I'd had any particular use for it, let alone anyone else.


- Klaus

Re: swapcontext vs libpthread, round 10

2012-09-05 Thread Klaus Klein 
On Wed, Sep 05, 2012 at 09:08:56AM +, Emmanuel Dreyfus wrote:
 On Wed, Sep 05, 2012 at 04:42:57PM +1000, matthew green wrote:
  the right place to document this is in the source code, not in the
  public documentation.  please move or delete this.

Indeed.

 The flags are documented in source code. However since we named the
 field uc_flags and not _uc_flags, one could expect it to be public
 interface, hence the motivation to state it is not.

You may be reading too much into this.  To shed some light on it,
that structure member got named this way simply because the uc_
prefix is already reserved for ucontext.h use.  No underscores
required, none of the application's business, thus no mention in
ucontext(2) (so why would anyone consider it public?).


- Klaus