1. 33
  1.  

  2. 6

    I know it’s a hobby/personal project but the commit messages could be much better written, especially the ones written today.

    https://hg.sr.ht/~icefox/mongoose/log

    Just some constructive criticism.

    1. 7

      How could they be better written? Excepting the ones that are three words or less.

      1. 28

        Well I think

        glrblrmbnfl

        is top notch. No changes from me. 😁

        1. 4

          I’m glad that at least someone appreciates my cunning prose and razor wit! /s

        2. 12

          I can go through some of your messages and state how I would write them:

          why so many inaccuracies in docs

          Instead: “Document attempts at cooperative scheduling”

          brain y u keep thinking of things

          I know it’s your job, but really.

          Instead: “Add RISCV notes, also update address space notes”

          Just minor cleanups

          Explain the cleanups you did here, I’d actually break this into multiple commits.

          1. 3

            Three words is pretty verbose, may I suggest a more laconic style as an alternative?

            https://github.com/matklad/config/commits/master

            (learned that from brson)

            1. 2

              git commit --allow-empty-message

              1. 1

                I am glad to find I still have so much to learn from the masters!

              2. 2

                I personally think that if you’re doing something for fun, you should do the parts you think are fun. If that’s writing good descriptive commit messages, do that. If not then, well, don’t.

            2. 2

              OS Dev seems to have such a huge barrier to entry (obviously? I’ve been through the OS Dev wiki a few times and it hasn’t stuck).

              Much respect to anyone that gets something even slightly off the ground for themselves.

              1. 13

                I didn’t do it all by myself! Much, much credit goes to https://github.com/repnop/, who I talked with nearly daily on the Unofficial Rust Discord server and who helped me figure out several bugs and taught me a ton of general background info about RISC-V. This is also my third or fourth serious attempt to write an OS of some kind or another, and I’ve gotten a little further each time. Plus the Rust crate ecosystem makes life a lot easier as well, since there’s a surprising number of low-level crates such as fdt and goblin for doing things like parsing data structures you’re going to need to parse anyway. And as I say way at the bottom of the readme, targeting RISC-V and the qemu virt machine architecture is also kinda easy mode since it’s quite minimalist but is also close enough to real machines to be satisfying. x86 would involve a lot more tedious “get everything perfect or the machine triple faults”, and ARM would drive me slightly crazy trying to understand what combination of instruction set + extensions + peripherals + whatever else I should be using today and finding the correct docs for all of them.

                You just find a good collection of giants and start a-climbing.

                1. 2

                  find a good collection of giants and start a-climbing.

                  I love this, thanks.

              2. 2

                Regarding the comment in the article about how to do a context switch outside of an interrupt - this should work ?

                i.e., the relevant regs are stored in a struct, and passed via a0,a1

                https://raw.githubusercontent.com/mit-pdos/xv6-riscv/riscv/kernel/swtch.S

                Call swtch to jump from t0 -> t1, and when done call it again to jump back t1 -> t0, and return to where you swtched from.

                1. 1

                  I don’t get the problem with cooperative context switches.

                  Cooperative context switches look like a function call, therefore if your code is written according to the standard ABI none of a0-a7 and t0-t6 need to be saved and the context switch code can use/clobber as many of them as it needs.

                  If anything, they should be set to 0 or 0xDEADBEEF or something just before returning to the new process.

                  1. 1

                    Yeah, I think my problem with context switches was I did things the wrong way around. I wrote a Rust function to do it, then tried to inline asm inside the function to juggle the registers, but the Rust function was using some of the registers already so things got complicated. Should have just written a repr(C) function that takes a couple register structures or such as arguments and does the switching for you.

                    1. 1

                      A context switch is fundamentally doing things behind the compiler’s back. It should be written in assembly language.

                      Often you can get away with using setjmp() and longjmp(). But those are written in assembly language – just not by you. And to create a new thread you need to fiddle with saved registers inside the jmp_buf, which supposed to be an opaque structure, so that’s undocumented and non-portable. You might as well define your own thread structure and thread switch function anyway.