[PATCH gnumach] Define rpc_vm_size_array_t and rpc_vm_offset_array_t

2023-01-30 Thread Flavio Cruz
When generating stubs, Mig will will take the vm_size_array_t and define the input request struct using rpc_vm_size_t since the size is variable. This will turn cause a mismatch between types (vm_size_t* vs rpc_vm_size_t*). We could also ask Mig to produce a prototype by using rpc_vm_size_t*, howe

Re: [PATCH] Use $(CC) instead of gcc to avoid relying on the host gcc.

2023-01-30 Thread Flávio Cruz
On Mon, Jan 30, 2023 at 6:51 PM Guillem Jover wrote: > On Mon, 2023-01-30 at 12:43:09 +0300, Sergey Bugaev wrote: > > it would be nicer if you explicitly specified what source tree this > > patch is for, for instance: [PATCH glibc] or [PATCH gnumach] instead > > of just [PATCH]. (There is the --s

Re: [PATCH] Use $(CC) instead of gcc to avoid relying on the host gcc.

2023-01-30 Thread Guillem Jover
On Mon, 2023-01-30 at 12:43:09 +0300, Sergey Bugaev wrote: > it would be nicer if you explicitly specified what source tree this > patch is for, for instance: [PATCH glibc] or [PATCH gnumach] instead > of just [PATCH]. (There is the --subject-prefix option in git > format-patch for this.) Right, a

Out of order building

2023-01-30 Thread Ryan Raymond
I think I found a resolvable issue. Still looking into it though. Apparently some things which depend on libstrore/libstore.so are built before it. The solution is to run make libstore and then continue. If this fixes it I'd like to make this the default behavior. What think?

Re: [PATCH] Use $(CC) instead of gcc to avoid relying on the host gcc.

2023-01-30 Thread Samuel Thibault
Applied, thanks! Flavio Cruz, le lun. 30 janv. 2023 02:26:59 -0500, a ecrit: > --- > Makefile.am | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/Makefile.am b/Makefile.am > index 10d030b8..e31a875d 100644 > --- a/Makefile.am > +++ b/Makefile.am > @@ -41,7 +41,7 @@ AM_LDF

Re: [PATCH] Include i386asm.h using i386/i386/i386.asm.h

2023-01-30 Thread Samuel Thibault
Applied, thanks! Flavio Cruz, le lun. 30 janv. 2023 02:22:14 -0500, a ecrit: > If we 1) build for x86_64 and 2) build in a separate directory, we will not > have > -Ii386 (-Ix86_64 instead) hence this file won't be found since it is > autogenerated. > --- > i386/i386at/int_init.c | 2 +- > 1 fi

Re: [PATCH] Add support for x86_64-*-gnu-* targets to build x86_64 gnumach/hurd

2023-01-30 Thread Thomas Schwinge
Hi! On 2023-01-27T21:15:01-0500, Flávio Cruz wrote: > Not sure what happened, but here's the patch as an attachment. Thanks for > your patience. Thanks, that worked. Without any changes now pushed to master branch in commit 5f8950b403f6351f125d8281d2e7430a43e7d125 "Add support for x86_64-*-gnu-

[PATCH v2 3/3] hurd: Implement SHM_ANON

2023-01-30 Thread Sergey Bugaev
This adds a special SHM_ANON value that can be passed into shm_open () in place of a name. When called in this way, shm_open () will create a new anonymous shared memory file. The file will be created in the same way that other shared memory files are created (i.e., under /dev/shm/), except that it

[PATCH v2 2/3] hurd: Implement O_TMPFILE

2023-01-30 Thread Sergey Bugaev
This is a flag that causes open () to create a new, unnamed file in the same filesystem as the given directory. The file descriptor can be simply used in the creating process as a temporary file, or shared with children processes via fork (), or sent over a Unix socket. The file can be left anonymo

[PATCH v2 1/3] hurd: Consolidate file_name_lookup implementation

2023-01-30 Thread Sergey Bugaev
Instead of __file_name_lookup_at delegating to __file_name_lookup in simple cases, make __file_name_lookup_at deal with both cases, and have __file_name_lookup simply wrap __file_name_lookup_at. Signed-off-by: Sergey Bugaev --- hurd/hurdlookup.c | 10 ++ hurd/lookup-at.c | 51 ++

[PATCH v2 0/3] O_TMPFILE and SHM_ANON for the Hurd

2023-01-30 Thread Sergey Bugaev
Changes since v1: - Add forgotten Signed-off-by - Fix a typo (thanks Amos!) - Drop the separate __O_TMPFILE definition Re-tested on i686-gnu, still works. Sergey Bugaev (3): hurd: Consolidate file_name_lookup implementation hurd: Implement O_TMPFILE hurd: Implement SHM_ANON hurd/hurdlooku

Re: [RFC PATCH 2/3] hurd: Implement O_TMPFILE

2023-01-30 Thread Samuel Thibault
Sergey Bugaev, le lun. 30 janv. 2023 12:53:02 +0300, a ecrit: > So should I remove this and just have > > # define O_TMPFILE 0x0080 /* Make a new unnamed file. */ > > ? Yes, I believe we don't need the __ variant. Samuel

Re: [RFC PATCH 2/3] hurd: Implement O_TMPFILE

2023-01-30 Thread Sergey Bugaev
On Mon, Jan 30, 2023 at 2:25 AM Samuel Thibault wrote: > > Hello, > > Sergey Bugaev, le lun. 12 déc. 2022 14:46:35 +0300, a ecrit: > > diff --git a/sysdeps/mach/hurd/bits/fcntl.h b/sysdeps/mach/hurd/bits/fcntl.h > > index 17dcb384..b898a0c5 100644 > > --- a/sysdeps/mach/hurd/bits/fcntl.h > > +++ b

Re: [PATCH] Use $(CC) instead of gcc to avoid relying on the host gcc.

2023-01-30 Thread Sergey Bugaev
A humble meta-suggestion, if I might: it would be nicer if you explicitly specified what source tree this patch is for, for instance: [PATCH glibc] or [PATCH gnumach] instead of just [PATCH]. (There is the --subject-prefix option in git format-patch for this.) This is typically easy to infer by l