IRC channel logs
2026-09-29.log
back to list of logs
<notgull>Mikaku: and while you’re here, thanks for writing Fiwix, I’ve very much enjoyed reading through the codebase <stikonas>oh, that might be useful for Googulator28 's hope to get small live-bootstrap images <Googulator>Network is one thing, but the biggest thing missing from Fiwix is proper disk support - and I don't see that changing in a meaningful way anytime soon; at least not without making Fiwix too complicated to build under builder-hex0 <Googulator>Also for network, every NIC Fiwix gains support for means more code to build in builder-hex0 <Googulator>i.e. BH0 builds and boots fiwix-mini which is ramdisk + VGA out + serial console only, then in fiwix-mini, we build fiwix-full with broader hardware support, kexec to it, and use it to build Linux <stikonas>every feature we add, make us compile more stuff with cc_x86 <stikonas>those are more complex and might significantly increase compile complexity <Googulator>IMO the lowest hanging fruit right now is reducing the size of the Fiwix initrd - right now, it needs to be built in builder-hex0 big enough to hold everything that will be built in Fiwix <Googulator>If we could pass a smaller initrd to Fiwix, just enough to contain everything built in BH0, and then have Fiwix expand it dynamically, that would alleviate much of our memory map-related restrictions <Googulator>or any kind of ramfs without a backing block device <Mikaku>notgull: glad to know you enjoyed it :-) <Mikaku>Googulator: this requires changes in the kernel memory management and this also aligns with the current problem of not having support to allocate dynamically more than a PAGE_SIZE <Mikaku>I plan to focus on this in the near future <aggi>Googulator> making Fiwix too complicated to build under builder-hex0 <aggi>don't know what the limitations are with builder-hex0 (kernel ABI), since it is tinycc which compiles fiwix <aggi>which is of interest to me, when considering to replace kexec_fiwix with kexec_linux-tcc (2.4) <aggi>fiwix is a preferable choice, nonetheless hardware support with linux-2.4 could remain relevant with a linux/busybox/tcc system bootstrap <aggi>which three options exist: 1) chroot bootstrap 2) bootstrap builder-hex0 -> tcc/fiwix -> any linux; and 3) builder-hex0 -> tcc/linux directly (which mentioned limitations are unknown) <Googulator>once a file is created, it can't disappear or shrink <Googulator>not just that the memory isn't freed - system calls to delete or shrink files are silently ignored <Googulator>on top of that, the amount of space available for files is limited not by actual RAM, but by how BIOS allocates physical address space <Googulator>and because of the aforementioned lack of ramfs support in Fiwix, every file must fit in that space twice - first as a "loose" file, and then as part of the Fiwix initrd image <Googulator>and then on top of that, the initrd image must allocate all of what will become free space for Fiwix to build things in <Googulator>so you really don't want to produce output in builder-hex0 beyond the bare minimum necessary <Googulator>Oh, and forget about using make, or a real shell, in builder-hex0 - those all need real fork/exec <aggi>Googulator: thanks. good to know. linux-tcc build-system is almost trivial and can be re-written for kaem style scripting <aggi>file-deletions can probably be avoided, which then leaves the memory size limit <aggi>current linux-tcc.bin kernel statically linked is 6MiB in size (since i tried to statically everything desirable such as NFS, iptables etc.) <Googulator>although - does Linux 2.4 support initramfs already? <aggi>yes, of cause; i've re-based and added squashfs for initrd even <aggi>moment... nope, initramfs was introduced with kernel-2.5 <aggi>don't know which implications this has, because initrd loaded from ext2 or sqfs worked with 2.4 <aggi>however linux-2.4 does support ramfs/tmpfs which can be referred to with root=/dev/ram0 etc.. <Googulator>yes, tmpfs is possible, just no built-in way to populate it <aggi>ok. good so far, kexec_linux/make_bootable for linux-tcc was not yet tested anyway <aggi>i'll do so first inside /chroot which needs adaptions to linux-tcc kbuild too <aggi>and then later test for the complete builder-hex0 system-bootstrap <aggi>for either variant (2) or (3) <Googulator>that means, if we can find a way to populate a tmpfs (perhaps via a minimal initrd containing kaem, untar and mount, plus a tarball with the contents, and a kaem script to drive everything), we can replace Fiwix with linux-tcc, and get much better memory management in the pre-gcc stage <Googulator>That's assuming linux-tcc can indeed be built under builder-hex0 <Googulator>even better, we could pass the actual memory block containing builder-hex0's in-memory FS as an initrd to linux-tcc (in place or via a trampoline-based copy - no copying to a builder-hex0 file), and have a custom read-only FS driver interpret it on the Linux side, and then all that's left is to write a linuxrc file (included in srcfs, and hence the <Googulator>builder-hex0 in-memory FS) to move everything into tmpfs <Googulator>But all of this is of course predicated on builder-hex0 being able to build something as complicated as Linux 2.4 <Googulator>Looks like we do already build Fiwix from multiple C files, and then link it using TCC's linker mode (I somehow remembered that we used a unity build, i.e. catm'ing all Fiwix sources into one file, and then compiling with tcc as one unit) <Googulator>aggi: is PAE available in linux-tcc? (Mainstream Linux 2.4 supported it, but I reckon it depends on the compiler supporting 64-bit data types in 32-bit mode.) <aggi>Googulator: i have not re-tested this for a while, i tend to think it did work with linux-tcc <aggi>i've had some other issue with SMP, when utilizing tinycc as x86_32 assembler, hence i had to use YASM which processed related asm pieces correctly <aggi>PAE, should work in any case, it's not been a priority yet <aggi>overall i think fiwix is a preferable choice over linux, for both bootstrapping and as a general purpose kernel <aggi>yet up until when fiwix got networking support and usb maybe in between latest linux version monstrosities <aggi>linux-2.4 remains a decent option <aggi>if i can i am planning for y2038k patching it, to prolong it's life-span beyond <aggi>because it's much less lines of code, much easier to compile/link with an ANSI C type toolchain (such as tcc) <aggi>there's a chance even to re-introduce the x86_64 variant with it (if tcc and bootstrapping was fully confirmed) <aggi>since i got ready YASM in combination this does support related kernel asm bootcode/smp pieces <aggi>from my perspective (which too prioritizes bootstrapping), the key criterion is c-toolchain portability and fully detangling from llvm/clang/gcc/binutils/c++ dependencies <aggi>linux-2.4 too could support aarch32 and a few other ARCH, but _no_ RISC-V, and _no_ aarch64 <aggi>those recent architectures remain blocked from both kernel side and toolchain side with the necessity to upgrade to latest software versions <aggi>which are affected by other issues (related to c++ dependencies, excess lines of code increase)