IRC channel logs

<fossy>jleightcap: have you seen https://archive.fosdem.org/2023/schedule/event/rv_selfhosting_all_the_way_down/?

<fossy>jleightcap: there's "unrealistic to develop" and "unrealistic to run for most people"

<fossy>"unrealistic to develop" for me would be any more than a couple weeks

<fossy>but it could be a lot shorter than that - e.g. i'm going to have very little patience if my feedback cycle is >1 days

<fossy>"unrealistic to run for most people" depends on what you're building, but i would say more than 24-48 hrs

<jleightcap>fossy: yes! i'm continuing this direction doing homebrew cpu / building an fpga

<jleightcap>good point about developing versus using

<fossy>very cool!

<jleightcap>bootstrapping on a laptop aiming for a gnu+linux DE/WM is very fitting

<jleightcap>for much slower runs the "most people " 1-2 day limit might need a more humble target

<jleightcap>maybe in that time it would be possible to bootstrap and establish chain of trust for just gcc

<jleightcap>but just sketching ideas now, i'll have about 10 weeks to work on this

<jleightcap>maybe more, related nlnet proposal is in the last round of its call

<jleightcap>thanks for the thoughts i'll, will continue hanging out / lurking here ^^

<fossy>right, that's why i say "depends on what you're building", if you're knowingly using ancient or slow hardware adjust accordingly :)

<fossy>or if you're building a whole DE etc ofc that will be more again

<fossy>but i don't see a average person waiting e.g. a week to build gcc

<jleightcap>hm could be variable, establish chain as far as you have time for

<jleightcap>estimated timing though, as long as it's not just blindly waiting

<stikonas>well, even if you forget bootstrapping, just compiling enough stuff for source based distro, e.g. Gentoo can take a few days

<Guest91|2>About the the cdq instruction in hex0_AMD64 I mentioned recently: the comment right next to it and the code for hex0_x86 confirms this is indeed a bug and the file descriptor should be sign extended instead of an uninitialized register

<Guest91|2>There are also two unnecessary instructions: the one zeroing mode before the first open call (removing would be consistent with hex1, which skips the zeroing), and the xor_ebp,ebp instruction. That last one would not only remove 2 bytes but also a jump target, which would untangle the whole thing nicely.

<Guest91|2>Finally, I still believe the first instruction should be pop rdi instead of pop rax to improve readability, though that's minor and debatable.

<Guest91|2>Correction: that first cdq zeroing mode cannot be removed, but it's not there to be "extra sure" during the first open call (O_RDONLY, mode argument ignored), but to zero the upper bits of the mode argument for the SECOND open syscall. So the instruction should be moved down, or the comment changed.

<Guest91|2>Another way to clear upper bits of rdx would be mov edx,448 (5 bytes, but 1 byte cdq can be removed) instead of mov dx,448 (4 bytes)

IRC channel logs

2025-10-18.log