IRC channel logs
2024-02-12.log
back to list of logs
<stikonas>oh I think there is one more issue with uefi/M2libc, we need to implement truncating files on opening <stikonas>cp bin/mes-m2 bin/mes and later mescc -o bin/mes ends up with too big file <Googulator>yeah, builder-hex0 just pretends that every file opened for writing is new <stikonas>well, this append problem in stage0-uefi was known to me for a long time (since last year) <stikonas>I just didn't realize we actually hit it in the bootstrap <stikonas>it's just that it's too big and fails checksum... <stikonas>and uefi api to reset file size was a bit clunky, so I haven't bothered yet... <stikonas>but yes, we should just truncate any newly opened file to 0 size... <oriansj>otherwise the open would not want truncation. <pabs3>oriansj: what was the reason for the savannah rejection? <pabs3>to me it seems like #bootstrappable projects should be considered necessary as the foundation of any FOSS system, so they should have been accepted in a heartbeat <janneke>pabs3: ignorance/stubbornness about binary files, bootstrap seeds, and also test data, i believe <janneke>pabs3: i believe the bootstrap/essential argument was made, but we should try to make it even stronger, dunno <janneke>as i said, i'm for waiting a bit until the guidelines have been improved, that could really help <oriansj>pabs3: duplication was their main argument; as all of the pieces are already submodules in stage0, they didn't want the pieces as separate repos for some reason. <Googulator>that means, -qr 8192 now works, and actually yields 8GiB RAM available once the Linux kernel boots <matrix_bridge><Andrius Štikonas> stage0 is not really where development goes to these days <matrix_bridge><Andrius Štikonas> Since even kernel bootstrap doesn't use it... <matrix_bridge><Andrius Štikonas> Though I guess stage0 is useful if you would build your own custom hw <pabs3>oriansj: wut? submodules are separate repos, just with pointers between them? <oriansj>pabs3: yep. welcome to my wonderful confusion regarding putting things into savannah <rickmasters>Googulator: The initrd code from Fiwix 1.4.0 was written by me and was a hack because it presumed the existence of hard coded physical memory ranges. <rickmasters>Googulator: Mikaku rewrote it and I think his implementation was better in that it mapped the initrd to an available virtual memory range. <rickmasters>But I think you are saying virtual range may not be a good choice because user space may try to occupy the same range. <rickmasters>Googulator: sorry, after looking at this further, it doesn't appear to be a virtual memory conflict. <rickmasters>It may be more related to the new (optional) user/kernel memory split of 2G/2G versus 3G/1G that we are using. <rickmasters>Mikaku introduced the 2/2 split that so we could map in a larger initrd into kernel space. <rickmasters>I'm still looking into how that relates to the change in available user space memory you are seeing.