Sergey Bugaev, le lun. 15 mai 2023 20:51:54 +0300, a ecrit:
> store (= rumpdisk, not ramdisk) and nano? :)
FI nano is now available as debian-amd64 package since a few days :)
Samuel
On May 15, 2023 7:51:54 PM GMT+02:00, Sergey Bugaev wrote:
>On Mon, May 15, 2023 at 7:28 PM Guy-Fleury Iteriteka
> wrote:
>> Yes, i know that. I fallow you on mastodon.
>
>Then you get to see all the shitposts :D
>
All posts yes :)
>> Also as you are good in writing you can documents how you
On Mon, May 15, 2023 at 7:28 PM Guy-Fleury Iteriteka
wrote:
> Yes, i know that. I fallow you on mastodon.
Then you get to see all the shitposts :D
> Also as you are good in writing you can documents how you created and launch
> it but when you finished your great work
Ah, :blush: thank you
On May 15, 2023 6:45:40 PM GMT+02:00, Samuel Thibault
wrote:
>Guy-Fleury Iteriteka, le lun. 15 mai 2023 18:28:36 +0200, a ecrit:
>> It should be interesting to use flavio's script.
>
>I don't think Flavio aims to bootstrap various libraries and whatnot :)
>
I meant to test just the hurd core
Sergey Bugaev writes:
> On Mon, May 15, 2023 at 6:12 PM Guy-Fleury Iteriteka
> wrote:
>> On May 15, 2023 4:38:34 PM GMT+02:00, "jbra...@dismail.de"
>> wrote:
>> >+As of May 2023, the Hurd developers have a bootable 64-bit Debian
>> Are sure a debian hurd boot??
>
> I'm rather sure some patches
On 15/05/23 13:27, Samuel Thibault via Libc-alpha wrote:
> Applied, thanks!
>
> Sergey Bugaev via Libc-alpha, le lun. 15 mai 2023 11:33:20 +0300, a ecrit:
>> Fixes 60f9bf974694d50daf58d46347b06a5975ac5ddd
>> "hurd: Port trampoline.c to x86_64"
>>
>> Checked on x86_64-gnu.
>>
>> Reported-by:
Sergey Bugaev wrote:
> Looking at [0]: 'int code' should be 'long code', otherwise you won't
> be able to extract the full 64-bit address from it.
Good point, thanks! I've changed libsigsegv and gnulib accordingly.
> I don't know how
> this works out for the BSDs -- maybe they just don't pass
Sergey Bugaev wrote:
> state->basic is the Mach i386_thread_state structure; the
> signal handling machinery first initializes it using thread_get_state
> ()) to describe the state that the thread had at the time it was
> interrupted. It then initializes the sigcontext based on this state
>
I committed:
> 2023-05-12 Bruno Haible
>
> sigsegv: Add tentative support for Hurd/x86_64.
> Reported by Samuel Thibault .
> * lib/sigsegv.c: Update from libsigsegv/src/fault-hurd-i386.h.
This was not sufficient. Sergey Bugaev pointed out that
- my comments were wrong,
-
Sergey Bugaev, le sam. 13 mai 2023 20:45:35 +0300, a ecrit:
> On Sat, May 13, 2023 at 7:38 PM jbra...@dismail.de wrote:
> > +Hurd developers are adding 64-bit support, and they plan to drop the
> > +32-bit support, once the 64-bit support is deemed stable.
>
> Is this really the plan? :(
No,
applied, thanks!
pasha (biblio), le dim. 14 mai 2023 10:02:31 +0200, a ecrit:
> ---
> hurd/building.mdwn | 6 ++
> microkernel/mach/gnumach/debugging.mdwn | 14 --
> 2 files changed, 14 insertions(+), 6 deletions(-)
>
> diff --git a/hurd/building.mdwn
Guy-Fleury Iteriteka, le lun. 15 mai 2023 18:28:36 +0200, a ecrit:
> It should be interesting to use flavio's script.
I don't think Flavio aims to bootstrap various libraries and whatnot :)
Samuel
Applied, thanks!
Sergey Bugaev, le lun. 15 mai 2023 10:36:00 +0300, a ecrit:
> ---
> proc/msg.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/proc/msg.c b/proc/msg.c
> index 25ce0d5b..93ad995b 100644
> --- a/proc/msg.c
> +++ b/proc/msg.c
> @@ -80,7 +80,7 @@
Applied, thanks!
Sergey Bugaev, le lun. 15 mai 2023 10:35:59 +0300, a ecrit:
> Normally glibc does not buffer tty output, but a devstream backed by
> the Mach console device cannot be isatty'ed. So we need to ask glibc
> explicitly to not buffer it. This is what the startup and mach-defpager
> do
This was already fixed :)
Sergey Bugaev, le lun. 15 mai 2023 10:35:58 +0300, a ecrit:
> This fixes a proc server crash during startup inside
> initialize_version_info ().
> ---
> proc/cpu-types.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/proc/cpu-types.c b/proc/cpu-types.c
>
Applied, thanks!
Sergey Bugaev, le lun. 15 mai 2023 10:35:57 +0300, a ecrit:
> Since we don't support mixing i386 and x86_64 binaries on the same
> system (as running them requires different build-time gnumach
> configurations), the exec server can simply require the binary being
> loaded to have
Applied, thanks!
Sergey Bugaev, le lun. 15 mai 2023 10:44:34 +0300, a ecrit:
> Fixes 31dd30a94a682955c3c9e2f42252b4a07687067a "add setting gs/fsbase".
> ---
> This was breaking fork () in glibc when it tried to set up TLS in the
> new process by copying fs_base from an existing thread.
>
>
Applied, thanks!
Sergey Bugaev, le lun. 15 mai 2023 11:33:23 +0300, a ecrit:
> Fixes b574ae0a2876ee94e4fe617f878407bf818c2df0
> "hurd: Implement sigreturn for x86_64"
>
> Checked on x86_64-gnu.
>
> Signed-off-by: Sergey Bugaev
> ---
> sysdeps/mach/hurd/x86_64/sigreturn.c | 2 +-
> 1 file
Applied, thanks!
Sergey Bugaev, le lun. 15 mai 2023 11:33:22 +0300, a ecrit:
> The real i386_thread_state Mach structure has an alignment of 8 on
> x86_64. However, in struct sigcontext, the compiler was packing sc_gs
> (which is the first member of sc_i386_thread_state) into the same 8-byte
>
Applied, thanks!
Sergey Bugaev via Libc-alpha, le lun. 15 mai 2023 11:33:20 +0300, a ecrit:
> Fixes 60f9bf974694d50daf58d46347b06a5975ac5ddd
> "hurd: Port trampoline.c to x86_64"
>
> Checked on x86_64-gnu.
>
> Reported-by: Bruno Haible
> Signed-off-by: Sergey Bugaev
> ---
>
On May 15, 2023 5:58:12 PM GMT+02:00, Sergey Bugaev wrote:
>On Mon, May 15, 2023 at 6:12 PM Guy-Fleury Iteriteka
> wrote:
>> On May 15, 2023 4:38:34 PM GMT+02:00, "jbra...@dismail.de"
>> wrote:
>> >+As of May 2023, the Hurd developers have a bootable 64-bit Debian
>> Are sure a debian hurd
Applied, thanks!
Sergey Bugaev via Libc-alpha, le lun. 15 mai 2023 11:33:21 +0300, a ecrit:
> sizeof (*stackframe) appears to be divisible by 16, but we should not
> rely on that. So make sure to leave enough space for the stackframe
> first, and then align the final pointer at 16 bytes.
>
>
I applied the series, thanks!
jbra...@dismail.de, le lun. 15 mai 2023 11:34:53 -0400, a ecrit:
> ---
> We have no interest in supporting Upstart since it it a dead project.
>
> open_issues/Upstart.mdwn | 69
> 1 file changed, 69 deletions(-)
> delete
On Mon, May 15, 2023 at 6:12 PM Guy-Fleury Iteriteka
wrote:
> On May 15, 2023 4:38:34 PM GMT+02:00, "jbra...@dismail.de"
> wrote:
> >+As of May 2023, the Hurd developers have a bootable 64-bit Debian
> Are sure a debian hurd boot??
I'm rather sure some patches required to get anything serious
Guy-Fleury Iteriteka writes:
> On May 15, 2023 4:38:34 PM GMT+02:00, "jbra...@dismail.de"
> wrote:
>>---
>>I explained that the Hurd has initial 64-bit support, but I
>>did not mention if the project plans to drop 32-bit
>>support. Joshua
>>
>> faq/64-bit.mdwn | 10 +++---
>>
---
.../sync_but_still_unclean_filesystem.mdwn| 39 ---
1 file changed, 39 deletions(-)
delete mode 100644 open_issues/sync_but_still_unclean_filesystem.mdwn
diff --git a/open_issues/sync_but_still_unclean_filesystem.mdwn
b/open_issues/sync_but_still_unclean_filesystem.mdwn
---
...omatic_backtraces_when_assertions_hit.mdwn | 79 ---
1 file changed, 79 deletions(-)
delete mode 100644 open_issues/automatic_backtraces_when_assertions_hit.mdwn
diff --git a/open_issues/automatic_backtraces_when_assertions_hit.mdwn
---
open_issues/exec.mdwn | 84 ---
1 file changed, 84 deletions(-)
delete mode 100644 open_issues/exec.mdwn
diff --git a/open_issues/exec.mdwn b/open_issues/exec.mdwn
deleted file mode 100644
index 05deaa7a..
--- a/open_issues/exec.mdwn
+++
---
open_issues/exec_memory_leaks.mdwn | 121 -
1 file changed, 121 deletions(-)
delete mode 100644 open_issues/exec_memory_leaks.mdwn
diff --git a/open_issues/exec_memory_leaks.mdwn
b/open_issues/exec_memory_leaks.mdwn
deleted file mode 100644
index
---
We have no interest in supporting Upstart since it it a dead project.
open_issues/Upstart.mdwn | 69
1 file changed, 69 deletions(-)
delete mode 100644 open_issues/Upstart.mdwn
diff --git a/open_issues/Upstart.mdwn b/open_issues/Upstart.mdwn
deleted
On May 15, 2023 4:38:34 PM GMT+02:00, "jbra...@dismail.de"
wrote:
>---
>I explained that the Hurd has initial 64-bit support, but I
>did not mention if the project plans to drop 32-bit
>support. Joshua
>
> faq/64-bit.mdwn | 10 +++---
> open_issues/64-bit_port.mdwn | 6 +-
---
I explained that the Hurd has initial 64-bit support, but I
did not mention if the project plans to drop 32-bit
support. Joshua
faq/64-bit.mdwn | 10 +++---
open_issues/64-bit_port.mdwn | 6 +-
2 files changed, 4 insertions(+), 12 deletions(-)
diff --git
sizeof (*stackframe) appears to be divisible by 16, but we should not
rely on that. So make sure to leave enough space for the stackframe
first, and then align the final pointer at 16 bytes.
Checked on x86_64-gnu.
Signed-off-by: Sergey Bugaev
---
sysdeps/mach/hurd/x86/trampoline.c | 5 ++---
1
Hello,
now that we got enough of the system running on x86_64-gnu, we can
actually test the signal machinery. In fact we sort of *have to*,
because /bin/sh receives SIGCHLD when a command completes, and wants
to handle it.
Suprisingly, most of the logic actually does just work! -- but several
Fixes b574ae0a2876ee94e4fe617f878407bf818c2df0
"hurd: Implement sigreturn for x86_64"
Checked on x86_64-gnu.
Signed-off-by: Sergey Bugaev
---
sysdeps/mach/hurd/x86_64/sigreturn.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sysdeps/mach/hurd/x86_64/sigreturn.c
The real i386_thread_state Mach structure has an alignment of 8 on
x86_64. However, in struct sigcontext, the compiler was packing sc_gs
(which is the first member of sc_i386_thread_state) into the same 8-byte
slot as sc_error; this resulted in the rest of sc_i386_thread_state
members having wrong
Fixes 60f9bf974694d50daf58d46347b06a5975ac5ddd
"hurd: Port trampoline.c to x86_64"
Checked on x86_64-gnu.
Reported-by: Bruno Haible
Signed-off-by: Sergey Bugaev
---
sysdeps/mach/hurd/x86/trampoline.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
Fixes 31dd30a94a682955c3c9e2f42252b4a07687067a "add setting gs/fsbase".
---
This was breaking fork () in glibc when it tried to set up TLS in the
new process by copying fs_base from an existing thread.
i386/i386/pcb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
---
proc/msg.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/proc/msg.c b/proc/msg.c
index 25ce0d5b..93ad995b 100644
--- a/proc/msg.c
+++ b/proc/msg.c
@@ -80,7 +80,7 @@ S_proc_setmsgport (struct proc *p,
perror ("pthread_create");
}
}
-
+
This fixes a proc server crash during startup inside
initialize_version_info ().
---
proc/cpu-types.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/proc/cpu-types.c b/proc/cpu-types.c
index 3d89d5a7..89787d3d 100644
--- a/proc/cpu-types.c
+++ b/proc/cpu-types.c
@@ -30,6 +30,9 @@ const
Normally glibc does not buffer tty output, but a devstream backed by
the Mach console device cannot be isatty'ed. So we need to ask glibc
explicitly to not buffer it. This is what the startup and mach-defpager
do already.
---
proc/main.c | 1 +
1 file changed, 1 insertion(+)
diff --git
Since we don't support mixing i386 and x86_64 binaries on the same
system (as running them requires different build-time gnumach
configurations), the exec server can simply require the binary being
loaded to have been built for the same architecture as the exec server
itself.
---
exec/exec.c
On Mon, May 15, 2023 at 9:19 AM Sergey Bugaev wrote:
> 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.
>
>
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.
Huh? Why would MIG call that? Maybe I'm missing some context.
44 matches
Mail list logo
