IRC channel logs
2026-01-07.log
back to list of logs
<aggi>concerning posix shell, something else crossed my mind with regards to bootstrappable and the tinycc-driven distribution i'm hacking <aggi>that is system-integration tooling for packaging relied upon, with python/portage/bootstrappable-scripting and perl/autotools <aggi>neither perl nor python are covered by POSIX standardization, and the system-integration tooling is extremely complicated <aggi>in this context, both POSIX shell and POSIX make are relevant, because limiting workflow to such tooling can greatly simplify the dependency graph <aggi>that's something suckless.org are approaching, sabotage linux (and oasis-linux who chose non-posix lua), simplifying their build-systems _without_ python nor perl involved <aggi>and i've had alot of trouble with retaining a tinycc-compiled/linked perl.static and python.static in a cross-compilation setup <aggi>while posix make and shell were easily compiled/linked <aggi>although thats a completely different concern than pnut-sh targetting posix-sh as emulation-host <aggi>nonetheless it's a reminder of the dangers involved with shell 'eval' <aggi>meanwhile i continued hacking linux-tcc (linux-2.4) kernel for extended hardware support <aggi>made a little progres, improved sata/ahci hard disk support, meaning most controllers could be driven by generic ahci.c from linux-2.4 kernel still <aggi>which is alot faster than usb2/flash-memory or cdrom <aggi>and, i've debugged the backported ASIX8872 rev. a/b/c usb-ethernet dongle support with linux-tcc kernel <aggi>i'll do another complete runtime testing by re-compiling the distribution with this latest kernel, seeing to there's no more kernel panics <aggi>finally, we might have a tinycc/bootstrappable kernel with decent hardware support <aggi>this kernel too can be driven by the original tccboot (bellard.org) JiT compiled, although i'm doing regular nightly builds AoT currently <aggi>a JiT compiled linux-tcc kernel could not yet support SMP because that needs 16bit real-mode asm support for trampoline.S which tcc can't digest <aggi>AoT it's a non-issue because i can utilize binutils-as for the two microscopic pieces of bootsect.S and trampoline.S to pre-compile those two separately before linking <aggi>anyway, i'll cleanup the asix.c usb-ethernet backport today to commit that <aggi>it's been one major technical blocking for release, to provide a bootstrappable/tinycc-driven complete GNUish/POSIX system with sufficient hardware support, inside virtual machine but most importantly too bare-metal <aggi>given this, the original tccboot could be worth a discussion for bootstrappable, because this can drive a linux-tcc kernel, as said, hardware support is decent <aggi>i don't fully grasp the reasoning behind pnut-sh yet, although it's fascinating <aggi>because, an acceptance criteria of bootstrapping implies avoiding build-time "circular dependencies" <aggi>yet, all POSIX shell interpreters known are written in C, compiled by a C-compiler etc. <aggi>so, bootstrapping a C-compiler and written in shell introduces just this, another circular dependency <aggi>theoretically, if any posix-shell interpreter was implemented in assembler, pnut-sh would be plausible with regards to bootstrapping <aggi>for practical reasons, it's fascinating nonetheless, to spawn a c-compiler from and with posix-shell as initial emulation host <Googulator>Also, this makes C<->Posix shell a similar "mutual bootstrapping" pair to Mes's C<->Scheme <Googulator>Plus, there's also pnut-exe which is a straight C->I386ELF compiler; far more useful for bootstrapping <Googulator>now, if pnut-exe can compile a Posix shell that can host the output of pnut-sh, that would open up some additional interesting bootstrap paths. <lanodan>I guess a candidate shell would be OpenBSD ksh (only non-experimental shell I found that can be compiled without already having a shell) <aggi>didn't think of this before, what a coincidence, i did pull in oksh as main system shell into the tinycc-driven distribution for other reasons already <aggi>it's a matter of priorities <aggi>and a major concern i see, is the system-integration tooling python/portage and perl/autotools, too bootstrappable is using python <aggi>it's not covered by POSIX, it's not easily bootstrapped, it's not easily supported with tinycc <aggi>POSIX shell and make are much less headache, but would require a _complete_ re-write of packaging <aggi>thing is, live-bootstrap does work, even when it needs python, and a re-write isn't worth the effort <aggi>same with python.static/portage that i managed to self-host with tinycc, it does work <aggi>and a rewrite of packaging is an all-or-nothing, doing it gradually isn't plausible because then i had to maintain two packaging systems in parallel <aggi>same with autotools/perl, although this could be done gradually, but it's even more efforts to do it <aggi>and, i intended to keep broad test-coverage compile-time and runtime testing of tinycc, hence it is ~500 ebuilds supported already <aggi>fully detangled from GNU/gcc and/or llvm/clang <aggi>and of cause, the tinycc-driven distribution can both be bootstrapped itself, and be used as bootstrapping/cross-compilation host itself <aggi>to spawn gcc and a recent kernel version with, on a powerful development host that the tinycc-driven distribution is <aggi>i've hacked into asix.c usb-ethernet again, no more kernel panics, so far, sigh... this was notable headache too <aggi>because, that's the key difference to fiwix-kernel: hardware support <aggi>and that's no trivial thing, knowing some cheapo usb-ethernet dongle is available and it just works, with real hardware <snuik>LaurentH, you have 1 message <snuik>LaurentH, janneke says: congrats, kudos, and tanks for sharing! <LaurentH>civodul: we agree! We think pnut could be used to reduce the size of the Guix bootstrap seeds since it includes a bash executable from which every other binary could be produced <LaurentH>aggi: pnut doesn't use `eval` anywhere, that was one of the challenges when compiling C to shell <aggi>LaurentH: i've already cloned pnut last year when it was first mentioned here <janneke>LaurentH: have you (thought about) sending your thesis to the rb-general and bootstrappable mailing lists? <LaurentH>aggi: regarding the circular dependency between the shell and pnut-sh, the idea is that there are so many shell implementations that were independently developed, that you can use diverse double-compilation (i.e. bootstrap from many different shells and compare the results) to prevent trusting trust attacks <LaurentH>We could definitely implement a POSIX shell (the subset required by pnut) in assembly, but using pnut-sh.sh as the seed means we have the same seed for all platforms <aggi>by no means should anyone implement a (complete) posix shell in assembly; it's merely a hint to circular dependency issues <aggi>due to this, bootstrappable hacked their kaem script interpreter <LaurentH>Pnut-sh only uses a small part of what the POSIX shell standard requires, so it may be in reach <aggi>and if pnut addresses toolchain-trust, that's accomplished if pnut can spawn a c-compiler <LaurentH>Thought it was some other project, makes sense <aggi>you could trust a c-compiler/toolchain spawn from pnut-sh, even when this didn't cover a full bootsrapping chain without circular dependnecy <LaurentH>But then to use this trusted compiler you'll likely use some kind of shell, which you also need to trust, so it's better to bootstrap from the shell in the first place <LaurentH>Bootstrapping from the shell isn't fast, so I could see pnut being used to gain trust in some other compiler <LaurentH>pnut can reproduce live-bootstrap's TCC binary, so there's already that if you want to trust TCC <aggi>yes, i have not re-confirmed live-bootstrap myself yet, for the tinycc-driven distribution i'm hacking <Foxboron>LaurentH: Using POSIX sh for DDC is a clever hack, nice work <aggi>and pnut could provide an alternative/comfortable way of spawning tinycc, without doing the complete live-bootstrap <sh4>the amount of ingenuity that went into pnut is quite amazing <sh4>unfortunately the HN link didnt get traction, and it's probably already too late <Googulator>What features would Kaem (the full one written in M2-compatible C) need in order to interpret Pnut scripts? <stikonas>Googulator: probaly almost full POSIX shell is needed <LaurentH>Pnut-exe can be bootstrapped from M2-Planet, so no need to use kaem to bootstrap pnut-sh <aggi>pnut-sh cannot target kaem as emulation host, that's not directly related to bootstrapping, but the size of a circular dependency graph introduced <stikonas>I guess the biggest wishlist for pnut would be support for more arches <aggi>can pnut-sh be compiled with mescc (before tcc) - probably <aggi>but if pnut needs a posix-shell interpreter as target emulation host, then bash-2.x had to be compiled with mescc too, _before_ tinycc was available <aggi>if this was the idea to avoid a circular dependency <aggi>other than compile-time dependencies, a posix shell too needs a runtime itself, atop some kernel/libc - this probably implies presence of fiwix kernel that too was compiled with tinycc <aggi>which pnut can't have spawn at that stage