Re: [PATCH 3/4] rcutorture/nolibc: add a bit of documentation to explain how to use nolibc

2019-01-01 Thread Paul E. McKenney
On Mon, Dec 31, 2018 at 02:21:36PM -1000, Joey Pabalinas wrote:
> On Mon, Dec 31, 2018 at 12:08:54PM -0800, Paul E. McKenney wrote:
> > On Sat, Dec 29, 2018 at 09:40:20PM -1000, Joey Pabalinas wrote:
> > > On Sun, Dec 30, 2018 at 08:08:46AM +0100, Willy Tarreau wrote:
> > > > Definitely! Same, I won't emit a patch just for this, Paul already 
> > > > queued it.
> > > 
> > > Yeah, not that big a deal :)
> > > 
> > > Reviewed-by: Joey Pabalinas 
> > 
> > But as long as I am rebasing to add the Reviewed-by, might as well
> > update the others.
> > 
> > The English rules for capitalization and lists are baroque and completely
> > unsuited to word processors ("If any list item is longer than one line,
> > capitalize all the items."), but in this case each item has multiple
> > sentences, so it makes sense to capitalize.
> > 
> > Please see below for the updated commit, and thank you all!
> 
> Interesting, I had no idea it was actually that odd, hah.

The horrible thing is the guy that informed me of this had English as
his third or fourth of something like seven languages.  Yet he knew
English better than I ever will.  Worst of all, when I would complain
about some inconsistency, his response was simply "Mr. McKenney, it is
your language, not mine!"  ;-)

Thanx, Paul



Re: [PATCH 3/4] rcutorture/nolibc: add a bit of documentation to explain how to use nolibc

2018-12-31 Thread Joey Pabalinas
On Mon, Dec 31, 2018 at 12:08:54PM -0800, Paul E. McKenney wrote:
> On Sat, Dec 29, 2018 at 09:40:20PM -1000, Joey Pabalinas wrote:
> > On Sun, Dec 30, 2018 at 08:08:46AM +0100, Willy Tarreau wrote:
> > > Definitely! Same, I won't emit a patch just for this, Paul already queued 
> > > it.
> > 
> > Yeah, not that big a deal :)
> > 
> > Reviewed-by: Joey Pabalinas 
> 
> But as long as I am rebasing to add the Reviewed-by, might as well
> update the others.
> 
> The English rules for capitalization and lists are baroque and completely
> unsuited to word processors ("If any list item is longer than one line,
> capitalize all the items."), but in this case each item has multiple
> sentences, so it makes sense to capitalize.
> 
> Please see below for the updated commit, and thank you all!

Interesting, I had no idea it was actually that odd, hah.

> And Happy New Year!!!  ;-)

Glad to help, and happy new year to you as well  :)

-- 
Cheers,
Joey Pabalinas


signature.asc
Description: PGP signature


Re: [PATCH 3/4] rcutorture/nolibc: add a bit of documentation to explain how to use nolibc

2018-12-31 Thread Willy Tarreau
On Mon, Dec 31, 2018 at 12:08:54PM -0800, Paul E. McKenney wrote:
> The English rules for capitalization and lists are baroque and completely
> unsuited to word processors ("If any list item is longer than one line,
> capitalize all the items."), but in this case each item has multiple
> sentences, so it makes sense to capitalize.
> 
> Please see below for the updated commit, and thank you all!

OK, this looks fine to me, thank you Paul!

> And Happy New Year!!!  ;-)

Oh and same to you ;-)

willy


Re: [PATCH 3/4] rcutorture/nolibc: add a bit of documentation to explain how to use nolibc

2018-12-31 Thread Paul E. McKenney
On Sat, Dec 29, 2018 at 09:40:20PM -1000, Joey Pabalinas wrote:
> On Sun, Dec 30, 2018 at 08:08:46AM +0100, Willy Tarreau wrote:
> > Definitely! Same, I won't emit a patch just for this, Paul already queued 
> > it.
> 
> Yeah, not that big a deal :)
> 
> Reviewed-by: Joey Pabalinas 

But as long as I am rebasing to add the Reviewed-by, might as well
update the others.

The English rules for capitalization and lists are baroque and completely
unsuited to word processors ("If any list item is longer than one line,
capitalize all the items."), but in this case each item has multiple
sentences, so it makes sense to capitalize.

Please see below for the updated commit, and thank you all!

And Happy New Year!!!  ;-)

Thanx, Paul



