IRC channel logs

<damo22>(10:51:13 AM) damo22: acpi has generic address structure they call it GAS for short

<damo22>(10:51:33 AM) damo22: its a 12 byte struct containing either 32 or 64 bit address of something

<damo22>no wonder i got the address wrong

<zamfofex>apteryx: Since it doesn’t support linker scripts, I imagine you’d probably have to add explicit support for other systems to it.

<zamfofex>solid_black: Very cool! 🎉 I wonder whether it could boot on v86. I remember trying with Debian and Guix, and neither worked.

<apteryx>does hurd tooling relies on linker scripts?

<damo22>woot i implemented HPET timer

<damo22>it counts properly on amd and qemu

<etno>damo22: that's great ! I am curious about the 12 bytes pointers, do you have a reference?

<damo22>see hpet spec page 30

<damo22>aaaand it still wont boot smp

<etno>Haha, byte 5 to 12, they did not make it easy to guess

<damo22>mailed in HPET support

<damo22>its a lot of work to get a function that delays for a known amount of time

<zamfofex>apteryx: It’s not that Hurd tooling relies on linker scripts, but, as far as I know, ELF has a field indicating the system of the binary (in order to avoid linking incompatible binaries together by accident). That should be easy to add, but there might be other kinds of incompatibilities too. (I’m not particularly familiar with linkers, so you should explore it if you find it valuable, I feel.)

<damo22>This option limits the number of SIPI signals sent during during the

<damo22> common AP setup. Intel documentation specifies an INIT SIPI SIPI

<damo22> sequence, however this doesn't work on some AMD and Intel platforms.

<damo22> These newer AMD and Intel platforms don't need the 10ms wait between

<damo22> INIT and SIPI, so skip that too to save some time.

<solid_black>hi all

<damo22>hi

<azert>Hello damo22. I’ve spotted a typo in your patch

<azert>You write « wait 10ms »

<azert>Then you delay 10 microseconds instead

<damo22>hmm

<damo22>where, in smp.c?

<azert>Yes

<damo22> /* Wait 10 msec */ - pit_mdelay(10); + hpet_mdelay(10);

<damo22>these are millisecond delays

<damo22>udelay is microseconds

<damo22>i think you are mistaken, azert

<damo22>anyway that is not an interesting patch, the one before is

<azert>It’s true damo22, I’m mistaken

<azert>I didn’t notice the single letter difference between the two function names

<azert>Im wondering if you really need the mdelay function

<biblio>hi all, I am trying to cross build 32-bit gnumach for learning. I am getting "error: static assertion failed" for $ make gnumach.gz - https://paste.debian.net/1306083/ .Is it a known issue ?

<biblio>or I need updated version of binutils or other libs.

<youpi>biblio: which documentation did you follow? You need a git version of mig

<biblio>youpi: yes, I have mig from git://git.savannah.gnu.org/hurd/mig.git

<biblio>youpi: https://www.gnu.org/software/hurd/microkernel/mach/gnumach/building.html and https://www.gnu.org/software/hurd/microkernel/mach/mig/gnu_mig/building.html

<youpi>did you pass --target-arch=i386 to the mig build ?

<youpi>err, I meant --host=i686-unknown-linux-gnu

<youpi>(target-arch is for dpkg-buildpackage)

<biblio>youpi: yes --host=i686-unknown-linux-gnu

<solid_black>don't pass --host to MIG build if all you're trying to do is build a cross-mig; pass --target

<youpi>then the documentation needs fixing

<solid_black>I should really upstream my cross-compilation guide

<solid_black>maybe I could ask gnucode for help with that

<youpi>we have way too many half-correct documentations rather than just one with all corrections, yes

<youpi>it seems it's a human tendency to just re-write documentation on the corner, and taking the time to contribute seems a high cost few people manage to spend

<biblio>solid_black: thank you

<solid_black>biblio: first install Mach hedaers like so: CC=gcc ../configure --host=i686-gnu && make install-data

<solid_black>then build MIG like so: ./configure --target=i686-gnu && make && make install

<solid_black>then Mach again, ../configure --host=i686-gnu && make && make install

<solid_black>there you go, another half-complete guide :)

<damo22>at this point i am at a loss why sending INIT + SIPI crashes the AMD board, i even have the BKDG for this cpu

