IRC channel logs

<pabs3>adding Rust to git https://lwn.net/SubscriberLink/998115/1c2a7dd6c8607fd0/

<janus>it's interesting that .NET appeared after Java and still it seems less bootstrappable

<lilyp>it does seem like "modern" software cares less about bootstrappability than older one – consider kotlin, scala, etc. vs java for example

<stikonas>well, java was not always like this

<stikonas>it was not even free software initially

<stikonas>which meant people were trying to write some alternative free implementations

<stikonas>and those were very helpful for bootrapping

<lilyp>same with dotnet ironically

<kpcyrd>pabs3: I'm confused why the entire article seems to be written around some proprietary operating system I've never heard of

<sam_>because that was the main point of opposition

<aggi>x86 kernel bootstrapping and 16bit real-mode isn't bootstrappable

<aggi>in particular 16bit real-mode assembly

<aggi>to distinguish this further, it is two options available for this

<aggi>tccboot/jit (bellard) or linux-2.4/aot (not considering the tiny staging kernels/loaders of bootstrappable)

<aggi>either need 16bit bootcode, that's implemented with GNU assembly

<aggi>tcc itself fails with .code16, and even if it fully supported it, a circular dependency remained for itself

<aggi>with linux-2.4, SMP support introduces another piece of 16bit asm (trampoline.S), hence SMP would NOT be available with tccboot

<aggi>hence, smp/ioapic/usb may not be available with a bootstrappable kernel (whichever this would be)

<aggi>anyway, for linux2.4 i succeeded to salvage an almost complete kconfig, including smp/ioapic/usb

<aggi>but all 16bit asm remains dependent on binutils-as still

<aggi>nonetheless linux-2.4 can be supported with tcc

<aggi>with a few exceptions, a recent package set of ~500ebuilds too compiled/linked with tcc, against linux-2.4 api headers since recently

<aggi>i'll backport/re-integrate squashfs support into linux-2.4 today, to throw i486-tcc-musl-rootfs.squashfs at linux-2.4/tcc kernel

<aggi>AoT-compiled

<aggi>tccboot/JiT would provide a decent approach to bootstrapping, but it would exclude smp/ioapic/usb support for those x86 systems that need it

<aggi>depends where 16bit asm sneaks into the dependency graph, which options remain then, in practice

<aggi>and 16bit real-mode assembler was needed at two places: outside tcc for bootcode.S parts, and within kernel (trampoline.S) if smp/ioapic/usb was required (in practice, to access storage and peripheral i/o)

<aggi>earlier linux-2.x kernels implemented their 16bit asm differently, which was not GNU as syntax

<aggi>besides, fiwix certainly would need 16bit boot code too

<aggi>tcc itself gave up many years ago: https://repo.or.cz/tinycc.git/commitdiff/55bd08c5

<aggi>although a 16bit assembler separated from tcc would be needed (to avoid circular dependency)

<aggi>to my understanding, bootstrappable approached this by avoiding the need of such an assembler with hex0 loaders/kernel/utils

<aggi>*for

<aggi>realistically, a kernel bootstrapping path could be (simplified speaking) hex0 -> assembler needed for 16bit bootcode, compiler needed for tccboot/tcc and some userspace

<aggi>i don't see a realistic chance to fully support 16bit asm with tcc, hence any kernel compiled with it may not support smp/ioapic/usb

<aggi>which in practice, would exclude rather many real x86 hardware and it's peripheral i/o

IRC channel logs

2024-11-24.log