IRC channel logs
2022-12-23.log
back to list of logs
<oriansj>pder: I noticed strange behavior in your unbz; ./bin/unbz2 -f unbz2.c.bz2 -o unbz2.c results in exit code of 1 but the resulting output does have a matching checksum <stikonas>otherwise it's somewhat tricky to ignore it <stikonas>would have to wrap it in another kaem script that we run with non strict mode <oriansj>it appears to be exiting in do_bunzip2 because err was -6 <pder>oriansj: thanks for reviewing, I will take a look <fossy>stikonas[m]: are you ok with a global SOURCE_DATE_EPOCH=0? python is finally modern enough software to respect SOURCE_DATE_EPOCH for a few things in its build <oriansj>pabs3: I've been thinking deeper on your question. And I feel that the video you posted is more about how modern firmwares are effectively operating systems; in which the answer is to eliminate firmware that functions beyond an extremely limited let of essentials <pder>oriansj: I fixed the return code issue and ran astyle and pushed to the unbz2 branch. The return code problem was due to me reusing the i variable in the for loop when freeing, so the function was always returning -6 <pder>Let me know if you want me to squash the changes <oriansj>pder: well I leave that up to you, just let me know when you are ready for me to pull and merge <pder>oriansj: I just created a new pull request <rickmasters>pder: thank you for the contribution! That should allows us to build tcc-0.9.27 from its original bz2 package without repackaging/rehosting as gzip. <rickmasters>stikonas: regarding tcc-0.9.27, there is a already a kaem file (make not needed) but it relies on patch ... <rickmasters>patch has a very simple Makefile so it shouldn't be difficult to use kaem commands instead. <rickmasters>also, there is a sed command used to remove some lines from a source file. That could also be replaced with a purpose built tool. <rickmasters>So, I'll try to build tcc-0.9.27 right after tcc-0.9.26. <rickmasters>Sorry, I mean tcc-0.9.26, then patch, then tcc-0.9.27 <stikonas>rickmasters: I think it would be easier if you build tcc without patches <stikonas>and then continue by building patch and patched tcc 0.9.27 <stikonas>which adds 1 extra build step but not much more complexity <stikonas>but we'll reduce number of steps before fiwix <stikonas>first tcc 0.9.27 patch just removes needs to call it with -static flag <stikonas>hmm, I don't remember exactly why 2nd patch is needed, but there is a comment <stikonas># Note that tcc includes static-link and ignore-static-inside-array patches since we do not build from clean checkout. <stikonas>rickmasters: do you think it will be easier for you this way? <stikonas>pder: are you going to update stage0-posix and live-bootstrap? <rickmasters>stikonas: It looks easy either way. I did change a couple lines to build Fiwix but that doesn't need patch. I can probably skip patch. <stikonas>(if not, I can do it at some point later) <rickmasters>stikonas: I'm not sure pder would need to change live-bootstrap much, I could make the change for tcc and we could continue to build bzip2 normally. <stikonas>well, at the very least one has to update stage0-posix submodule <stikonas>I might take a look at updating it this weekened if pder doesn't do it before that <stikonas>we can first just update it to build unbz2 <stikonas>and then you can make other changes as you need them for fiwix <stikonas>I'll probably move tcc 0.9.27 earlier too <stikonas>with availability of unbz2, there is no reason to build tcc 0.9.27 later <stikonas>and we get some early stuff built with newer compiler <rickmasters>So, I have good news. I've been using gcc to build Fiwix. Yesterday I got Fiwix to build with tcc-0.9.27 and it drove live-bootstrap through to Linux! <rickmasters>This was tcc-0.9.27 outside of live-bootstrap and so I'll be working on building inside live-bootstrap next. So this discussion is timely. <rickmasters>And just confirmed it was tcc-0.9.27 unpatched so I think we're good without the patches. <stikonas>well, static patch doesn't apply to kernel anyway <stikonas>you can't have dynamically linked kernel <stikonas>(and it was just to remove the need to specify -static for all compile commands) <rickmasters>(Unpatched except for a couple lines I changed - a bug fix and a linker hack). <stikonas>and I think the 2nd patch is not used till much later <stikonas>and then I guess kernel transition / fs work... <rickmasters>Yes, I'll try to transition to Fiwix after building it, and the Linux transition will come later as the final step <rickmasters>fossy asked about where to find my work - today I'll try to commit all my Fiwix changes to my fork on github then I'll work on upstream PRs. <Hagfish_>this is such an exciting time for bootstrapping. for the first time in decades, we can almost say that the only space for a trusting-trust attack is in a few hundred bytes of binary (or firmware, or hardware). i'm hopeful that next year, those areas will get more attention too <pder>rickmasters: glad it will be useful. Thank you for all the work on the kernel bootstrap. Exciting times! <pder>stikonas: I have started updating stage0-posix <pder>Its not clear to me if I need to update checksums for all architectures in stage0-posix since I need to update the M2-Planet submodule <pder>how do you normally go about updating all the *.answers files <oriansj> Hagfish: well they have already started to get attention on the firmware (libreboot, openBMC, etc) and hardware (opencores, libresilicon, etc) the question becomes when and how do we link up with those <oriansj>pder: look at the makefile (hint Generate-${ARCH}-answers: ) <pder>ahh- so I dont actually need to be to run on different architecures? <oriansj>(it is easiest if you have qemu userspace virtualization) <oriansj>if you wish to test for those architectures <Hagfish_>oriansj: yes, those are just the sort of people whose contributions would be valuable. you're right that linking up with them is tricky, but you've done an amazing job of community-building so far, so i'm confident that things will continue to grow <pder>if for example I want to bootstrap-seeds/POSIX/AArch64/kaem-optional-seed, do I need to do this within a AArch64 distro running in qemu, or is there another way? <stikonas>pder: no, user space emulation just runs on your distro <stikonas>it's basically a transparent running of aarch64 binaries on x86 <stikonas>in order to be able to use it, you need to install qemu and configure binfmt in /etc/binfmt.d/ <stikonas>but basically, 1. install qemu. 2. Put config files into /etc/binfmt.d/ (or your distro might do it for you already when installing qemu) 3. systemctl enable systemd-binfmt; systemctl start systemd-binfmt <stikonas>ok, so that debian wiki should have exact steps <pder>cool, thanks, I will give it a try <stikonas>and debian even ships update-binfmt helper, so it should be fairly easy <stikonas>I had to copy in config files like :aarch64:M::\x7fELF\x02\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\xb7:\xff\xff\xff\xff\xff\xff\xff\xfc\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff:/usr/bin/qemu-aarch64: <stikonas>and once qemu is configured, run "make test-aarch64" in stage0-posix <stikonas>it will run the seed and will also checksum results (so once checksum will be calculated using sha256sum from mescc-tools-extra and then make will also launch external distro sha256sum) <pder>are you able to test all architectures that stage0-posix supports? <pder>I wasn't sure about knight <stikonas>pder: I think so, knight is not in stage0-posix <stikonas>I tried testing knight-posix recently for M2-Planet tests <stikonas>(you just need to build ./vm from stage0 and it runs there <stikonas>but we don't have anything like qemu-user for knight-posix <stikonas>pder: so basically you need x86, amd64, aarch64, riscv32 and riscv64 <stikonas>there is no armv7l support in stage0-posix right now <duplexsystem>Does anyone know of a way to bootstrap clang without GCC? <stikonas>duplexsystem: there is none as far as I know <stikonas>and so you need to find some other bootstrappable C++ compiler that is not GCC <Hagfish_>thanks for sharing the "civboot" project! <Hagfish_>they have some interesting goals, including "Photo Optics (lenses) fabrication and working knowledge." <Hagfish_>sadly it seems that so far (after three years) their main achievement is coming up with a new programming language <stikonas>yeah, I'm not sure if new programming language is that helpful, we already have a fairly good bootstrap in stage0 <Hagfish_>yeah, and it doesn't look like they're planning to use their system to bootstrap the extensive corpus of existing free software, but that doesn't mean there isn't overlap between our goals and theirs <rillian>Hagfish_: is this the solarpunk/ceramic path to hi-tech for people who can no longer access fossil fuels? <Hagfish_>hmm, it's not clear whether they are expecting it to be useful after a disaster, but i guess "no longer access fossil fuels" could happen for lots of reasons, some of which their project is suited to <rillian>re cpu, does the bootstrap sequence fit in 24 bits of address space? <rillian>stikonas: I suppose so. and an operating system under it. <stikonas>well, at the very least nobody has done any work on it. So in theory should be possible to do it, but in practice we don't have much <rillian>was just thinking about the 'running on your own relay computer' aspect of it. <stikonas>rillian: in fact we only have bootstrap chain to gcc on x86, not even amd64 <rillian>stikonas: ah. because mes+tcc output x86 only? <stikonas>I guess mescc can output some other stuff <stikonas>but patches for tcc 0.9.26 only work for x86 <stikonas>it would be nice if somebody could get more than just x86 <stikonas>in particular amd64 bootstrap would be good to have too <stikonas>you'll have to rewind clock or fix all Y2K37 bugs <rillian>well, yes. But I was thinking if you wanted to connect to some kind of audited hardware there's still something of a gap between something individually comprehensible like an 8-bit cpu and what a posix system capable of linux+gcc <rillian>or how much you'd need to trust MB of storage <oriansj>drakonis: yes they look like they might be onboard with our goals, I should reach out to them <drakonis>plus getting somebody zig adjacent might be better <oriansj>rillian: well we could port cc_x86 to an 8086 and CP/M if someone was interested in that work <oriansj>also 24bits of address space is enough for a POSIX kernel and a full development (as was done on the 68K systems in the 80s/90s) <oriansj>a 386 is just much easier to program and if one opts to, can ignore most of the ugly bits of x86 <pder>oriansj: I just sent you a pull request for mescc-tools-seed. This updates M2-Planet, M2libc, mescc-tools-extra to integrate unbz2 into the build <stikonas>yes, and amd64 is even easier to program, one has access to easy position independent code there <oriansj>not to mention 16 registers instead of 8 <rillian>oriansj: CP/M is an interesting idea! <oriansj>rillian: well DOS has been discussed; unfortunately no one published such work <stikonas>there was a typo in commit but oh well... <stikonas>pder: nice work! Just tested unbz2 on tcc-0.9.27.tar.bz2 tarball <stikonas>janneke: you might want to be aware of this too: stage0-posix now has unbz2 program, so we are not restricted to .tar.gz anymore <stikonas>oriansj, pder (cc fossy, rickmasters): we have some issue with live-boostrap update <stikonas>lib/m2/time.c:31: Got unsupported size 8 when trying to load value. <stikonas>which probably means that some of my M2-Planet updates that I did for UEFI bringup have some bug <stikonas>hmm, it's not happy with "r = _sys_call2 (SYS_gettimeofday, tv, tz);" and things that we have 64-bit value on x86...