<damo22>i fixed the timing, even tried coreboot's way of dropping first SIPI

<biblio>solid_black: In debian 12. dpkg -L gcc-i686-linux-gnu . So, I had to pass (for mig) $ TARGET_CPPFLAGS=-I"$GNU"/include ../configure --prefix="$GNU" --target=i686-linux-gnu

<biblio>solid_black: I end up having i686-linux-gnu-mig instead of mig in ~/gnu/bin/. So, I create symlink mig. Finally, I was able to build. :)

<biblio>youpi: solid_black: thank you for your help. It worked.

<solid_black>biblio: yes, you should have i686-gnu-mig

<solid_black>I don't think you're supposed to alias just "mig" to it, but nothing stops you from doing that

<solid_black>but the target triple is important, i686-gnu-mig is different (generates difference C code) from x86_64-gnu-mig, and even more different from e.g. x86_64-apple-darwin20-mig

<biblio>solid_black: I found readelf -h ../libexec/i686-linux-gnu-migcom Class: ELF64

<biblio>solid_black: I will check and try to solve.

<solid_black>yes, that's alright if what you're doing this on your *build machine* is a 64-bit Unix system

<solid_black>s/your *build machine*/(your *build machine*)/

<solid_black>and s/difference C code/different C code/, argh

<biblio>solid_black: ok thanks.

<solid_black>it still sounds like this doesn't make sense to you :|

<biblio>solid_black: I am clear about gnumach targetting i686. But even if we passed, target=i686-linux-gnu. it is generating 64bit elf.

<biblio>solid_black: So, my understanding we are telling mig to generate c code for i686 but mig is build to run on 64-bit in my dev OS. right ?

<solid_black>yes, exactly!

<biblio>saolid_black: ok

<biblio>solid_black: clear

<solid_black>except --target=i686-linux-gnu is wrong, it should be just --target=i686-gnu

<solid_black>or i686-pc-gnu or whatever, but not linux-gnu

<biblio>solid_black: it could be - I am using debian packges to install i686 gcc.

<youpi>mig is a compiler

<solid_black>and it's not just the number of bits; your MIG is being built on x86_64 GNU/Linux (its *build* machine), will itself run on x86_64 GNU/Linux (its *host* machine), but will generate code for i686 GNU/Hurd (the *target* machine)

<youpi>so it's normal that when building it, you get something that runs on your build system

<biblio>solid_black: https://www.gnu.org/software/hurd/microkernel/mach/mig/gnu_mig/building.html we have --host=i686-unknown-linux-gnu . It is generating i686/i386 migcom. Will it generate 64bit c code ?

<solid_black>I'm not seeing " --host=i686-unknown-linux-gnu" on that page?

<biblio>"If you are building on a 64 bit machine, you need to add a --host option:"

<biblio>solid_black: the page is updated just now. :)

<solid_black>uhh, you must pass --target in any case, 64-bit or not, unless you're building a native MIG and not a cross-MIG

<biblio>solid_black: oh now everything clear.

<solid_black>but really this is approaching this all from the wrong angle

<damo22>hmm maybe the IOAPIC irqs need to all be masked in case the AP starts with interrupts enabled??

<solid_black>a guide should start from explaining what build/host/target machines/triplets are

<biblio>youpi: ok

<solid_black>and which ones to pass to which projects

<solid_black>(i.e. that you pass i686-gnu target to gcc and mig, but a i686-gnu host to gnumach and glibc)

<youpi>contributions welcome

<youpi>I always see people complain about documentation, but few bring documentation patches

<youpi>(I'm not even angry about this, mostly desesperate to see people always think "bah I'll just rewrite my own tutorial" over and over)

<biblio>youpi: agree

<solid_black> https://www.gnu.org/software/hurd/microkernel/mach/gnumach/building.html doesn't even mention you need to pass --host to gnumach build unless "building on a 64 bit host system"

<youpi>"doesn't even" is not a good justification not to do anything about it

<youpi>also, take care of documentations that get too long

<youpi>people then don't read it

<solid_black>much like you're saying, what I'd like to do about it write my own guide to building a cross-toolchain and cross-compiling Mach/Hurd/glibc

<youpi>why yet another new guide?

<youpi>we have already litteraly a dozen over the internet

<youpi>can't we *just* fix the gnu.org one?

<youpi>realluy

<youpi>I'm amazed

<solid_black>xkcd 927, but for buildling guides :)

