<warren>It seems this should be acceptable to Guix because it's from the clean mrustc bootstrap <vagrantc>i think the core should be internally consistant, bootstrappability-wise <vagrantc>but i'm not sure what more involved opinions would say :) <warren>I'm told that mrustc bootstrapped rustc has been shown to be capable of being bit-for-bit identical to upstream bootstrapped rustc. That could be demonstrated here again. <OriansJ>xentrac: the file-system bootstrap problem is all tools for making file-systems only run on operating systems and all known operating systems require an existing file-system to run. So to bootstrap any known operating system you need the ability to make a file-system (that is supported by that operating system) and populate it with the kernel and other essential pieces before you can use said operating system. It is a problem because no <OriansJ>one has made those tools run on bare metal yet. <OriansJ>warren: to answer your question about stage0; we are a single program away (mes-m2) <OriansJ>mes-m2 already is buildable via various C compilers but there a couple C features that need to be added to M2-Planet and some changes to mes-m2 to get it buildable via M2-Plaet. Once that is done the path from stage0 to gcc will be done <OriansJ>full bootstrap from hex0 to M2-Planet + mescc-tools <warren>OriansJ: please confirm is my understanding correct ... stage0 starts as a 1KB hex assembler but it needs to run on an existing OS that handles the filesystem? <OriansJ>warren: 357byte hex0 assembler for the linux port 250bytes for bare metal <OriansJ>bare metal does not depend on any bios or firmware <OriansJ>that I am going to implement in first FPGA and then in TTL <OriansJ>Thus using librehardware as an absolute basis of trust <OriansJ>I however am currently planning on pulling mes.c's dependence on mescc-tools to reduce the number of binaries in the guix bootstrap down to exactly 1 (mes-m2) as when it is done it will be able to directly run the mescc-tools scheme version, MesCC and ideally guix. Thus reducing the distributed binary down to 200KB with a 357byte bootstrap <OriansJ>warren: also one thing you might want to notice is that M2-Planet + mescc-tools currently is not only reproducible but also cross-platform reproducible (aka aarch64, armv7l, x86, knight and amd64 hosts building all of the platforms produce bit for bit identical binaries) <warren>So theoretically after the bootstrap from this to gcc is complete, it would be true that it is proven to not be compromised? (at least not by anything outside of the source code) <OriansJ>warren: well one has to validate their hex0 binary corresponds with the hex0 impementation of that binary (takes about 40 minutes) then every step of after that can be inspected using only source code as none of the tools in stage0 use anything but passed input (source code) <OriansJ>as otherwise the behavior wouldn't be identical between the linux port and the bare metal port <OriansJ>and the hardware only assumes 3 serial ports, 1 cpu and a specified amount of RAM <OriansJ>(no firmware, no bios, nothing but pure hardware) <OriansJ>(on the bare metal port as the linux port just uses file handles per standard posix calls) <OriansJ>and if you notice; stage0 doesn't even depend upon trusting existing source code files [It bootstraps SET to allow read/create/write of source files] Thus one can know what binaries are being given <OriansJ>now there is always the possibility that the hardware itself or the posix kernel it is running on could compromise the binaries but I have engineered it such that such a compromise can easily be discovered once one has a trusted kernel and trusted hardware <OriansJ>as the steps of trusted hardware with a trusted kernel should produce identical binaries with all other hardware in the world. If there is a deviation of even a single byte; we know something is wrong. <OriansJ>warren: hopefully that answers your question exactly. <OriansJ>also you'll notice the entire x86 bootstrap is only a total of 7,929 lines to audit before M2-Planet self-hosts itself and mescc-tools from the much easier to audit C code. <OriansJ>(4974 of which is the C compiler written in assembly and 869 is the macro assembler written in hex2) which includes the 330line kaem.run script (which is just the steps of build everything) <vagrantc>yup, guix build rust failed at build rust 1.19 <warren>vagrantc: who to ask if cross-build from one arch to another would be acceptable, because it's impossible otherwise? <vagrantc>warren: probably ask in #guix civodul or rekado or on guix-devel@gnu.org ***ChanServ sets mode: +o rekado
<OriansJ>janneke: after much thought; I am going to be removing a couple of the implicit assumptions of mes.c from mes-m2 <janneke>OriansJ: what have you seen, been thinking about? <OriansJ>first I am pulling the loading of boot-0.scm and removing the entire argv chunk out <OriansJ>So, it is going to be ugly for a bit until I fix it <OriansJ>Then I am going to rework your lisp reader to first read the S-expression as a text block (allowing for easy inspection and debugging) before tokenization and manipulation <OriansJ>Then I'll figure out what to do from there <janneke>i have been rewriting the boot sequence so many times... <OriansJ>looks like I can put it in a form where it can stick for a long long time <janneke>this was the best i could come up with, but i also was fed-up with changing it and i was still not happy with it <janneke>the reader also saw quite some rewrites -- i had a minimal s-expression reader in C and then a full scheme reader (quote, # etc) in scheme <OriansJ>well, I hope I can make it to the standard you will be happy with ^_^ <janneke>far too clever, not really helping... <janneke>it's so amazing that you are looking at this, really <OriansJ>I said I would, I just had to overcome the wall of "I have no idea how this works" and be in a place where failing is easier and faster <janneke>btw, what's the plan with temp.c/good2bad and the weird capitalizet GetSCM etc? <OriansJ>it was just a placeholder so I could get mes.c into a place I could sorta figure out what I was doing <janneke>that's what i thought, i just wondered why it was "lingering" around still <OriansJ>because I was still trying to figure mes.c out <OriansJ>Now I am at the stage of building up breaking assumptions <OriansJ>I'll be writing tiny tests and slowly getting everything to a place I like <OriansJ>now that I am able to use cgdb effectively with mes-m2 <OriansJ>I can start drilling down into individual primitives and ensure my assumptions about behavior matches guile <janneke>ah yes, i have been giving that some thought... <janneke>actually, guile is built using (a heavily modified) psyntax, are you familiar with that setup? <janneke>i tried some things with psyntax, but did not fully get it working and also it's not bootstrappable that i know of <janneke>so it's about 30,000 lines of pretty primitive scheme, lambdas mostly, gensym and some hooks to register flavours of variable <janneke>so...if we really want to go 100% guile compatible, we should aim to load guile's generated psyntax.scm <OriansJ>be able to run the human written guile used to generate psyntax.scm and thus eliminate that bootstrap problem <janneke>i went another route, only supporting the simpler syntax-rules and and create guile compatibility "by hand" in the .c and .scm libraries <janneke>yeah, i would like that; and like to help <janneke>but first i'm going to concentrate on the scheme-only bootstrap with guile <OriansJ>and I'll try to finish up the M1 in scheme this weekend; so you can use that to eliminate all binaries except guile from the bootstrap binaries <OriansJ>thus we will have a single binary bootstrap for you to clean up while I have time to hammer through mes-m2 to the point of it being able to be built by M2-Planet and then I'll work to extend it to the degree we can be a drop in replacement for guile <OriansJ>So what I am going to do is commit the currently ugly state, so you'll be able to see and feel what I am currently playing with (along with anyone else who wants to get dirty) <OriansJ>(I've tagged the commit prior to the change should we wish to later use it as a placeholder for mes-m2) <OriansJ>and I am making a change which will ensure you'll know if you are working on a primitive or something built ontop of the primitives <OriansJ>(basically prim:thing for all the mes-m2 primitives) <OriansJ>hopefully I have something more fun to look at when you wake up. Sweet dreams janneke