IRC channel logs

<fossy>stikonas[m]: finally packaging pr done

<fossy>should be no QEMU inconsistencies anynmore

<stikonas[m]>fossy: I'll take a look, though will take a bit of time. It's big PR...

<fossy>yes, no rush

<fossy>although, much of it is checksum-related, so kinda inflates size

<oriansj>"The region of RAM above 1 MiB is not standardized, well-defined, or contiguous."

<oriansj>wooo more complexity for me to manage

<bauen1>oriansj: you're reading about x86 ? if you're looking at dos/bios era things, it's just an absolute minefield

<oriansj>bauen1: well yes, I figure do x86 first and go from there.

<oriansj>just need enough to do paging, read/write to a block device (or two) and single tasking batch processing.

<oriansj>I can probably bury the ugly memory details in a function that sets up a memory table.

<bauen1>oriansj: i really recommend you to take a look around osdev.org, there's quite a few people doing similiar things, and while not a single one will match exactly your needs they're still good for learning what works when and when not

<unmatched-paren>I just had a thought: would a literate programming system have a bootstrapping problem if it was itself written literately? Usually the output of a literate programming tool is easily machine-readable and not at all obfusicated.

<unmatched-paren>s/machine-readable/human-readable/

<oriansj>unmatched-paren: one can do literate programming in Assembly or even hex if one so desires

<oriansj>So the binary might not be literate but at that point it isn't an issue

<unmatched-paren>Yeah, that would make sense. It's just that _technically_, it's not _exactly_ the original source code.

<unmatched-paren> https://github.com/zyedidia/Literate <- this thing is written in literate D, but it has the tangled output in src/tangle/

<unmatched-paren>so i guess src/tangle would count as source?

<oriansj>unmatched-paren: the ASCII C compiler is as probably the closest to the output binary being readable

<stikonas>fossy: I still have some checksum failures in live-bootstrap

<muurkha>doing boot and paging is going to be enormously easier on RISC-V than on x86

<oriansj>muurkha: probably

<muurkha>check out the RISC-V privileged spec: https://github.com/riscv/riscv-isa-manual/releases/download/Priv-v1.12/riscv-privileged-20211203.pdf

<muurkha>it's teensy and it covers everything you need to know for paging (though boot is out of scope)

<oriansj>muurkha: adding filesystem support is probably going to be a much bigger (and harder to debug) part to implement

<muurkha>what, in C?

<oriansj>muurkha: well first in C and after I get it working, I'll rewrite it in Assembly

<muurkha>what do we need lseek() for again? I forget

<oriansj>muurkha: hex2

<muurkha>oh

<oriansj>it might be possible to rewrite hex2 and hex1 to not use lseek by buffering in memory

<oriansj>So, I'll be supporting it in kernel; unless it proves difficult enough to punt to do a userspace rewrite

<muurkha>I was thinking the filesystem would be easier to write if it buffers the whole filesystem in memory

<muurkha>in the kernel

<muurkha>not a good approach for bootstrapping on a Z80 or something of course

<muurkha>but if you have gigabytes of RAM it should be fine

<oriansj>muurkha: well we can dictate hardware too

IRC channel logs

2022-03-07.log