commit c12cd600666874ef43f2c555391dce47fe60fcd9
Author: Willy Tarreau 
Date:   Sat Dec 29 19:02:18 2018 +0100

rcutorture/nolibc: Add a bit of documentation to explain how to use nolibc

Ingo rightfully asked for a bit more documentation in the nolibc header,
so this patch adds some explanation about its purpose, how it's made, and
how to use it.

Cc: Ingo Molnar 
Cc: Paul E. McKenney 
Cc: Randy Dunlap 
Signed-off-by: Willy Tarreau 
Signed-off-by: Paul E. McKenney 
Reviewed-by: Joey Pabalinas 
Reviewed-by: Randy Dunlap 

diff --git a/tools/testing/selftests/rcutorture/bin/nolibc.h 
b/tools/testing/selftests/rcutorture/bin/nolibc.h
index cfbbbad4bca4..1708e9f9f8aa 100644
--- a/tools/testing/selftests/rcutorture/bin/nolibc.h
+++ b/tools/testing/selftests/rcutorture/bin/nolibc.h
@@ -3,7 +3,85 @@
  * Copyright (C) 2017-2018 Willy Tarreau 
  */
 
-/* some archs (at least aarch64) don't expose the regular syscalls anymore by
+/*
+ * This file is designed to be used as a libc alternative for minimal programs
+ * with very limited requirements. It consists of a small number of syscall and
+ * type definitions, and the minimal startup code needed to call main().
+ * All syscalls are declared as static functions so that they can be optimized
+ * away by the compiler when not used.
+ *
+ * Syscalls are split into 3 levels:
+ *   - The lower level is the arch-specific syscall() definition, consisting in
+ * assembly code in compound expressions. These are called my_syscall0() to
+ * my_syscall6() depending on the number of arguments. The MIPS
+ * implementation is limited to 5 arguments. All input arguments are cast
+ * to a long stored in a register. These expressions always return the
+ * syscall's return value as a signed long value which is often either a
+ * pointer or the negated errno value.
+ *
+ *   - The second level is mostly architecture-independent. It is made of
+ * static functions called sys_() which rely on my_syscallN()
+ * depending on the syscall definition. These functions are responsible
+ * for exposing the appropriate types for the syscall arguments (int,
+ * pointers, etc) and for setting the appropriate return type (often int).
+ * A few of them are architecture-specific because the syscalls are not all
+ * mapped exactly the same among architectures. For example, some archs do
+ * not implement select() and need pselect6() instead, so the sys_select()
+ * function will have to abstract this.
+ *
+ *   - The third level is the libc call definition. It exposes the lower raw
+ * sys_() calls in a way that looks like what a libc usually does,
+ * takes care of specific input values, and of setting errno upon error.
+ * There can be minor variations compared to standard libc calls. For
+ * example the open() call always takes 3 args here.
+ *
+ * The errno variable is declared static and unused. This way it can be
+ * optimized away if not used. However this means that a program made of
+ * multiple C files may observe different errno values (one per C file). For
+ * the type of programs this project targets it usually is not a problem. The
+ * resulting program may even be reduced by defining the NOLIBC_IGNORE_ERRNO
+ * macro, in which case the errno value will never be assigned.
+ *
+ * Some stdint-like integer types are defined. These are valid on all currently
+ * supported architectures, because signs are enforced, ints are assumed to be
+ * 32 bits, longs the size of a pointer and long long 64 bits. If more
+ * architectures have to be supported, this may need to be adapted.
+ *
+ * Some macro definitions like the O_* values passed to open(), and some
+ * structures like the sys_stat struct depend on the architecture.
+ *
+ * The definitions start with the architecture-specific parts, which are picked
+ * based on what the compiler knows about the target architecture, and are
+ * completed with the generic code. Since it is the compiler which sets the
+ * target architecture, cross-compiling normally works out of the box 

Re: [PATCH 3/4] rcutorture/nolibc: add a bit of documentation to explain how to use nolibc

2018-12-29 Thread Joey Pabalinas
On Sun, Dec 30, 2018 at 08:08:46AM +0100, Willy Tarreau wrote:
> Definitely! Same, I won't emit a patch just for this, Paul already queued it.

Yeah, not that big a deal :)

Reviewed-by: Joey Pabalinas 

-- 
Cheers,
Joey Pabalinas


signature.asc
Description: PGP signature


Re: [PATCH 3/4] rcutorture/nolibc: add a bit of documentation to explain how to use nolibc

2018-12-29 Thread Willy Tarreau
On Sat, Dec 29, 2018 at 12:33:24PM -1000, Joey Pabalinas wrote:
> On Sat, Dec 29, 2018 at 07:02:18PM +0100, Willy Tarreau wrote:
> > + *   - the lower level is the arch-specific syscall() definition, 
> > consisting in
> > + * assembly code in compound expressions. These are called 
> > my_syscall0() to
> > + * my_syscall6() depending on the number of arguments. The MIPS
> > + * implementation is limited to 5 arguments. All input arguments are 
> > cast
> > + * to a long stored in a register. These expressions always return the
> > + * syscall's return value as a signed long value which is often either 
> > a
> > + * pointer or the negated errno value.
> > + *
> > + *   - the second level is mostly architecture-independent. It is made of
> > + * static functions called sys_() which rely on my_syscallN()
> > + * depending on the syscall definition. These functions are responsible
> > + * for exposing the appropriate types for the syscall arguments (int,
> > + * pointers, etc) and for setting the appropriate return type (often 
> > int).
> > + * A few of them are architecture-specific because the syscalls are 
> > not all
> > + * mapped exactly the same among architectures. For example, some 
> > archs do
> > + * not implement select() and need pselect6() instead, so the 
> > sys_select()
> > + * function will have to abstract this.
> > + *
> > + *   - the third level is the libc call definition. It exposes the lower 
> > raw
> > + * sys_() calls in a way that looks like what a libc usually 
> > does,
> > + * takes care of specific input values, and of setting errno upon 
> > error.
> > + * There can be minor variations compared to standard libc calls. For
> > + * example the open() call always takes 3 args here.
> 
> Shouldn't these sentences begin with a capitalized "The" for
> consistency?

Not sure since they're just list items. But probably as such they should
end with a semi-colon and not a dot. Anyway, this is minor and likely for
a later update to the file.

> >  /* some archs (at least aarch64) don't expose the regular syscalls anymore 
> > by
> >   * default, either because they have an "_at" replacement, or because 
> > there are
> >   * more modern alternatives. For now we'd rather still use them.
> 
> Also here. Shouldn't this begin with a capitalized "Some"?

Definitely! Same, I won't emit a patch just for this, Paul already queued it.

Thanks!
Willy


Re: [PATCH 3/4] rcutorture/nolibc: add a bit of documentation to explain how to use nolibc

2018-12-29 Thread Randy Dunlap
On 12/29/18 10:02 AM, Willy Tarreau wrote:
> Ingo rightfully asked for a bit more documentation in the nolibc header,
> so this patch adds some explanation about its purpose, how it's made, and
> how to use it.
> 
> Cc: Ingo Molnar 
> Cc: Paul E. McKenney 
> Cc: Randy Dunlap 
> Signed-off-by: Willy Tarreau 

Reviewed-by: Randy Dunlap 

Thanks.

> ---
>  tools/testing/selftests/rcutorture/bin/nolibc.h | 90 
> +
>  1 file changed, 78 insertions(+), 12 deletions(-)
> 
> diff --git a/tools/testing/selftests/rcutorture/bin/nolibc.h 
> b/tools/testing/selftests/rcutorture/bin/nolibc.h
> index 985364c..6643ba9 100644
> --- a/tools/testing/selftests/rcutorture/bin/nolibc.h
> +++ b/tools/testing/selftests/rcutorture/bin/nolibc.h
> @@ -3,6 +3,84 @@
>   * Copyright (C) 2017-2018 Willy Tarreau 
>   */
>  
> +/*
> + * This file is designed to be used as a libc alternative for minimal 
> programs
> + * with very limited requirements. It consists of a small number of syscall 
> and
> + * type definitions, and the minimal startup code needed to call main().
> + * All syscalls are declared as static functions so that they can be 
> optimized
> + * away by the compiler when not used.
> + *
> + * Syscalls are split into 3 levels:
> + *   - the lower level is the arch-specific syscall() definition, consisting 
> in
> + * assembly code in compound expressions. These are called my_syscall0() 
> to
> + * my_syscall6() depending on the number of arguments. The MIPS
> + * implementation is limited to 5 arguments. All input arguments are cast
> + * to a long stored in a register. These expressions always return the
> + * syscall's return value as a signed long value which is often either a
> + * pointer or the negated errno value.
> + *
> + *   - the second level is mostly architecture-independent. It is made of
> + * static functions called sys_() which rely on my_syscallN()
> + * depending on the syscall definition. These functions are responsible
> + * for exposing the appropriate types for the syscall arguments (int,
> + * pointers, etc) and for setting the appropriate return type (often 
> int).
> + * A few of them are architecture-specific because the syscalls are not 
> all
> + * mapped exactly the same among architectures. For example, some archs 
> do
> + * not implement select() and need pselect6() instead, so the 
> sys_select()
> + * function will have to abstract this.
> + *
> + *   - the third level is the libc call definition. It exposes the lower raw
> + * sys_() calls in a way that looks like what a libc usually does,
> + * takes care of specific input values, and of setting errno upon error.
> + * There can be minor variations compared to standard libc calls. For
> + * example the open() call always takes 3 args here.
> + *
> + * The errno variable is declared static and unused. This way it can be
> + * optimized away if not used. However this means that a program made of
> + * multiple C files may observe different errno values (one per C file). For
> + * the type of programs this project targets it usually is not a problem. The
> + * resulting program may even be reduced by defining the NOLIBC_IGNORE_ERRNO
> + * macro, in which case the errno value will never be assigned.
> + *
> + * Some stdint-like integer types are defined. These are valid on all 
> currently
> + * supported architectures, because signs are enforced, ints are assumed to 
> be
> + * 32 bits, longs the size of a pointer and long long 64 bits. If more
> + * architectures have to be supported, this may need to be adapted.
> + *
> + * Some macro definitions like the O_* values passed to open(), and some
> + * structures like the sys_stat struct depend on the architecture.
> + *
> + * The definitions start with the architecture-specific parts, which are 
> picked
> + * based on what the compiler knows about the target architecture, and are
> + * completed with the generic code. Since it is the compiler which sets the
> + * target architecture, cross-compiling normally works out of the box without
> + * having to specify anything.
> + *
> + * Finally some very common libc-level functions are provided. It is the case
> + * for a few functions usually found in string.h, ctype.h, or stdlib.h. 
> Nothing
> + * is currently provided regarding stdio emulation.
> + *
> + * The macro NOLIBC is always defined, so that it is possible for a program 
> to
> + * check this macro to know if it is being built against and decide to 
> disable
> + * some features or simply not to include some standard libc files.
> + *
> + * Ideally this file should be split in multiple files for easier long term
> + * maintenance, but provided as a single file as it is now, it's quite
> + * convenient to use. Maybe some variations involving a set of includes at 
> the
> + * top could work.
> + *
> + * A simple static executable may be built this way :
> + *  $ gcc 

Re: [PATCH 3/4] rcutorture/nolibc: add a bit of documentation to explain how to use nolibc

2018-12-29 Thread Joey Pabalinas
On Sat, Dec 29, 2018 at 07:02:18PM +0100, Willy Tarreau wrote:
> + *   - the lower level is the arch-specific syscall() definition, consisting 
> in
> + * assembly code in compound expressions. These are called my_syscall0() 
> to
> + * my_syscall6() depending on the number of arguments. The MIPS
> + * implementation is limited to 5 arguments. All input arguments are cast
> + * to a long stored in a register. These expressions always return the
> + * syscall's return value as a signed long value which is often either a
> + * pointer or the negated errno value.
> + *
> + *   - the second level is mostly architecture-independent. It is made of
> + * static functions called sys_() which rely on my_syscallN()
> + * depending on the syscall definition. These functions are responsible
> + * for exposing the appropriate types for the syscall arguments (int,
> + * pointers, etc) and for setting the appropriate return type (often 
> int).
> + * A few of them are architecture-specific because the syscalls are not 
> all
> + * mapped exactly the same among architectures. For example, some archs 
> do
> + * not implement select() and need pselect6() instead, so the 
> sys_select()
> + * function will have to abstract this.
> + *
> + *   - the third level is the libc call definition. It exposes the lower raw
> + * sys_() calls in a way that looks like what a libc usually does,
> + * takes care of specific input values, and of setting errno upon error.
> + * There can be minor variations compared to standard libc calls. For
> + * example the open() call always takes 3 args here.

Shouldn't these sentences begin with a capitalized "The" for
consistency?

>  /* some archs (at least aarch64) don't expose the regular syscalls anymore by
>   * default, either because they have an "_at" replacement, or because there 
> are
>   * more modern alternatives. For now we'd rather still use them.

Also here. Shouldn't this begin with a capitalized "Some"?

-- 
Cheers,
Joey Pabalinas


signature.asc
Description: PGP signature


[PATCH 3/4] rcutorture/nolibc: add a bit of documentation to explain how to use nolibc

2018-12-29 Thread Willy Tarreau
Ingo rightfully asked for a bit more documentation in the nolibc header,
so this patch adds some explanation about its purpose, how it's made, and
how to use it.

Cc: Ingo Molnar 
Cc: Paul E. McKenney 
Cc: Randy Dunlap 
Signed-off-by: Willy Tarreau 
---
 tools/testing/selftests/rcutorture/bin/nolibc.h | 90 +
 1 file changed, 78 insertions(+), 12 deletions(-)

diff --git a/tools/testing/selftests/rcutorture/bin/nolibc.h 
b/tools/testing/selftests/rcutorture/bin/nolibc.h
index 985364c..6643ba9 100644
--- a/tools/testing/selftests/rcutorture/bin/nolibc.h
+++ b/tools/testing/selftests/rcutorture/bin/nolibc.h
@@ -3,6 +3,84 @@
  * Copyright (C) 2017-2018 Willy Tarreau 
  */
 
