IRC channel logs

<solid_black>sneek: seen wbartczak?

<sneek>I think I remember wbartczak in #hurd -27 minutes and -26 seconds ago, saying: are there any specific rules for posting? text vs. html .etc?.

<solid_black>-27 minutes and -26 ago, huh

<solid_black>well, let's wait for 27 more minutes then I guess :)

<etno>Hi! I am investigating a delay (~90s) in the boot sequence of debian/hurd-i386/up installed on real hardware (once booted, the system is otherwise working really great). Right at boot up, it waits with "start pci-arbiter: pci acpi" as the last message for a long time. I added some printf statements in pci-arbiter and acpi, but they don't make it to the console. What is the easiest way to print to the console fr

<etno>om a bootstrap server ?

<etno>Argh, this got truncated :-/

<etno>Are bootstrap servers able to print to the console via printf() ? Or does one have to go through a console device?

<azert>etno: check the tests in gnumach

<azert>If I’m not wrong there is an rpc called mach_print

<azert>Dunno which header it is defined

<etno>Thanks azert, this looks like the entry point to print directly to the console, which I will probably end up using. In the meantime, I tried to print via the libc, and nothing gets displayed. This somehow makes complete sense, since file-descriptors are far from available at that stage.

<solid_black>etno: glibc can in fact print without file decsriptors

<solid_black>a FILE object doesn't have to be backed by one

<solid_black>see mach_open_devstream () in glibc

<solid_black>so you can do device_open ("console"), and then stdout = mach_open_devstream (console_port);

<solid_black>and some Hurd servers already do that

<solid_black>but maybe not the one you're debugging

<solid_black>also, don't forget to fflush

<etno>So, device_open is the syscall to open a gnumach device. The libc can use device ports as FILE backend. And mach_print is another syscall, opened to anyone willing to print in the console, which might be the "console" device. Is that correct solid_black ?

<solid_black>device_open is an RPC, not a syscall

<solid_black>mach_print is a syscall, yes

<solid_black>I think it's only enabled in debug builds of gnumach, but I'm not very sure

<solid_black>mach_print doesn't technically use the console device even, it uses kernel's printf ()

<solid_black>which supposedly goes to the same place where the "console" device writes, but it doesn't go through all the device code paths

<solid_black>which is why in the aarch64 port, printf () and mach_print () work, but "console" doesn't

<solid_black>but since you're dealing with x86, either should work, yes

<etno>Thanks solid_black!

<etno>It works like a charm. I learned about the global _hurd_device_master in the process

<dsmith>!uptime

<sneek>I've been a process for 11 days

<sneek>This system has been up 5 weeks, 2 days, 23 hours, 33 minutes

<dsmith>sneek, seen etno

<sneek>I last saw etno in #hurd 1 hour and 54 minutes ago, saying: It works like a charm. I learned about the global _hurd_device_master in the process.

<dsmith>sneek, botsnack

<sneek>:)

<sneek>ACTION wags

IRC channel logs

2024-04-19.log