[PATCH mig] Update code generation to handle the new 64 bit ABI

Mostly, we don't set the fields that do not exist and avoid type mismatching (like casting unsigned short to unsigned char for msgt_name). We also revamp type checking to compare mach_msg_type_t to uint64_t instead of just uint32_t as we now use the whole structure. --- global.h | 2 ++ utils.c

[PATCH gnumach] Update the 64bit RPC ABI to be simpler

* Make full use of the 8 bytes available in mach_msg_type_t by moving into the unused 4 bytes. This allows us to use 32bits for mach_msg_type_number_t whether we use the longform or not. * Make mach_msg_type_long_t exactly the same as mach_msg_type_t. I'm not changing any of the code but keep

[PATCH gnumach] Fix task_info for TASK_THREAD_TIMES_INFO.

We are checking for the existence of time_value64_t but we didn't add that to the task_thread_times_info structure. --- include/mach/task_info.h | 6 ++ kern/task.c | 8 +++- 2 files changed, 13 insertions(+), 1 deletion(-) diff --git a/include/mach/task_info.h b/include/mach

[PATCH glibc] Use TASK_THREAD_TIMES_INFO_COUNT when calling task_info with TASK_THREAD_TIMES_INFO

This hasn't caused any problems yet but we are passing a pointer to struct task_thread_times_info which can cause problems if we populate over the existing size of the struct. --- sysdeps/mach/clock_gettime.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sysdeps/mach/clock_ge

Re: [PATCH glibc] Stop checking if MiG supports retcode.

On Tue, May 16, 2023 at 6:02 PM Flávio Cruz wrote: > Yes, I meant this when I said "generate code to call the server reply routine > in case of errors". Ah, I see. > Take the example of the term translator, it forces TypeCheck to be 0 so that > it can still receive replies in the error case (oth

Re: [PATCH glibc] Stop checking if MiG supports retcode.

On Mon, May 15, 2023 at 2:19 AM Sergey Bugaev wrote: > Hi, > > On Mon, May 15, 2023 at 7:09 AM Flávio Cruz wrote: > > If we want > > ./configure to check if MiG generates code to call the server reply > routine > > in case of errors (it doesn't :() then we will need to build a different > check.

Re: ***UNCHECKED*** Re: [PATCH 0/3] Rumpkernel in GNU Guix

Janneke Nieuwenhuizen, le mar. 16 mai 2023 14:04:38 +0200, a ecrit: > variants, but in the Guix build only ext2fs.static got built. As I > couldn't find any reference to how building ex2fs.static was triggered, > I ignored it... > > Also, until recently Guix simply used /hurd/ext2fs, but that fai

Re: ***UNCHECKED*** Re: [PATCH 0/3] Rumpkernel in GNU Guix

Samuel Thibault writes: Hi, > Janneke Nieuwenhuizen, le mar. 16 mai 2023 14:04:38 +0200, a ecrit: >> Sergey Bugaev writes: >> > * you probably need acpi in there too, before rumpdisk? > > It's not a requirement: if acpi is not available libpciaccess will just > use legacy IRQ routing, which shoul

Re: [PATCH 0/3] Rumpkernel in GNU Guix

Janneke Nieuwenhuizen, le mar. 16 mai 2023 14:40:49 +0200, a ecrit: > > I have applied your patches, thanks! > > Great...updating source in Guix right away to simplify our > packaging...and found a silly typo, sorry! Fix attached. Applied, thanks! Samuel

Re: ***UNCHECKED*** Re: [PATCH 0/3] Rumpkernel in GNU Guix

Hello, Janneke Nieuwenhuizen, le mar. 16 mai 2023 14:04:38 +0200, a ecrit: > Sergey Bugaev writes: > > * you probably need acpi in there too, before rumpdisk? It's not a requirement: if acpi is not available libpciaccess will just use legacy IRQ routing, which should be working quite fine. > Als

Re: [PATCH 0/3] Rumpkernel in GNU Guix

Samuel Thibault writes: Hi Samuel, > Janneke Nieuwenhuizen, le mar. 16 mai 2023 10:57:47 +0200, a ecrit: [..] > I have applied your patches, thanks! Great...updating source in Guix right away to simplify our packaging...and found a silly typo, sorry! Fix attached. Greetings, Janneke >From 5

Re: [PATCH 0/3] Rumpkernel in GNU Guix

Sergey Bugaev writes: Hello, > On Tue, May 16, 2023 at 11:58 AM Janneke Nieuwenhuizen > wrote: >> Sadly when actually using them booting hangs: >> >> start: pci.arbiter: >> >> So, yeah. To be continued. > > Not that I know anything about any of this, but: > > * why are you passing --store-

Re: [PATCH 0/3] Rumpkernel in GNU Guix

Hello, Janneke Nieuwenhuizen, le mar. 16 mai 2023 10:57:47 +0200, a ecrit: > Recently, Josselin Poiret updated the (gnumach, etc. and) Hurd > packages[0] and two days ago we managed to get this new version to > boot[1]! \o/ \o/ > This opened the way for us to have another look at include the > r

Re: [PATCH 0/3] Rumpkernel in GNU Guix

Hi, On Tue, May 16, 2023 at 11:58 AM Janneke Nieuwenhuizen wrote: > Sadly when actually using them booting hangs: > > start: pci.arbiter: > > So, yeah. To be continued. Not that I know anything about any of this, but: * why are you passing --store-type=typed to pci-arbiter? (Bad copy-pas

[PATCH 2/3] crossbuild: Cater for non-FHS shell.

* debian/patches/non-fhs-shell: New file. * debian/patches/series: Add it. --- debian/patches/non-fhs-shell | 37 debian/patches/series| 1 + 2 files changed, 38 insertions(+) create mode 100644 debian/patches/non-fhs-shell diff --git a/debian/patche

[PATCH 3/3] acpi: Cater for cross-mig.

* debian/patches/acpi.diff: Introduce MIG variable so that it may be overridden to -mig. --- debian/patches/acpi.diff | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/debian/patches/acpi.diff b/debian/patches/acpi.diff index 8015a6e63..8e359b2c0 100644 --- a/debian/patches/

[PATCH 0/3] Rumpkernel in GNU Guix

Hi! Recently, Josselin Poiret updated the (gnumach, etc. and) Hurd packages[0] and two days ago we managed to get this new version to boot[1]! \o/ This opened the way for us to have another look at include the rumpkernel. AFAIU there isn't really an upstream (yet) for this, I have used/treated t

[PATCH 1/3] Fix cross-build for non-multiarch toolchains.

* debian/patches/crossbuild: Also respect triplet on AR, MIG and NM. --- debian/patches/crossbuild | 55 ++- 1 file changed, 49 insertions(+), 6 deletions(-) diff --git a/debian/patches/crossbuild b/debian/patches/crossbuild index 779360306..6185b9fcf 100644 --