[PATCH gnumach] Add TIME_VALUE64_TO_TIMESPEC and TIMESPEC_TO_TIME_VALUE64

2023-02-20 Thread Flavio Cruz
We can use these in userland with the new time_value64_t struct. --- include/mach/time_value.h | 12 1 file changed, 12 insertions(+) diff --git a/include/mach/time_value.h b/include/mach/time_value.h index 2984e88c..0643b740 100644 --- a/include/mach/time_value.h +++ b/include/mach/

Re: [PATCH mig] Stop including mach/msg_type.h in generated code.

2023-02-20 Thread Samuel Thibault
Applied, thanks! Flavio Cruz, le dim. 19 févr. 2023 18:49:00 -0500, a ecrit: > File is not needed. > --- > user.c | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/user.c b/user.c > index de3f58c..dc9e21f 100644 > --- a/user.c > +++ b/user.c > @@ -89,7 +89,6 @@ WriteIncludes(FILE *file) >

Re: [PATCH gnumach] Delete include/mach/msg_type.h

2023-02-20 Thread Samuel Thibault
Applied, thanks! Flavio Cruz, le dim. 19 févr. 2023 18:49:25 -0500, a ecrit: > File is not included anywhere. > --- > Makefrag.am | 1 - > include/mach/msg_type.h | 42 - > 2 files changed, 43 deletions(-) > delete mode 100644 include/mach/msg

Re: [RFC PATCH 7/9] hurd: Generalize init-first.c to support x86_64

2023-02-20 Thread Noah Goldstein
On Sat, Feb 18, 2023 at 2:40 PM Sergey Bugaev via Libc-alpha wrote: > > Signed-off-by: Sergey Bugaev > --- > sysdeps/mach/hurd/{i386 => x86}/init-first.c | 17 ++--- > 1 file changed, 14 insertions(+), 3 deletions(-) > rename sysdeps/mach/hurd/{i386 => x86}/init-first.c (96%) > > di

Re: [RFC PATCH 7/9] hurd: Generalize init-first.c to support x86_64

2023-02-20 Thread Samuel Thibault
Sergey Bugaev, le lun. 20 févr. 2023 20:10:29 +0300, a ecrit: > - the implementation does not seem to actually switch stacks (in fact, > I have removed the unused switch_stacks function in the last commit) > -- so the "gets called with the stack just as the application's entry > point will see it"

Re: [RFC PATCH 7/9] hurd: Generalize init-first.c to support x86_64

2023-02-20 Thread Sergey Bugaev
> I wish I had a better understanding of just what's going on in this > file. Maybe a lot of the hacks can be rewritten in a nicer way. For > instance, do we really need to hijack the return addresses and jump to > init1 in this weird way, only to enable it to access argc/arg0? Since > we know wher

Re: [RFC PATCH 7/9] hurd: Generalize init-first.c to support x86_64

2023-02-20 Thread Sergey Bugaev
On Mon, Feb 20, 2023 at 3:01 AM Samuel Thibault wrote: > That won't work on x86_64: there, arguments are passed mostly through > registers, so &argc won't actually give you the address of arguments on > the stack. Right, good point. I wish I had a better understanding of just what's going on in