IRC channel logs

<oriansj>alMalsamo: well x86_64 hardware can run x86 binaries natively just fine.

<alMalsamo>oriansj: Yes I know this of course, unlike Itanium which tanked... but i want to end up with amd64 OS even if I have to start with an i686 kernel (for reasons I do not understand)

<oriansj>and hex2, M1, M2-Planet and M2-Mesoplanet should behave identiically if run on bare metal or on DOS or on Windows or BSD or Linux or (your own kernel) or etc

<oriansj>alMalsamo: you can start with an amd64 OS if you wish

<stikonas>well, you can start with amd64 OS but live-bootstrap eventually would fail due to technical reasons

<stikonas>it won't be able to kexec into the new kernel

<stikonas>but in any case, one you bootstrap 32-bit toolchain, cross-compilation to 64-bit is not hard

<alMalsamo>Hmm okay so I have to build a 32-bit toolchain first before I cross-compile a 64-bit one? This sounds like there are a LOT of steps wow

<stikonas>alMalsamo: but a lot of the steps are automated

<stikonas>so just the number of steps is not really concerning

<stikonas>e.g. live-bootstrap will get your from hex0/kaem-optional-seed to fairly functional 32-bit toolchain with gcc 4.7.4 and lots of extra tools (more than LFS starting point)

<oriansj>stikonas: thank you for that clarification.

<oriansj>alMalsamo: a LOT, no.

<oriansj>a non-zero value, yes

<alMalsamo>Hmm so looking at live-bootstrap README I am not sure I understand the difference between sysa sysb and sysc... are these seperate phsyical machines needed for bootstrapping (I am more interested in bare metal compared to QEMU or something) or are they aliases for seperate phases of the bootsrapping process on the same physical machine?

<alMalsamo>And why exactly do I need to start with i686 kernel and toolchain? Is this because a lot of components are written in 32-bit x86 ASM or something?

<stikonas>alMalsamo: it's the same machine

<oriansj>alMalsamo: The short answer for why we did the i686 bootstrap first, it was the shortest path to giving us a working bootstrap.

<stikonas>but kind of different file systems in each

<stikonas>sysa is the initial bootstrap system that bootstraps up to gcc

<alMalsamo>stikonas: what do you mean by different file systems, does that mean different filesystems being written to partitions on my SSD?

<stikonas>it then builds a linux kernel and boots it (actually kexecs into it)

<stikonas>sysa and sysb are entirely in memory

<stikonas>then sysb mounts filesystem on physical device

<stikonas>and chroots into it (that's sysc)

<stikonas>(sysb is inserted because we don't want to asume that bootstrap kernel can access hard drives)

<stikonas>actually if you run live-bootstrap in chroot mode rather than qemu or real system then it skips sysb and jumps from sysa to sysc

<stikonas>just before we jump to sysc we are already very close to maximum RAM limit (3 GiB)

<stikonas>that's why we need a disk to continue bootstrap

<stikonas>can't do any more in memory

<stikonas>alMalsamo: so it's kind of places where we change kernels

<stikonas>it's not that significant if you ignore kernel completely (and do chroot build)

<stikonas>which is what some distros might choose to do

<alMalsamo>Hmm well I just installed 16GB in my laptop, but the 3GB limit is because i686 binaries? I thought i686 can address up to 4GB RAM...

<stikonas>to bootstrap their root of trust

<stikonas>alMalsamo: yes, it can do up to 4 GB but not all of it is available to userspace

<stikonas>some of it is reserved for kernel

<stikonas>some has to be allocated to stack

<stikonas>some might be completely unused (from 0 to base address)

<stikonas>but it's mostly kernelspace

<oriansj>alMalsamo: also we need to leave some for running processes to do their work

<alMalsamo>Hmm my current kernel image is only 7MB why would it need a whole GB for kernelspace memory?

<stikonas>alMalsamo: I think it's hardcoded

<stikonas> https://www.kernel.org/doc/html/latest/vm/highmem.html

<fossy>hi

<fossy>yeah that's right

<oriansj>alMalsamo: you can also see how much memory your kernel is actually using with: slabtop

<fossy>stikonas: btw, are you happy for doras's PR to be merged

<fossy>I can't see anything wrong with it

<stikonas[m]>Didn't I approve it?

<stikonas[m]>I just didn't merge it yet cause I was not sure if it has conflicts with your work

<fossy>yeah, you did approve it, just wanted to make sure there wasn't any other reason why you didn't merge

<fossy>coolio, i will merge in that case

<fossy>there's nothing in there i can't trivally merge into my branch

<stikonas[m]>OK, go for it

<oriansj>well I traced the segfault but I think it pointts to a serious bug in M2-Planet

<oriansj>with the latest commit you should be able to do: make clean M2-boot

<oriansj>then ./bin/M2-Mesoplanet --debug-mode 8 -f ../mescc-tools/blood-elf.c -f ../mescc-tools/stringify.c --dump-mode -o foo

<oriansj>it shows the problem line is: struct utsname* unameData = calloc(1, sizeof(struct utsname));

<oriansj>but the calloc returns a valid pointer, as does the malloc inside of it (the memset inside of it proves that out)

<oriansj>but unameData just never gets set; which shouldn't happen

<oriansj>So I need to figure out a minimal test for M2-Planet to sort out the why

<oriansj>but I need some rest and will work at it tomorrow

<muurkha>wonderful you found that. that sounds like a real bear to track down

<oriansj>muurkha: the nice thing about M2-Planet, small enough enclosure to make the hunt fast

<muurkha>:)

IRC channel logs

2022-01-21.log