IRC channel logs
2023-01-19.log
back to list of logs
<rickmasters>I added better file descriptor support to the builder-hex0 kernel. <rickmasters>Now it can support running tcc-0.9.27 to build a fully functional Fiwix kernel. <rickmasters>The remaining work is to implement (kexec/no rebooting) transitions from builder-hex0 to Fiwix to Linux. <rickmasters>The builder-hex0 kernel currently weighs in at 3466 bytes. <stikonas>I guess there is still some effort needed to upstream stuff? <rickmasters>stikonas: I have around a dozen improvements to upstream to Fiwix. <rickmasters>I have a change to both versions of musl to bypass the need for the clone syscall <stikonas>well, mes should be easy, I'm sure janneke would accept your patch <rickmasters>These changes would generate new checksums for many live-bootstrap binaries and packages <stikonas>oh, that is fine, any mes update also breaks all checksums until after musl <stikonas>we now have a fairly good scripting to update them <stikonas>all tar.bz2 packages end up in /usr/src/repo directory and you can just check it there <stikonas>back to patching. Musl should be easy too as we have patch then <stikonas>tcc might be a bit trickier, maybe we can use your pathching script or replace from stage0-posix... <rickmasters>Yes, I'm already patching all my changes with simple-patch <rickmasters>I also need to formulate an integration strategy with live-bootstrap but it shouldn't be too hard. <stikonas>well, builder-hex0 takes different input than initramfs image live-bootstrap uses now <rickmasters>I'm thinking just dump the boot2now file system scripts in a directory and add that option to the python launcher <rickmasters>I modified a version of live-bootstrap to produce an ext2 file system for Fiwix so I've done that kind of work already. <oriansj>rickmasters: I am so so very very excited by your progress. <rickmasters>oriansj: Thanks! I'm hoping the hardest parts are done now - writing and compiling the kernels. <oriansj>Well the hardest parts will likely be solving the hardware bootstrap problem but your kernel work really paved the way for other people to do kernel ports <oriansj>and honestly probably saved me from 5-10 years of work <rickmasters>Yeah, I was just talking about the kernel bootstrap work. The hardest parts are done in relation to the work remaining to kexec/boot them. <oriansj>I also hope the kexec/boot work is a nice peaceful jot to victory for you <rickmasters>In the bigger picture there is still so much difficult work - for hardware and other architectures. <oriansj>oh, I think of it as a lot of fun and a way to really finally know all of the secrets <fossy>rickmasters: that is very exciting update! thanks for your work :D <fossy>rickmasters: builder-hex0 is effectively stage0-posix+kernel right? <stikonas>fossy: builder-hex0 I guess is just kernel <oriansj>(and the steps to TCC-0.9.27 too by the looks of it) <stikonas>and in fact it includes an implementation of hex0 inside the kernel <rickmasters>builder-hex0 also includes a primitive shell and hex0 compiler <stikonas>it's boot2now that is builder-hex0+ stage0-posix + a few extra steps to TCC <fossy>so in terms of live-bootstrap integration we effectively prepend builder-hex0 to stage0-posix <oriansj>and insert the fiwix kernel bootstrap prior to the Linux kernel build <fossy>rickmasters: are there any patches for fiwix compatibility to userland software? or is it only kernel changes you made <rickmasters>builder-hex0 is compiled into one binary that can process source for stage0-posix, mes, tcc, and Fiwix and produce new executables and the Fiwix kernel <rickmasters>The boot2now project is the driver that assembles that source code and appends it to the binary in the form of a bootable disk image. <oriansj>(Which later I can solve generating using the Nanochess BootOS) <rickmasters>fossy: The Fiwix specific change was to patch musl to avoid using the clone system call. I replaced it with fork and a little bit more. <fossy>oh, that's no big deal at all <rickmasters>fossy: I also tested that musl change with the Linux kernel and it ran to the end fine <oriansj>and a single boot sector kernel should be a small enough root of trust for our bootstrap chain (and we don't need to automate the building of the boot2now disk image if we have a written procedure for generating it) <fossy>whats the format of the disk, in terms of providing files live-bootstrap needs? since builder-hex0 doesn't use a full-featured filesystem <fossy>ie, how does the disk get translated into vfs <rickmasters>The initial file system is a series of source files appended together with a small text header that has the file name and number of bytes <rickmasters>That is read off the disk into a primitive memory file system. <fossy>yeah, i just wanted to make sure this wouldn't require any logic in rootfs.py that is too hard to perform manually <rickmasters>Except I also currently append tar files. But in theory, those could be expanded into text files. <fossy>rickmasters: i have no worries about that <fossy>even easier to audit than cpio (which is what we use right now) <fossy>hrm, should add a TRUST.md equivalent to live-bootstrap, like in boot2now <fossy>because all the right concerns and unsolved problems are there <rickmasters>fossy: feel free to copy any of it you'd like and attribution is not necessary <rickmasters>The text of TRUST.md was initially part of the README but I broke it out because it was a bit too philosophical and maybe distracting from the "useful" stuff in the README <stikonas>muurkha: we already have untar in stage0-posix <stikonas>and half of it is argument parsing (whereas tar.pl doesn't seem to support arguments) <stikonas>well, we didn't have a goal to minimize lines of code in untar.c <oriansj>also we don't have a known good path to Prolog yet <stikonas>tar is also almost a human readable format <stikonas>so perhaps it's not surprising that implementations are short <stikonas>it's a bit more complex than rickmasters filesystem but not terribly more so