IRC channel logs

<stikonas[m]>lesson for today: don't forget to initialise variables. I was wondering why malloc on UEFI is resulting in application hanging. Turns out I forgot to call _init_malloc() that initialises linked list...

<rickmasters>I was able to get fiwix to run live-bootstrap until it failed building tcc-0.9.26 with mes.

<rickmasters>It may have run out of memory, not sure yet.

<rickmasters>It said one of the C files was not a valid input file.

<rickmasters>But it got pretty far, I'm happy with the results so far.

<rickmasters>I just had to work through some setup issues.

<rickmasters>Fiwix expects /dev/console to be populated in the ram drive.

<rickmasters>Fiwix mounts the root ram drive readonly so I had to change a line in the kernel to work around that.

<rickmasters>It executes /sbin/init by default but live-bootstrap uses /init.

<rickmasters>The bulk of my time was modifying live-bootstrap to prepare an ext2 ram drive.

<rickmasters>But I didn't have to change any stage0-posix source. It ran through that just fine.

<rickmasters>stikonas: you were right about finding issues with an alternative kernel.

<rickmasters>The missing /dev/console caused the init program (kaem) to not have stdin or stdout and so it opened kaem.x86 as fd 0, but misinterpreted that as an error.

<rickmasters>When open fails, it returns -1 but kaem is looking for zero as an error. That's a bug.

<stikonas[m]>OK a few issues but it seems that it's not too bad

<stikonas[m]>The first one (possible ran out of memory is slightly worrying)

<stikonas[m]>And in unrelated news, I now have a working malloc in M2libc on UEFI

<stikonas[m]>Including cleaning up all alocated pages on exit

<stikonas[m]>Still a bit more work is needed until i can build rest if stage0-uefi

<deesix>ACTION puts the bootstrappable work, again, on the table.

<deesix>But then, there's the hardware trust (none).

<deesix>Sorry, bad channel :)

<deesix>ACTION spreading the message, somewhere else.

<rickmasters>stikonas: congrats on malloc

<oriansj>deesix: right channel and honestly people doing hardware bootstrapping is probably the next phase after we get the kernel bit sorted.

<oriansj>So people getting started on that now (or ideally a couple years ago) is a very good idea

<oriansj>but as always people work on what they think is the correct course forward and I encourage you deesix if you think hardware bootstrapping needs more progress to share more information or perhaps even start something that would solve that in a way you think is best.

<deesix>Hi, oriansj. It was not the right channel; I was talking with some other people and by mistake typed here (after coming to get the right spelling of the word) those messages. Again, sorry :)

<oriansj>no worries deesix easy mistake to make

<stikonas>rickmasters: well, most of the work was already done when I implemented first free fit malloc in stage0-posix

<Hagfish>i'm really pleased about how well Fiwix is integrating with bootstrapping, from both a technical and social perspective

<Hagfish>messages like this are so wholesome:

<Hagfish>"I'm completely astonished to know that Fiwix can be of small help in your bootstrapping projects. I'll do my best to include and fix anything you need for your project."

<rickmasters>The problem building tcc-0.9.26 on fiwix was because the maximum number of open files per process (256) was too low.

<rickmasters>I increased that to 512 and the tcc-0.9.26 build succeeded.

<rickmasters>It also built make, gzip (with make), tar, sed, patch, bzip2, tcc-0.9.27, coreutils, heirloom-devtools, and bash.

<rickmasters>Then it failed on flex 2.5.11

<stikonas>ok, that's a good progress

<rickmasters>stikonas: yeah. still a lot of packages ahead but it's a good start.

<stikonas>I suspect once you get a bit further, things will start looking easier, there shouldn't be too many new kernel features used

<stikonas>is something with bash caused flex build failure?

<rickmasters>I'm still looking at the flex failure. it's an invalid byte 0x0f in an input file

<rickmasters>That could be memory corruption which is typically a difficult issue to debug.

<rickmasters>I think 'make' was running multiple processes simultaneously which I wasn't expecting.

<stikonas>hmm, yes, that's not right... live-bootstrap never runs make with -j

<rickmasters>I may be wrong, the output isn't clear.

<stikonas>in the meantime I'm trying to get user stack working in M2libc. Looks like implementation that I used in bootstrap M2libc is buggy...

<stikonas>I'm probably overwriting some stuff outside allocated area (probably 64 bits or so before stack)

<stikonas>(and probably solved, I think I was passing the wrong end of allocated memory for stack, since stack grows downwards)

<stikonas>oriansj: do you prefer one big M2libc PR or should I submit smaller ones (for now I just have malloc() and user stack switching working)

<stikonas>looks like remaining things are mostly to do with I/O and launching new processes

<stikonas>oh and I still need to deal with command line arguments and env variables...

IRC channel logs

2022-11-20.log