IRC channel logs
2022-12-12.log
back to list of logs
<mihi>hello :) Been away for a while since I caught COVID, but feeling better now :) <mihi>logs are a bit confusing due to some missing date switches, so I probably missed some discussions while catching up. I recall at some point some discussion how cwd should be handled on UEFI, though. <stikonas>mihi: cwd itself is going to be environmental variable <mihi>I would have the libc hold a EFI_FILE_PROTOCOL reference pointing to the current directory (initialized from loaded image protocol by using the directory of the currently running application), and use Open() calls on it to change the directory. Open() will handle ..\ and stuff automatically, the only thing it does not handle is volume switching (and I don't know if we need that) <stikonas>I'm thinking that I'll just reuse uefi shell guid to share env variables with UEFI shell <stikonas>mihi: my first and very limitted prototype is to just store a string <stikonas>rather than EFI_FILE_PROTOCOL reference, that might be good enough <mihi>when you try to store CWD as a string, you'd have to do the ..\ and .\ mangling yourself or risk it to become too long eventually. <mihi>but as long as I don't use kaem, I think it should not matter too much. <stikonas>potentially yes, but we might be able to just steal some code <stikonas>there must be somebody doing stuff like that already <stikonas>it has to be environmental variable rather than just libc holding it <stikonas>otherwise it wouldn't propagate to child processes <stikonas>but then M2-Planet wouldn't know that cd changed <mihi>hmm. Probably never noticed it as usually I start stuff from their own directory... <stikonas>well, initially it confused me, why it doesn't work <mihi>that could get interesting when calling binaries from UEFI shell across volumes. <stikonas>until I realized that child processes still had "/" as their cdw <stikonas>at the moment I was only supporting one volume... <stikonas>I thought it should be enough for bootstrapping <mihi>which is fine for kaem, of course :) When somebody is bootstrapping from EFI shell, they will have to be made aware that it will not work across volumes. <mihi>how to you find "the ESP" volume? On some of my VMS your code could get schizophrenic if it does not use LOADED_IMAGE_PROTOCOL :D <mihi>(they have multiple disk, each containing an ESP, with matching efi shell entries in the boot variables) <stikonas>anyway, I was busy with M2-Planet for most of the time you missed here <stikonas>now we have support for fixed length integer type, i.e. stuff like uint32_t <stikonas>and also fixed stuff like struc[a].member <stikonas>could even be btrfs partition if your UEFI implementation supports it... <stikonas>though perhaps later once we get to building a 2nd bootstrap kernel, it would matter <stikonas>though I doubt that I'll be able to reach all the way to fiwix by myself <stikonas>it's quite a long way away from where we are right now <mihi>you don't have to do it all by yourself :) <mihi>you are working on so many fronts, and the others are also useful :) <stikonas>oh M2libc comment about adding setting 32-bit values (for UEFI protocol GUIDs) is now misplaced... <mihi>Now that we were talking about, I was curious and tested efivim opening a file when cwd was on a different volume, and to my surprise it worked. Looking at the source, seems that efivim calls into EFI_SHELL_PROTOCOL.GetCurDir() if that protocol is present to find the current directory... Didn't expect UEFI to be such a mess... <stikonas>yeah, it is somewhat of a mess and API is somewhat cluncky <stikonas>but we only have to do the minimum amount of work for bootstrapping <stikonas>and don't have to write full POSIX library <stikonas>and I would assume that EFI_SHELL_PROTOCOL is generally not present <stikonas>mihi booted volume is always fs0: isn't it? <stikonas>I should first write a nicer readme for stage0-uefi, right now it assumes a general familiarity with stage0-posix stages <stikonas>would be easier to advertice that repo then <mihi>stikonas, I don't know how the shell assigns the drive numbers, but on my test VM with many disks of different controller, the boot volume (SATA drive 0) is FS1:. FS0: is the efi partition from an isohybrid ISO mounted in the CDROM drive (ATA primary master) which does not contain any files and is not writable. <mihi>I recall also having seen the boot volume to be FS2: But cannot really tell the rules. <mihi>(This is regardless whether I use the shell from within the UEFI, or boot one from a file on disk) <stikonas>ok, that's somewhat useful, though that raises the question whether or how I can reuse cwd variable from UEFI shell <stikonas>that variable has values like cwd = FS0:\path\to\directory\ <stikonas>maybe I indeed should use that suggestion to hold EFI_FILE_PROTOCOL reference pointing to the current directory