IRC channel logs

<aggi>the kexec() transitions up until linux has one advantage in comparison to reboot

<aggi>because otherwise a reboot into linux obviously needs some capable boot-loader assembled and written to disk before some linux was loaded and populated device nodes

<aggi>there is not yet a ready-made solution known for this

<aggi>in the end, avoiding a reboot _before_ any fiwix/linux was loaded with kexec() and populated device nodes it is

<aggi>so far i preferred syslinux/isolinux as the final boot.iso target, and this too needs a linux runtime available before that could be rebooted into

<aggi>i think linux-tcc(2.4) does not need kexec() syscall implemented, when it is the kexec target

<aggi>device nodes with it are populated by devfs, which doesn't need any userspace daemon initially

<aggi>but initramfs might be necessary, if to my understanding the whole bh0 -> optional kexec_fiwix -> kexec_linux is done to keep that in-memory only without disk access

<Googulator>kexec targets don't need to implement kexec(), correct

<Googulator>but I was hoping to use linux-tcc as the "middle" kernel in live-bootstrap, replacing Fiwix

<Googulator>the "middle" kernel there needs to support either kexec() or real block storage to transition to the final one

<Googulator>with kexec() strongly preferred, as using block storage will necessarily mean a regression in real hardware support

<Googulator>since nothing can compete with modern Linux in terms of supporting real world block storage hardware

<aggi>keeping a rootfs inside ram (before any linux version was loaded) seems preferrable

<aggi>and such a rootfs must be available while kexec()/loading kernel, and thereafter to have access to the bootstrapped/compiled tcc.bin/make/coreutils etc

<Googulator>i.e. there will always be some oddball OEM motherboard with a fake JMicron SATA chip that mainline Linux's AHCI driver has a quirk for, but silently writes corrupted data with linux-tcc's one

<aggi>don't know how severe/common this problem is in practice

<Googulator>it's just an example for the kind of problem we might miss if we let a simpler kernel deal with block storage

<Googulator>but the elephant in the room is NVMe

<aggi>my reasoning was, to guarantee at least some block-storage and networking always (bare-metal of cause)

<aggi>usb-storage and usb-ethernet (the latter was a major headache with linux-2.4 so i'm glad at least this works in 10Mbps mode)

<aggi>asix ax8872 (usb1/2 variant), but even this one has become rare in online shops

<aggi>in any case, either linux-tcc or fiwix won't work with all hardware out there

<Googulator>yeah, but we currently use Fiwix in such a way that it never has to deal with hardware at all, other than for printing to the screen

<Googulator>a feature that's considered kind of expendable

<Googulator>black or garbled screen until the final Linux is loaded is acceptable

<aggi>thing is, the bootstrap up until bh0->fiwix->linux5 is solved already as-is

<aggi>since i'm haunting linux-2.4 still for shrinking the entire dependency graph, in this case i would want to avoid a situation like bh0->fiwix->linux5/gcc-> back to linux2/tcc

<aggi>bh0->fiwix->linux2 seems feasible, maybe bh0->linux2 even (if the in-memory only rootfs can be done somehow)

<Googulator>For mainline live-bootstrap, I'm hoping for bh0->linux2->linux5

<Googulator>(actually linux4, since linux5 needs a compiler written in C++)

<Googulator>hmm, but with linux2 replacing fiwix, maybe we can actually get a more modern GCC suitable for building a fully modern Linux in stage 2

<Googulator>and with linux2's better memory management, the size of that kernel is also no longer an issue

<aggi>the linux2->linux5 transition would be trivial (almost), because this merely covers the already available tcc->gcc4 bootstrap, and a regular kernel/bootloader compile/deployment

<aggi>at that point even the kexec/reboot would be irelevant

<aggi>confirming the whole linux-tcc inside chroot with tiny-bootstrap fork is a tad bit of work remaining

<aggi>but i'm a little scared of re-iterating over the whole kexec/memory-handling/in-memory-only rootfs (with bh0 and/or fiwix)

<aggi>furtheremore i do not want to encourage a live-bootstrap fork, because the current live-bootstrap does work, it's a decent solution as is

<aggi>and so far, once things are forked as i did for kernel, gentoo-portage, a little libc, userspace etc. etc. i'm left all alone with it

<Googulator>"a regular kernel/bootloader compile/deployment" - not in live-bootstrap

<Googulator>because live-bootstrap can't afford to rely on linux2's hardware support

<aggi>i was too thinking linux-2.4 could be a candidate for ultra-long-term availability (together the backported userspace) overall

<aggi>(year 2007 OpenBSD tried before with i386-pcc too, but it never gained attention and i haven't got time nor mental resources remaining)

<aggi>to retain some fallback *nix development host

<aggi>even when that's the most boring

<aggi>contacting universities and employers didn't yield anything, and i can't nor won't do it without

<notgull>.au

IRC channel logs

2026-10-07.log