IRC channel logs

<braunr>am i right to understand that ssh currently doesn't work ?

<gnu_srs1>Hi, is 50_initrd.patch strictly needed for gnumach? What about --enable-pae?

<gnu_srs1>And: How to enter the debugger: --enable-kdb and --enable-kmsg are given to configure.

<youpi>initrd is needed for d-i

<youpi>enable-pae could probably be passed, I haven't checked

<youpi>concerning the debugger, see my latest commits

<gnu_srs1>Entering C-A-d in the serial console does not work :(

<gnu_srs1>The hang at boot "start ext2fs": seems to come from: kern/bootstrap.c:boot_script_task_resume(); printf ("\nstart %s: ", cmd->path);

<youpi>gnu_srs1: again, see latest commit: commit 97314ab115206137018b0cd7196ce404ceee136c

<youpi>Author: Samuel Thibault <samuel.thibault@ens-lyon.org>

<youpi>Date: Sun Nov 27 21:28:32 2022 +0100

<youpi> Update kdb_kintr according to new interrupt stack layout

<gnu_srs1>tks, I had gumach from git dated Nov 27, but your changes were not added yet. Will update and rebuild. Nevertheless C-A-d in the mate desktop environment hides all applications (:

<gnu_srs1>I switched to boot in console and C-A-d works, thanks.

<gnu_srs1>However, I'm not fluent with the debugger: show all thread: 0 gnumach (f59adf00): 8 threads:, 1 exec (f59add80): () ..SO..(thread_bootstrap_return)

<gnu_srs1>Is this correct for a non-apic,-pci-arbiter,-rumpdisk boot: https://paste.debian.net/1262299/ ?

<youpi>yes

<gnu_srs1>Thanks all, I think I'll give up for now. Here is the boot log with serial console output: https://paste.debian.net/1262333/

<Guest1161>I have a general question regarding migrating thread and short circuits, if I understand correctly they are big optimization to mac ipc, and mklinux implemented them. Gnumach have only a dev version of the former and none of the latter. Do you think that the Hurd would benefit from those optimizations?

<gnucode>Guest1161: probably. Wanna help us implement them?

<gnucode>"us"... haha. I am not a Hurd developer

<Guest1161>Ahah I am too dumb to do that

<Guest1161>I’ve read that the most significant optimization to gnumach respect to those Mach is something called protected payloads

<Guest1161>But when I try to understand how they work it seems it requires one to be too involved than me to understand

<gnucode>Guest1161: I feel your pain. I tried to implement a trivial translator...I didn't get very far....

<Guest1161>Interesting there is a page on the wiki arguing for new optimizations https://www.gnu.org/software/hurd/microkernel/mach/gnumach/projects/mach_5.html

<Guest1161>Most thing there has been implemented

<Guest1161>Not most.. many

<gnucode>Guest1161: how do you know they have been implemented?

<gnucode>nevermind the wiki talks about it.

<gnu_srs>Hello, when cross-compiling hurd I get 48 warnings like: i686-pc-gnu/bin/ld:

<gnu_srs>warning: manage-one-thread_pic.o: requires executable stack (because the .note.GNU-stack section is executable)

<gnu_srs>Any ideas on how to create an executable stack (or how to avoid these problems)?

<youpi>I haven't looked at that

<youpi>usually that happens because we use a nested function that is passed to an iterator

<youpi>that indeed requires making the stack executable

<youpi>which is frowned upon for security reasons

<youpi>but nested functions are really nice to have so make the code simpler

<youpi>anyway, the warning is only there to tell that in general it's not good to have an executable stack

<youpi>but it'll just work fine

<slex>hello guys, i have a little toy libc i'm writing. I'd like to use it on gnumach, where i should look to implements its basic syscalls like mach_msg?

<youpi>hello, you can look at mach/machine/syscall_sw.h

<slex>ty

<iska>damo22 is your smp-upstreaming branch working? and what configure flags do I use again?

IRC channel logs

2022-11-29.log