On Wed, Dec 5, 2018 at 1:55 PM Florian Weimer <fweimer@redhat.com> wrote:
>
> * H. J. Lu:
>
> > +@node Process Information
> > +@section Process Information
>
> I'm not sure if this is the right place.  This is specifically not a
> process attribute, after all.  Perhaps it will fit better into the
> discussion of scheduling-related functionality?

I moved it to manual/resource.texi.

> > +@deftypefun int getcpu (unsigned int *cpu, unsigned int *node)
> > +@standards{Linux, <sched.h>}
> > +@safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
>
> Can we unwind through vsyscalls?  If not, the function is not AC-safe.

Yes, see:

https://bugzilla.kernel.org/show_bug.cgi?id=201741

> > +The @code{getcpu} function identifies the processor and node on which
> > +the calling thread or process is currently running and writes them into
> > +the integers pointed to by the @var{cpu} and @var{node} arguments.  The
> > +processor is a unique small integer identifying a CPU.  The node is a
>
> “small nonnegative integer”

I changed it to "nonnegative integer” .

> > +unique small identifier identifying a NUMA node.  When either @var{cpu}
>
> “small nonnegative integer” (not “identifier”)

I changed it to "nonnegative integer” .

> > +or @var{node} is @code{NULL}, nothing is written to the respective
> > +pointer.
>
> Should we add a caveat that due to CPU hotplugging, the values might not
> be so small after a while?

I removed "small".

> > +The return value is @code{0} on success and @code{-1} on failure.  The
> > +following @code{errno} error condition is defined for this function:
> > +
> > +@table @code
> > +@item EFAULT
> > +Arguments point outside the calling process's address space.
> > +@end table
> > +@end deftypefun
>
> I don't think the vsyscall can detect the EFAULT error condition
> reliably.  Should we really document it?

Removed.

> What about ENOSYS?  Is this system call really supported on all
> architectures?

Added.

OK for master?

Thanks.

-- 
H.J.