IRC channel logs

2020-04-30.log

back to list of logs

<OriansJ>well getting kaem master in shape for a release seemed the priority
<dddddd>just for the record, the blood-elf and M2-Planet patches worlked as expected on aarch64
<dddddd>*worked
<OriansJ>thank you dddddd for testing ^_^ I appreciate having an extra set of eyes before I do a release, so I don't have too major of a public screw up
<dddddd>no problem, sorry for the initial false negative
<dddddd>I missed the link between the two patches.
<dddddd>Oh, so mescc-tools is both at github and savannh, but kaem isn't; therefore the relative-URL submodule is not fully possible right now.
<fossy>OriansJ: yes it is
<fossy>thank you for the patch
***midnight is now known as midnightmagic
***midnightmagic is now known as midnight
<OriansJ>dddddd: well currently kaem is evolving faster than the rest of mescc-tools, which are now mostly just stablizing into their final form. Hence why it is a seperate submodule in a repo controlled by the person who wants to drive it forward the most (fossy).
<dddddd>I see, but it's weird anyway (under your account). It can evolve in branches even. Whatever...
<dddddd>Two repos and two sites for five files. One repo at savannah should be enough IMO.
***ChanServ sets mode: +o rekado
<amirouche>forth in collapseos https://github.com/hsoft/collapseos/issues/4
***dddddd__ is now known as dddddd
<OriansJ>dddddd: the reason it is under my account was simply expedience. if fossy wants to move kaem to savanna, gitlab, notabug or anyother hosting provider; I have no issue with such a change. It is a submodule simply because github doesn't allow me to give permission to just a single folder in a repo to another person.
<fossy>dddddd: it is not good for me to have permissions to all of karm
<fossy>all of mescc tools I mean
<fossy>but for development to move I need write permissions to kaem
***Server sets mode: +cnt
<OriansJ>also the comment about doing a C compiler in FORTH; LOL there are more than a dozen C compilers written in assembly now (I know because I did most of them) but not a single C compiler written in FORTH.
<dddddd>I don't want to think about this anymore, I don't share your view of the issue and me explaining it won't change it. This is just too painful and I want to get it out of my head. Nonsense IMO.
<OriansJ>dddddd: would movement of the master kaem repo to somewhere other than github work better for you?
<mihi>Hi, short question: Is https://github.com/oriansj/stage0/blob/master/x86/stage0/stage0_monitor.s still used by the bootstrap process?
<mihi>although it is really shote, it contains a subtle bug as it modifies ss/sp while interrupts are enabled and does not use the "magic" "mov ss, reg; mov sp, imm" sequence that disables interrupts in between automatically
<mihi>*short
<OriansJ>mihi: the stage0_monitor is 1 of 2 possible routes to bootstrapping.
<mihi>I mean, is the usual path going from stage0 on x86, or rather on Knight VM? Or do most bootstraps start from within Linux anyway?
<mihi>also, having an (albeit unreachable) HLT instruction that is not in a loop with enabled interrupts makes me cringe. And I feel an urge to replace all the "call ... / ret" combos by jumps, but I can see that readability is more important than size and/or stack efficiency here.
<OriansJ>mihi: well usual depends on one's preferences, right now the three most commonly tested paths are the x86 on linux, amd64 on linux and knight on bare metal
<OriansJ>The x86 bios level bootstrap work however never really progressed all the way to cc_x86.s
<mihi>ok thanks :)
<OriansJ>so if you wanted to take over that bit, it is certainly available
<OriansJ>I just literally didn't have the time to get to it yet.
***reepca`` is now known as reepca
<mihi>yeah, I can see that the project is really ambitious and I'm thankful that you have enough time to get this project further, because bootstrappability seems to be important to me. While still it's unclear how best to connect some of the paths, but I'm confident that y'all will find a good solution :)
<OriansJ>mihi: all of the paths connect at M2-Planet+mescc-tools https://github.com/oriansj/talk-notes/blob/master/Current%20bootstrap%20map.pdf
<mihi>(e.g. how to get a crosscompiler that compiles to e.g. x86 running on Knight, since as far as I know neither gcc nor llvm has a Knight target.
<mihi>)
<mihi>that PDF refers to the Linux level bootstrap as far as I understand it, not the native one.
<mihi>and when you want to compile a Linux kernel or a coreboot payload, I doubt you can get far with "smaller" C compilers.
<mihi>but I won't mind if you prove me wrong :D