<youpi>how it seems to be so hard to just work on one doc

<youpi>as soon as a documentation is missing a tiny update, somebody writes another

<youpi>which then misses another update

<youpi>and there you go with another one

<youpi>can't people understand that's no good use of anybody's time?

<biblio>youpi: i will update the docs for building, if I find any new issue.

<damo22>i hope everyone knows where the official docs live

<biblio>damo22: I think - git://git.savannah.gnu.org/hurd/web.git . In emacs markdown-mode package helps to edit it.

<damo22>:)

<biblio>damo22: I have a lenovo x201 flashed with coreboot (now using as a printer server). If you need some hardware specific info for the issue you are facing, let me know.

<damo22>so far, it seems that AP init is broken on native hw

<damo22>but works in qemu

<damo22>i tried masking all the IOAPIC irqs

<biblio>damo22: ok

<damo22>you really dont want the AP to get an interrupt except the IPIs

<damo22>i dont understand how the init sequence can cause a fault, its supposed to wake up

<damo22>All other processor cores other than core 0 begin executing code from the reset vector.

<damo22>and coreboot sets up the APs and then puts them to sleep

<biblio>damo22: https://www.cs.cmu.edu/~410/doc/minimal_boot.pdf is sure if it will help.

<zamfofex>youpi: Maybe there should be a wiki‐style manual that people can easily edit and moderate from a web interface.

<zamfofex>The documentation truly is kinda “everywhere”. I remember when I was having trouble with netdde, I couldn’t find a centralised source of information. There were pages on gnu.org, on debian.net, and on various other websites, each with subtle differences.

<biblio>zamfofex: In my personal opinion, submisstion via mail is better option. Webinterface requires autentication mechanism using 3rd party (unless Hurd's own authentication system like Debian wiki). So, I prefer current model. But, I agree another wiki page needed - how to edit wikipages and submit. :)

<apteryx>zamfofex: thanks

<solid_black>and -- I have built x86_64-gnu world :)

<solid_black>as in, alll the same packages as for i586-gnu previously

<etno>Where is __mach_msg_overwrite_trap() implemented ?

<solid_black>it's not? we don't have mach_msg_overwrite, that's an OSF Mach thing

<etno>Let me rephrase my question then :-) : where can I find the low level mach syscall implementation?

<solid_black>gnumach:i386/include/mach/i386/syscall_sw.h

<solid_black>that's the code that ends up in glibc for making syscalls from userland

<solid_black>the actual implementation of mach_msg_trap is in gnumach:ipc/mach_msg.c

<dsmith>j #rust

<etno>solid_black: Thanks !

<etno>So those headers are not used in gnumach and are headers only, is this correct?

<solid_black>they are installed by gnumach, but include-d, and the resulting code and compiled, by glibc

<youpi>it's mach telling userland how to make system calls

<youpi>thus not for mach itself indeed, but for userland

<solid_black>well, guess they're also used in Mach self-tests now

<solid_black>but yeah userland

<solid_black>sneek: seen gnucode?

<sneek>gnucode?, pretty sure was seen in #hurd one day and 22 hours ago, saying: I actually prefer later! Let's go for 11am EST, which should be 19 PM for you..

<solid_black>jab: you're gnucode aren't you? :) hi!

<jab>solid_black:

<jab>what up?

<jab>let me set up a meeting room!

<jab>soorry for being a little late...

<jab> https://jitsi.member.fsf.org/AlpineHurd

<jab>solid_black: this is going to be fun!

<jab>yes I am gnucode.

<jab>sorry about the confusion. Oh! It says gnucode when I use the Hurd.

<jab>anyone is welcome to join Sergey is an awesome discussion about his new Hurd distro based on Alpine Hurd

<jab>"AlpineHurd"'s console works! You do see the message of the day.

<jab>You can do "apk add gcc" and you get it in a few seconds.

<jab>python works!

<jab>still far behind debian and guix system

<jab>It took Sergey 5 minutes to update to the latest glibc. How long would it take Debian to do that? We love Debian! They just have different goals than "Apline Hurd".

<youpi>doing it is not long

<youpi>getting bugs fixed *is* long

<youpi>and new upstreams of glibc come with a lot of them

