<siraben>I feel like memory safety can be achieved after the fact. No. 1 goal is having the bootstrap in the first place, then one refines it ***terpri is now known as robin
<stikonas>fossy: that's for merging. And in the next stage0-posix version we'll also have mkdir, so we can remove all advance prepared empty mkdir calls <fossy>i'll attempt to push my kernel work this weekend. <fossy>now that 2nd busy session of the last two months is over, i should have more bootstrappable free time <stikonas>in the early bootstrap I still want to get rid of mes and tcc submodules <stikonas>running into some problems with mes though <clemens3>both links in the topic don't mention operating systems explicitly (if I am correct), is that because it is implicitly included, or some kind of omission? and if implicitly clearly included, what OS are you working towards.. guix or something smaller, or just way out in the future (sorry if there is already something out there that can be compiled from scratch).. <NieDzejkob>the goal is generally the typical open-source stack, i.e. GNU/Linux. <NieDzejkob>most people seem to be deferring dealing with the kernel itself as part of the bootstrap seed, if that's what you're asking <stikonas>in some sense it doesn't matter what OS, once you have GCC on one OS, you can basically build any OS <clemens3>yes, just wanted to make sure that is the end goal.. <clemens3>working myself on LFS and trying to go from the latest to older versions.. <NieDzejkob>LFS has quite a big bootstrap seed though, doesn't it ;) <clemens3>but atleast it follows the first rule, not to rely on itself.. and it is source all the way <clemens3>except java, rust, maybe go-lang (not officially part of LFS).. but atleast the java part you guys/girls seemed to have solved already.. <stikonas>clemens3: well, we can basicall bootstrap what is roughly LFS from kernel+357 byte hex assembler <stikonas>(with some minor gaps, e.g. g++ is missing for now) <clemens3>really, wow, didn't know you guys have come this far.. <stikonas>clemens3: kernel is big, but it might not be as big as you think <stikonas>probably something like 400kb might be enough <stikonas>basically we need process and VFS in RAM <clemens3>ok, you mean your own mini kernel to get to some minimal linux kernel..? <stikonas>well, either some mini kernel can be used (but somebody has to write it <stikonas>we only need a few things on top of linux'es allnoconfig <xentrac>stikonas: the problem isn't so much how many bytes of binary data is in the kernel, more how many pages of source code <stikonas>well, that depends on which kernel you use... <stikonas>but bootstrap process should not depend on kernel <xentrac>the kernel is certainly in a position to affect all your checksums <xentrac>I mean, there's a well-defined correct behavior for the kernel to have <stikonas>even in live-bootstrap we saw some differences <xentrac>but we don't have a way to verify that it has that behavior <stikonas>well, only using diverse independent kernels for now <xentrac>what kinds of misconfiguration have we seen? <stikonas>hmm, I think some differences in pipesize <stikonas>bash build system tries to determine pipesize using some small program that tries to fill the pipe <stikonas>so in live-bootstrpap we replaced that program with static #define PIPESIZE 65536 <xentrac>this is probably a stupid question I should grep the source for, but what's PIPESIZE? I guess not PIPE_BUF, which is normally 8192? <stikonas>hmm, not too sure, I thought it's how much buffer is allocated to pipes <clemens3>yes, and again, starting with an old kernel, and then stripping down.. <clemens3>should ask linus for some 0.93 versions or back to minux, once owned the real paper book.. <xentrac>why does the size of the buffer matter for the results of the build though? <NieDzejkob>well bash embeds it as a constant in the binary, no? <stikonas>well, it doesn't matter for bootstrappable purposes but matters for reproducibility <xentrac>reproducibility is important for bootstrappability I think <xentrac>they're not inseparable but it sure helps a lot <stikonas>well, that's why live-bootstrap does both <stikonas>it does not checksum all the files at the moment but it does checksum binaries <stikonas>text and data files are not done right now <xentrac>I've been thinking about what corners can be cut in a bootstrap-building kernel <xentrac>like, obviously we don't need epoll, 3c503 support, and NFS, right? <xentrac>I suspect that (as NieDzejkob's experience suggests) memory protection and some kind of interrupt support would probably save more work than they cost <xentrac>and some other similar debugging features <xentrac>but for example it might be adequate to keep the whole filesystem in RAM, at which point filesystem multithreading stops being very important <stikonas>xentrac: yeah, the whole filesystem in RAM should be fine <xentrac>(and it might not even be necessary to do real multitasking) <xentrac>on RISC-V a simple kernel should be a quite reasonable hobby project; if not an afternoon or weekend project, surely no more than a month <stikonas>live-bootstrap goes all the way till GCC inside RAM <stikonas>and at the moment build directories are not even deleted, so there are potential RAM savings for future