+/*
+ * This file is designed to be used as a libc alternative for minimal programs
+ * with very limited requirements. It consists of a small number of syscall and
+ * type definitions, and the minimal startup code needed to call main().
+ * All syscalls are declared as static functions so that they can be optimized
+ * away by the compiler when not used.
+ *
+ * Syscalls are split into 3 levels:
+ *   - the lower level is the arch-specific syscall() definition, consisting in
+ * assembly code in compound expressions. These are called my_syscall0() to
+ * my_syscall6() depending on the number of arguments. The MIPS
+ * implementation is limited to 5 arguments. All input arguments are cast
+ * to a long stored in a register. These expressions always return the
+ * syscall's return value as a signed long value which is often either a
+ * pointer or the negated errno value.
+ *
+ *   - the second level is mostly architecture-independent. It is made of
+ * static functions called sys_() which rely on my_syscallN()
+ * depending on the syscall definition. These functions are responsible
+ * for exposing the appropriate types for the syscall arguments (int,
+ * pointers, etc) and for setting the appropriate return type (often int).
+ * A few of them are architecture-specific because the syscalls are not all
+ * mapped exactly the same among architectures. For example, some archs do
+ * not implement select() and need pselect6() instead, so the sys_select()
+ * function will have to abstract this.
+ *
+ *   - the third level is the libc call definition. It exposes the lower raw
+ * sys_() calls in a way that looks like what a libc usually does,
+ * takes care of specific input values, and of setting errno upon error.
+ * There can be minor variations compared to standard libc calls. For
+ * example the open() call always takes 3 args here.
+ *
+ * The errno variable is declared static and unused. This way it can be
+ * optimized away if not used. However this means that a program made of
+ * multiple C files may observe different errno values (one per C file). For
+ * the type of programs this project targets it usually is not a problem. The
+ * resulting program may even be reduced by defining the NOLIBC_IGNORE_ERRNO
+ * macro, in which case the errno value will never be assigned.
+ *
+ * Some stdint-like integer types are defined. These are valid on all currently
+ * supported architectures, because signs are enforced, ints are assumed to be
+ * 32 bits, longs the size of a pointer and long long 64 bits. If more
+ * architectures have to be supported, this may need to be adapted.
+ *
+ * Some macro definitions like the O_* values passed to open(), and some
+ * structures like the sys_stat struct depend on the architecture.
+ *
+ * The definitions start with the architecture-specific parts, which are picked
+ * based on what the compiler knows about the target architecture, and are
+ * completed with the generic code. Since it is the compiler which sets the
+ * target architecture, cross-compiling normally works out of the box without
+ * having to specify anything.
+ *
+ * Finally some very common libc-level functions are provided. It is the case
+ * for a few functions usually found in string.h, ctype.h, or stdlib.h. Nothing
+ * is currently provided regarding stdio emulation.
+ *
+ * The macro NOLIBC is always defined, so that it is possible for a program to
+ * check this macro to know if it is being built against and decide to disable
+ * some features or simply not to include some standard libc files.
+ *
+ * Ideally this file should be split in multiple files for easier long term
+ * maintenance, but provided as a single file as it is now, it's quite
+ * convenient to use. Maybe some variations involving a set of includes at the
+ * top could work.
+ *
+ * A simple static executable may be built this way :
+ *  $ gcc -fno-asynchronous-unwind-tables -fno-ident -s -Os -nostdlib \
+ *-static -include nolibc.h -lgcc -o hello hello.c
+ *
+ * A very useful calling convention table may be found here :
+ *  http://man7.org/linux/man-pages/man2/syscall.2.html
+ *
+ * This doc is quite convenient though not necessarily up to date :
+