IRC channel logs
2021-09-21.log
back to list of logs
<oriansj>this CPU supports RV64IFMAD and depreciated instructions v1.0 1.1 and 1.2 sort of thing <oriansj>That way everyone has 20 years to stop using an instruction before its opcodes become available <stikonas>fossy: live-bootstrap readme still refers to binaries in /after/bin... <stikonas>I haven't ran live-bootstrap right now... <stikonas>remaining things are mostly variables and some minor things like [] and -> <oriansj>So live-bootstrap is just a short path away from building the guix bootstrap tarball <stikonas>might be nice to build newer binutils/gcc... <stikonas>well, there is that autogen issue, we can't rebuild top level gcc/binutils configure files but they are not essential <oriansj>certainly would enable a much faster bootstrap tarball for guix and a bootstrap without any cheating. <fossy>stikonas[m]: oh, yes. I will fix that in the next PR. <Hagfish>can you list some milestones along that short path? <Hagfish>also, is there a chance that the guix community will publicise the achievement when it occurs, to raise awareness for people who might want to contribute here? <oriansj>possibly as they have previously published in the past; however I am uncertain how the having to walk back the last post about full source bootstrapping when there was a massive guile blob in the mix <Hagfish>hopefully the make version is sufficient <Hagfish>yeah, the guile blob sort of complicated the story <oriansj>if not civodul, janneke and rekado are here and guix developers <oriansj>but no blob (except a kernel) is certainly a great step forward. <oriansj>Removing the kernel blob is going to require a bit more work; removing the bios blob and the microcode blobs basically require us to build our own hardware. <Hagfish>yeah, i think the latter steps are really at the cutting edge of what's even being attempted <Hagfish>but it's good to see there are projects in that field <Hagfish>was there a plan to use tccboot to replace the kernel with a small bootloading compiler? <Hagfish>i'm assuming the compiler is smaller than a minimal kernel, but maybe that's wrong <xentrac>depends on the hardware but I've never seen a machine where a minimal kernel would be 100K! <oriansj>well a minimal kernel could easily be under 64KB <xentrac>Linux is humongous largely because of all the drivers for hardware I don't have <oriansj>we only need hard drive drivers and maybe ps/2 or COM keyboard <Hagfish>yeah, i guess the question of "how big is the kernel?" has the answer "it depends" (like all good questions), because the answer can be hardware-specific <oriansj>only needs to support single core and single tasking <oriansj>so basically not much more than BootOS that exists in 510bytes <xentrac>you can do IDE PIO in a few lines of code <oriansj>only a proper filesystem and a handful of POSIX style syscalls <oriansj>xentrac: skip USB entirely when bootstrapping until after Linux <xentrac>a minimal kernel doesn't even need POSIX syscalls, just an IPC mechanism that allows a POSIX server to handle syscalls <xentrac>of course then you have to write the POSIX server but you might be able to write it in, say, Scheme <oriansj>xentrac: scheme bootstrapping is much harder than C bootstrapping <oriansj>which mes-m2 can't run and MesCC can't run on <xentrac>but you wouldn't have to add much to Ur-Scheme to write a POSIX server in it <oriansj>I wouldn't have to add much onto BootOS to have a minimal POSIX either and bootstrapping Assembly is much easier. <xentrac>the approach I'm taking with Qfitzah is that maybe an interpreter for a higher-level language than Scheme can be smaller if it doesn't have to be efficient <xentrac>bootstrapping assembly is definitely easier <oriansj>but writing a full kernel in Assembly tends to be quite unportable <oriansj>So it presents a problem: Get M2-Planet running with BIOS calls or do something unportable to solve the kernel bootstrap problem. <xentrac>well, the parts that *really* need to be in the kernel also need to be nonportable <xentrac>I mean you need thread switching, SMP setup, system call handling, interrupt handling, and, if you're using protected mode, page table setup <oriansj>well minus kaem doing fork; there isn't any thread switching and just programs running to completion. <oriansj>So instead of a process queue, perhaps a process stack? <oriansj>run until fork. push onto stack and run forked process to completion. Pop off stack and continue running until completion. <oriansj>which is good enough to get us to M2-Planet and whatever kernel we bootstrap from there. <oriansj>perhaps I'll just punt that problem until I know more about writing and bootstrapping a Kernel <oriansj>unless bauen1 has something of interest to share for dropping our bootstrap kernel requirements <xentrac>yeah, for running a build batch job you don't really need thread switching <xentrac>except in the sense that when a process terminates you need to switch back to some other process <xentrac>but thread switching is really very simple. you save all your callee-saved registers (including SP and the return PC) in a struct, then overwrite them with values loaded from a different struct <xentrac>you have to save them anyway on system call entry if your kernel isn't itself multithreaded <xentrac>I mean, you have to save them anyway on system call entry. If your kernel isn't itself multithreaded, that's all you have to do <xentrac>(assuming the kernel is protected, anyway)