IRC channel logs
2022-11-27.log
back to list of logs
<oriansj>stikonas: well part of me wanted to pass environmented variables as an argument but I have been thinking about it further and linux's /proc gave me a better idea. <stikonas>hmm, at some point you were non-persistent suggesting UEFI variables <stikonas>at the moment I'm in the progress of implementing spawn(program, argv, envp) but first iteration would only deal with program and argv <stikonas>the good but probably expected thing is that local kaem variables work <stikonas>there was a small isue with PATH but easy to solve <stikonas>just had to add PATH=/ to the first kaem script <stikonas>it was preset to /bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games <stikonas>oriansj: so you whink we just create a file /proc/pid/environ? <stikonas>though it's not very clear what is $pid? <stikonas>given that we have no parallel programs, everything is single threaded and spawned <oriansj>or just a temp file which we pass the name to <oriansj>and the libc unpacks it into the array needed by FUNCTION_main <stikonas>that would work... Possibly a bit slower as writes/reads to hard drive are needed <stikonas>oriansj: I think there might be a simpler option <stikonas>we can probably just pass it via LoadOptions but without any huge hacks <oriansj>assuming we don't run into any annoying limitations that way <stikonas>we have both LoadOptions and LoadOptionSize, so what if we say that LoadOptions terminate with zero byte <stikonas>and zero byte adds a argv/evnp separator <stikonas>and libc continues to read pass that zero byte till LoadOptionsSize ends (and 2nd part is envp) <stikonas>which would never be used inside command line argument <stikonas>hmm, though this way would still need some care not to break programs launched by kaem-optional or UEFI shell <stikonas>but on the other hand, passing it via another file might be even simpler... <stikonas>oriansj: I think current implementation of _process_load_options would already stop at null byte <stikonas>so we just need to process the rest of the string <stikonas>so right now we have wcstombs(load_options, image->load_options, image->load_options_size); <stikonas>which will convert the whole wstring to "char string" and might even contain zero byte in the middle <stikonas>actually, I might be lying, met me check wcstombs... <stikonas>hmm, yes, current implementation of wcstobs would stop at 0... <stikonas>though perhaps we can just do strlen (wcstombs) and continue parsing LoadOptions from there <stikonas>just need to convert envp string to array, but that's not so different from argv work we are already doing <stikonas>I guess this whole system I'm using has a limitation that spaces are argument sparators <stikonas>so one can't easily pass them inside argument <stikonas>i.e. paths with spaces are not supported <stikonas>but that was already limitation of kaem-optional <oriansj>hence the question of how best to work around UEFI if it gets in our way of doing the basics <stikonas>well, given that we already have this limitation in kaem-optional and current M2libc <stikonas>I think we can try to live without spaces in paths <stikonas>(and only paths in command line matter, not all paths) <stikonas>given that we should be able to control most of the source until better kernel (fiwix?) <stikonas>and if we really need spaces in arguments <stikonas>we could probably do something too with them in libc but maybe let's worry only if we really need it <stikonas>hmm, quite a few small issues in kaem... <stikonas>I've tried adding PATH="/" to help with finding binaries, but then somehow that / doubled and I'm ending up with //amd64/bin/kaem.efi (which for some reason fails to work) <stikonas>hmm, that happens because PATH="/" does not play nicely with find_executable function <stikonas>ok, actually I should just keep ./ rather than remove it as I was doing in kaem-optional and it seems to work <stikonas>oriansj: hmm, I've now reached the place where uint16_t and uint32_t might be useful... <stikonas>so not sure whether we should add them to M2-Planet or use char[] workarounds <oriansj>stikonas: well it is what the C spec kind of indicated <oriansj>so on 32 bit platforms it is 32bit but on 64bit platforms it is 64bit <stikonas>hmm, so do you know what would be required to add uint32_t <stikonas>if we just add another type with hardcoded 32 <stikonas>at least for our usecase we are not even worried about overflows <stikonas>we are not doing much arithmetic on those values <stikonas>I can then also rework some of that early GUID initialization stuff... <oriansj>if we update expression in cc_core.c and define a few types in cc_types.c that'll solve most of it (only arrarys would need a little extra work) <oriansj>basically we only need to do the correct thing loading the value into the register and storing it from the register <oriansj>(although if we want uint64_t to work correctly on 32bit architectures, it'll take a good bit more work) <stikonas>yeah, I guess we need to add defines for WORD PTR (as in GAS) <stikonas>at least on amd64 I only need 16 and 32-bit <stikonas>maybe ideally it would be uint64_t there but oh well... <oriansj>well just adding int32_t, uint32_t, int16_t and uint16_t shouldn't be too complex <oriansj>and did you need 16bit behavior to be preserved past multiple operations? <stikonas>in M2libc (UEFI) it's really just setting struct data <stikonas>well, just need to get defines for all arches... <stikonas>do you want to look at it, or should I do it? (I won't do it today as it's getting late) <stikonas>and then hopefully tomorrow I can get spawning to work in kaem <stikonas>though I think envp shouldn't be too hard either <stikonas>M2-Planet is getting more and more like proper C.. <oriansj>well; after this if one adds switch statements to M2-Planet, it'll be a huge part of the c89 spec <oriansj>it is almost like the root core of C is just the laziest possible Language you can do with just a couple nice extras <stikonas>I guess we are also missing type conversion, i.e. (int) variable <stikonas>both of these are not critical if you write your own code... <stikonas>either use more if/else, or just define new variable with the right type and do assignment <oriansj>well as everything is implicitly converted to register; then (int) becomes quite meaningless <stikonas>though perhaps it's more readable to just assign it <stikonas>I recently used a lot of code like: struct efi_file_protocol* f = fd; <stikonas>perhaps we should do a release of M2-Planet (and I guess stage0-posix too then) once stage0-uefi runs to completion <stikonas>hmm, we've got #warning, lot's of segfault fixes, position independent code on amd64 and global and local structs <oriansj>I can see doing a new release seems reasonable <Hagfish>well there be a nice little release announcement about that? <Hagfish>i haven't been following exactly where things are at, but it sounds like some big things have been achieved, and there are almost enough pieces for someone to do a really impressive demo (maybe after the subsequent release?) <oriansj>well M2-Planet has been able to do a really impressive demo for a long time now <oriansj>is it just me or does modern software development sometimes feel like building a house on shifting sand <oriansj>because today GCC is just like, I'm gonna link to the wrong libc so return 42; will just be a segfault. Enjoy... >.< <oriansj>>.< well I had the least productive last few hours <oriansj>gcc and clang just don't want to work with me tonight and M2-Mesoplanet is displaying C preprocessor bug with the current M2libc when one does --architecture x86 <oriansj>added to that I can't even get guix to build the most basic of shepherd services without throwing errors. (literally on turn on, run a single script in a fixed location) <oriansj>and at this point, I've failed enough tonight and I'll try picking it up again in the morning (assuming guix can finally finish building gcc by then) <stikonas[m]>Hagfish: that's not imminent yet, I might need another week or so to finish stage0-uefi <stikonas[m]>And there is always an announcement on the mailing list <stikonas>hmm, M2-Mesoplanet currently broken muts be due to one of my UEFI changes... <stikonas>hmm, it's probably correct in terms of C but indeed M2-Mesoplanet does not play nicely with nested #ifs <stikonas>maybe let's undo that change for now, it's not yet useful for UEFI (as M2-Mesoplanet has not yet been built) <stikonas>so a bit hard to test what would be the correct way of doing it... <stikonas>it might be a bit annoying to make it play nicely on both POSIX and UEFI <oriansj>stikonas: I'm just going to fix M2-Mesoplanet (as soon as I can get gcc to work) <stikonas>ok, let's keep it PR open for now and then close it once it works <stikonas>because otherwise we might just be postponing the problem <stikonas>but to answer your question, I didn't usually have problems with compilers (gcc, etc...) <oriansj>might just be my experience of trying to use guix upon debian <stikonas>either debian or full guix might work fine but guix upon debian might be easier to misconfigure <oriansj>well guess I need to plan on a little downtime to finally dive into pure Guix on my librebooted x200 <Christoph[m]>I'd prefer if bootstraping would also work on debian with guix on top. I'm on the fence of switching to only guix for several years now... <stikonas>Christoph[m]: I suspect the problems oriansj has are nothing to do with bootstrapping <stikonas>it's inevitable that when you run one distro on top of another, you need to be very careful with binary, libary and various other paths (e.g. certs) <stikonas>bootstrapping itself should work on any distro <oriansj>Christoph[m]: stage0 and all the steps build and run just fine; <oriansj>the problem is entirely my setup and all of the pieces will work on both Debian and on Guix (and lets be honest Guix on other distros is not well supported and breaks from time to time) <mihi>stikonas_, oriansj: I don't mind how environment variables are done in stage0-uefi, but I'd like to be able to set them from UEFI shell and not only kaem. So if the "obvious" solution of using volatile EFI variables like UEFI shell's "set -v" command does is too complex, storing them in a file and having a simple command to get and set them should work fine too. Messing with LoadOptions would, <mihi>however, require to use kaem if you want to start a M2-Planet compiled program that requires environment variables (like Mes). <stikonas_>and then we can see about environmental variables <stikonas>perhaps we'll have to use EFI variables, as using files have some disadvantages (slow disk access, etc...) <oriansj>worst case is we learn what doesn't work and try something a little different <stikonas>oriansj: so I've started adding fixed length types to M2-Planet