IRC channel logs
2022-12-06.log
back to list of logs
<stikonas[m]>I wonder if we skip checksumming, will we get the same error while untarring <stikonas[m]>rickmasters: and yes, good progress! And good that we were able to go from bison to GCC with very few problems <stikonas[m]>You'll probably finish bootstrapping Linux before I'm even able to finish stage0-uefi <stikonas>yeah, kaem.efi will have to do some of the things that kernel normally does <stikonas>it looks like UEFI has no concept of current working directory <stikonas>so I'll have to implement it inside M2libc <stikonas>I guess I can just prefix cwd when e.g. opening files <Hagfish>"ten packages away from building Linux." <Hagfish>personally, if i was experiencing a problem with checksumming large files, i'd be tempted to just split the file into chunks and provide checksums for the chunks <Hagfish>that's an ugly hack that probably breaks the consistency of the rest of the process, though <rickmasters>HagFish: There was a bug in Fiwix's ext2 filesystem for files > 64MB that I tracked down this morning. <rickmasters>I was able to get past the checksum but now I'm running into a tar error. <rickmasters>tar seems to be trying to create a directory before creating the parents first. <rickmasters>stikonas: it must be a kernel issue because I can extract the file system and run the same tar binary on the same tar file and it works fine <oriansj>or you discovered another lazy thing in Linux <rickmasters>oriansj: i'm comparing with linux and offhand it looks like linux is creating the parent directories but that doesn't seem right... <stikonas[m]>That is a bit strange. I don't think normal writes on Linux create parent dirs <rickmasters>oh nevermind, its probably tar creating the parents but only if it gets a specific error code, I think. <rickmasters>it looks like linux returns ENOENT but fiwix is returning ENOTDIR when the parent does not exist <rickmasters>ok, got past linux-headers and musl-1.2.3. Now rebooting on gcc-4.0.4 pass2. <rickmasters>I bet I also need to patch out set_thread_area from musl-1.2.3 ... <stikonas[m]>and in the worst case, we can actually stay with older musl <stikonas>oriansj: I think I now have a fix for a[0].b construct in M2-Planet <stikonas>I guess I still need to implement signed/unsigned load_value and more cleanup with loading values in general... <stikonas>it was an easy to overlook initially when I just tried to implement structs but the fix is almost trivial <stikonas>we already have a check not to do dereferencing of arrays when assigning, so just extended the check to also include dot operator <stikonas>well, still more work to do to clean up those new features... <stikonas>but let's test it in kaem and see if I can remove that hack <stikonas>maybe wrong type size (for calculating offset) is used in "device_path[1].type" case