<stikonas>fossy: should we remove mes rebuild since it's not really needed... <OriansJ`>Hagfish: well that is a noble idea, I much prefer that anyone with a little bit of time could create their own bootstrap seed (from either the hex0 files or from scratch) so that. That being said skipping the ELF header, the hex0 would fit in a tweet <Hagfish>yeah, i imagine that ELF headers are well enough documented out there that anyone who understood the tweet would know what was missing <OriansJ`>It might be well documented but unfortunately for some architectures, the documentation is entirely wrong (look at mescc-tools ppc64le e_entry for example) <OriansJ`>or armv7l where the instruction encoding documentation is wrong byte-wise ***gio_ is now known as gio
<stikonas>gforce_de1977: by the way, you can now do parallel runs with rootfs.py <stikonas>everything can run from a single checkout <gforce_de1977>stikonas: ok, but does not make sense with minikernel, it supports --repeat XX and --multi XX (and then the kernel is only compiled once), but thanks for mention it. <stikonas>anyway, that option is at least useful outside minikernel... <pder>stikonas: with the new python rootfs.py if I attempt to run ./rootfs.py --chroot I get env: ‘chroot’: No such file or directory <pder>I am on debian and chroot is in /usr/sbin, so I think that needs to be added to the path <pder>for me as my normal user "which chroot" returns nothing <pder>we are, so I am not sure. But adding PATH=/usr/bin:/bin to line 83 of rootfs.py fixes the issue for me <pder>sorry PATH=/usr/sbin:/bin <stikonas>pder: oh, that's because env clears environment <stikonas>which I wanted to do to avoid poluting bootstrap environment <stikonas>that's extra addition compared to rootfs.sh <stikonas>pder: perhaps the best way would be to resolve chroot path in python? <pder>that sounds reasonable to me <stikonas>probabably need to do it with sudo to work on Debian <stikonas>then we'll be able to find chroot, but also environment inside chroot will be reasonably clean <gforce_de1977>stikonas: bauen1: fossy: a did a "small" massrun (48 full runs), turns out that the already merged PR96 regarding "autom4te.cfg: No such file or directory:" was successful, so no issues regarding this. i will do a real massrun tonight and report tomorrow <gforce_de1977>gef: the 2klinux looks really interesting, but for now it looks a little bit like cheating, but maybe i'am wrong, have to inspect the binaries... <gef>of course, it's all midnight summer dream, until it happens :) <stikonas>the plan looks a bit strange though... it seemed to me that stuff like busybox is not easy to build <stikonas>maybe it can be done... but some things are easy to say in the plan but when you actually have to do them, it's not so easy <gforce_de1977>stikonas: and without peer rewiew there can be a lot of bad smell in there (cheating) <stikonas>e.g. might just use bison generated parsers, etc... <stikonas>anyway, there isn't much there beyong C preprocessor... <gef>(with a shrug posture) not sure what's going on. As a minimum the fs driver in Forth could be reusable across architecture, since forth is cheap to implement. That should get that ticked. <gef>am i right all the currently *working* code, is with the assumption that kernel/fs services are available? <stikonas>there is gio's asmc where this is not assumed, although it is a bit larger (15 KB if I remember correctly) <gforce_de1977>gef: the repo has my attention, but without deeper digging, i'am careful to say *thats-it* <stikonas>gef: actually, stuff from OriansJ` stage0 up to M2-Planet does not need kernel/fs services <stikonas>gforce_de1977: no, you don't need kernel to run those <stikonas>you can run it on stuff like knight architecture <stikonas>you feed the code in via e.g. paper tape <stikonas>anything else will rely on code to load stuff into ram <stikonas>whether we load it from some drive or something similar <stikonas>or whether we ask bios to load stuff from 1st sector <gforce_de1977>stikonas: sorry, and yes: you are right and i'am wrong. using the BIOS is really cheating, gef: thats a point! <gef>gforce_de1977: bootstrapping the kernel and having system calls appears to be a much harder problem (fyi. I am looking at this business one level lower (systems-wise) than you guys: namely, I'm investigating what kind of primitives the machine code should have to do the bootstrapping - it can get complicated with certain kernel services) <stikonas>gef: well, that's why M2-Planet is designed to run on baremetal without kernel. The plan is that a simple POSIX kernel might be compiled with it <stikonas>well, we only need some VFS in RAM and processes <gef>So, the fs driver is worthy of attention and might offer a crack on that part of the challenge: implement a rudimentary VFS? <stikonas>hmm, maybe. bauen1 might know more about this <stikonas>I think bauen1 said it's not too hard to implement some VFS anyway <gef>at some point, I'd like to setup the first gitlab pipelines to make the bootstrapping look more like a ci/cd process; to be clear: there is NO need to move git repos or code, just add a file or two; I know the ropes of gitlab to a level that should get things started, but I'd need to be tour-guided with the current bootstrapping itself <gef>ideally, I'm asking someone to spend 10-15mins by voice with me to put my attention to the right places. But there is no rush, it can happen this month or next month <gef>gforce_de1977: you might not have to, the ci/cd process should be the explanation for others. Ultimately it should make it visible to more eyes <stikonas>gef: don't we have ci process already... <stikonas>this describes basically all stepts live-bootstrap does <gef>stikonas: ah, yes. Somehow, I'd like to have an alternative interface, which is meant for people like me as consumers of the bootstrapping. The .cirrus.yml ci can continue doing what it is doing. <bauen1>gef: stikonas: gforce_de1977: i've written v3 of myunix (https://gitlab.com/myunix/myunix/) that includes a very decent vfs implementation with mount and symlink support, though there might be a few parts missing right now, and i could reimplement it again very easily now that i know all the pit falls <bauen1>imho the initial "kernel" bootstrap would probably start from hex0 -> a better hex monitor -> a first pseudo assembler -> a monolithic kernel / library ; all done in the hypervisor "ring", and then you start writing a microkernel <bauen1>with a microkernel you keep your pseudo assembler or other tooling there and gradually add better "infrastructure", e.g. a vfs instead of raw memory, a network driver to download more source code etc... <bauen1>gef: they only build (and rome some basic code linting) <stikonas>so how is it different from what live-bootstrap runs? <stikonas>there is also code linting and the whole thing runs <stikonas>and if you want to consume those binaries, you can even extract them from chroot <bauen1>we just need enough money to send everyone in this irc room to a remote island for a few months, along with an empty computer and a dozent books about x86 then the problem will solve itself <gef>(if you ask about the CI aspect: it is only presentation, to me it is more readable) <stikonas>you basically want another pipeline to do the same thing <gef>stikonas: it would be similar or a parallel build, let's say. Just an alternative interface to the same process, hoping gitlab ci would become attractive for others to explore <stikonas>it's best to run it yourself anyway, not in CI... You can run ir on your computer <bauen1>hm, i may have hit another spurious failure of gcc-4.0.4 related to autotools ...