<jab>rumpdisk is not yet built on Alpine hurd.

<jab>youpi: of course! No insult intended. Just pointing out the different ways that Debian Hurd will be *stable* but Alpine Hurd may move quickly.

<youpi>people misunderstand the difficulty of maintaining a distribution

<youpi>I'm not taking it as insult

<jab>We do love and appreciate your dedication to debian over the years!

<youpi>just as misunderstanding of what exactly is difficult

<jab>lwip builds on Alpine Hurd.

<youpi>any distribution that grows to large numbers of packages will see that a newer version of glibc is not something you can pick up

<youpi>that'll break various packages

<jab>I'm just documenting the meeting as it happens. I'm appointing myself the secretary. :)

<jab>"AlpineHurd" does not have networking yet. no TCP/IP stack yet.

<jab>"apk add gcc" currently uses the local apk repository.

<youpi>really, my concern is that people often criticize things without actually knowing that the difficult part of that thing is

<youpi>I see it way too often

<jab>I'm sorry youpi. I just meant it as a little joke. :)

<youpi>leading to people making decisions on wrongly-understood premises

<youpi>sure

<youpi>I completely understand that

<jab>You are welcome to join in the meeting and give us some pointers. :) If you are not busy.

<youpi>but it pinpoints the kind of profound misunderstanding of what packaging difficulty really is

<youpi>I am busy

<youpi>from the start of distributions, the difficulty has been to find a combination of versions of software which actually happen to work altogether

<youpi>sometimes there is actually not even a solution without patching one of them

<youpi>because of people not caring enough about backward compatibility

<jab>gotcha.

<jpoiret>Guix/Hurd has trouble with that as well :)

<jab>jpoiret: what!? That is news to me actually.

<jpoiret>youpi: are you using 2.38 with cherry-picked hurd commits on top?

<jab>I thought that the Guix/Hurd fixed most of those things...

<youpi>(on a side note, rust is using a different versioning management which allows to break compatibility etc. but that seemingly mostly leads to people caring even less and making the whole thing even more complex in the end)

<jpoiret>jab: basically the libc in Linux-land is quite stable, but in Hurd-land you really have to update everything at the same time, ie. gnumach/hurd/libc and even mig sometimes

<youpi>jpoiret: yes, though the cherry-picks shouldn't be really required, the upstream tarball does run most of the testsuite fine

<youpi>jpoiret: well, if people were caring about backward compatibility, we wouldn't have the issue

<jpoiret>i am trying a 2.39 upgrade right now, but for Linux for now. Hurd will come second. We're still on 2.35 :)

<jpoiret>yeah, and for a project as small as Hurd, no one can really blame you for not maintaining backward-compatibility

<jab>"Alpine Hurd" offers no stability between upgrades yet.

<jpoiret>imo it's better to keep momentum and not worry about backwards compatibility in that case, as long as we know which versions work together properly

<jab>OpenRC works on "Alpine Hurd", but it fails to ... ?

<jab>the random translater /dev/random has some issues.

<jab>It does have a TCP/IP stack, but it lacks networking drivers.

<jab>Could "AlpineHurd" be a business? Could we get paid to develop "AlpineHurd" ?

<jab>Serenity OS, switched from irc to discord, and their # of users skyrocketed.

<jab>But guix is great at building communities too.

<jab>We can learn a lot from Serinity OS. They are a rapidly growing new OS.

<biblio>jab: https://en.wikipedia.org/wiki/Discord License: Proprietary

<jab>biblio: I know

<dsmith>That's probably because irc is considered "old". For boomers, graybeards, and the like.

<biblio>dsmith: "new" should not mean - lets move to a proprietary system we will get many users. Anyone can join IRC also from web-based system.

<Gooberpatrol66>i would recommend using matrix or something if irc is too "boomer"

<anatoly>Oh yeah! Hello every one!

<azert>The way I see it SerenityOS got momentum because of the Charisma of its main author and the fact that it’s an UNIX but with many idiosyncrasies

<azert>It’s basically something built with taste, although not very original

<ThinkT510>I'm a lot more interested in the ladybird browser

<azert>Agreed, ladybird is more something we need

<azert>I could see myself browsing one day in ladybird and working on the Hurd

<azert>Would be nice if the Hurd had more idiosyncrasies

IRC channel logs

2024-02-02.log