Maestro - Linux-compatible-ish OS in Rust

[late oar]

btw I'll try to re-enable LTO to see what it does, now that I have fixed provenance. Maybe it would fix that too

for the record, LTO used to break the kernel so I disabled it

[fringe pike]

i think it can't find thread safety issues

yeah

unless you dont follow strict provenance

[late oar]

I think provenance checking is not enabled by default on miri but it can check it

the thing is, all of my provenance issues were in the kernel itself, not the library that I can check with miri

[fringe pike]

ah

[late oar]

so I think I fixed everything. I am currently reviewing all my changes
also, I think getting pointer provenances right made the kernel get a bit faster, although I didn't measure

[late oar]

looks like LTO is breaking modules. They cannot find some symbols from the kernel

[elder sonnet]

Linus mentioned Maestro at OSSEU (which you already knew) but LWN covered that too and linked to your OS (still behind a paywall but I presume not for much longer)

https://lwn.net/Articles/990534/

[magic cloud]

big

[late oar]

I wasn't aware of that. Thanks!

[elder sonnet]

No problem. Always nice to see projects from here mentioned elsewhere

still waiting on AssertOS

[late oar]

everything is working. Now I have to review everything and then finally merge it

[shell tusk]

How many + and -

[late oar]

+32,120 −37,024

[shell tusk]

Damn thats a big pr

[late oar]

yeah, but it's a summary of a lot of smaller PRs merged together

[magic cloud]

I wanna see if my fireworks test that I ported to linux works hwre

On maestro

I'll find the link

https://github.com/oberrow/fireworks

[late oar]

That won't work because it's making use of the framebuffer. I don't have support for anything else than VGA text mode for now

[errant venture]

Any reason why u did that instead of incremental prs

[late oar]

huuuuuuh

no

[latent anchor]

it is supposed to catch everything

if something is ub and miri doesn't catch it

then it's a miri bug

or unimplemented feature

it's basically doing what the borrowck does but at runtime, evaluating MIR

at least that's what I remember

I can ask someone more knowledgeable about miri tho

I only used it like once

ig it can't catch stuff across ffi boundaries

but stuff like that are technical limitations

it can be seen relatively UB-free

[latent anchor]

this might not be exactly true implementation-wise but job-wise yes

[late oar]

@latent anchor thanks for the explainations!

[late oar]

reviewing all of that is so long

might take several days

[late oar]

oh well. The diff is kinda fucked up because of the files being moved and modified. I'll just make a last commit to fix what I found and I'll merge it

[desert hearth]

"Just one last commit"

Jokes aside, impressive work. Did this touch just about everything in the kernel?

[late oar]

MERGED

tomorrow I am beginning the implementation of long mode

[shell tusk]

556 new commits

jesus

[late oar]

Almost everything. I didn't refactor processes and the scheduler but I'll have to do it when I implement SMP anyways

[late oar]

I am once again beginning to wonder whether I should keep support for CPUs that don't have long mode

On one side, not many of those are still running I guess? On the other side, it does not seem to require a lot of work to keep it

[desert hearth]

if it doesn't limit your long mode shenanigans, no reason not to for now imo

[magic cloud]

if you have proper arch code separation then I don't see why not keep a prot mode target

[late oar]

ok I think I'll try to keep support for it and if it's too annoying I'll drop it

[late oar]

so, I am beginning the implementation of long mode. I am adding a new target architecture which I named x86_64. So far, no major issue encountered

[late oar]

just realized I don't need to enable the A20 line since the bootloader has to do it for me when using multiboot2

I hadn't touched this code for several years

[late oar]

I knew I was going to have issues with modules again, and here we go...

For the context, I compile my kernel as an executable file, but also a shared library, so that I can use it to build modules against it. So modules think the kernel is a shared library to avoid copying all of the kernel inside of them.
The problem is that it often creates issues with relocations. The one I have right now is this one:

  = note: x86_64-elf-ld: /home/luc/Desktop/dev/maestro/kernel/target/x86_64/debug/deps/kernel.8dkt4hawjz9zsyawhg84bzf5k.rcgu.o: relocation R_X86_64_32 against symbol `multiboot_entry' can not be used when making a shared object; recompile with -fPIC
          x86_64-elf-ld: failed to set dynamic section sizes: bad value

I am compiling the kernel to a x86_64 target, but multiboot_entry is in 32 bit (thanks to the .code32 directive in assembly)

[late oar]

So I just learned Linux is using .o files as kernel modules instead of .so like I do. If I understood correctly
That might make things easier. I just need to get it right

[errant venture]

Indeed

[late oar]

just stashing this: https://git.sr.ht/~abbix/fisix/tree/master/item/src/modules/build/rs-build (found it with the search bar on this discord server. thanks @tough onyx)

I'll continue working on that tomorrow

[errant venture]

do u want linux kernel abi level compatibilitiy as well?

[tough onyx]

yeah I wrote that a while ago

[cursive lintel]

that is literally impossible

[tough onyx]

i had rust modules but never used them

[tough onyx]

nah it's possible

just painful

[cursive lintel]

ok it might be possible if you pin like a exact kernel version for ABI

kernel ABI changes regularly

[late oar]

no, I just want my modules to work

[errant venture]

but u dont have to do .o

u can do .so

[late oar]

how do I build it against the kernel without it including all of the kernel's content?

[magic cloud]

I know this....

[errant venture]

sounds like something only mint would know

[late oar]

like, I just want it to reference symbols inside of the kernel, not include them

[magic cloud]

I beleive if you make it an so it assumes symbols are undefined

[late oar]

make the kernel a .so ? or the module ?

[magic cloud]

the module

[late oar]

it does not right now

[magic cloud]

weird

I have -shared passed to the linker

and I don't get unresolved symbols

I also pass -pic to the linker

and ofc -fPIC to the compiler

[late oar]

so far the strategy I adopted was to compile the kernel as an executable AND a shared library, and make rust compile the module against the shared library. Then at runtime the kernel loads the modules and can link it since it has the same symbols as the shared library

but making a shared library out of the kernel has often caused annoying issues, like right now

[magic cloud]

make the kernel a normal binary

*elf binary

[late oar]

it's already the case (at runtime)

[magic cloud]

normal meaning with relocations or statically linked

but not an so

yea my drivers get away with -Wl,-shared

try --unresolved-symbols=ignore-all

[late oar]

well, I think I'm going to sleep instead. I am too tired for this right now

[magic cloud]

gn then

[young ermine]

you can just use x86_64-freestanding-none, no?

ah that's for kernel modules

[desert hearth]

I dont know much about rust so I cant help with that part, but you're wanting to have a list of external functions that are resolved at runtime. Maybe look at how people write plugins for other programs using rust, it would work the same way I imagine?

or a worst case of a giant table of function pointers for driver->kernel calls

[late oar]

Other programs usually put #[repr(c)] everywhere, which I find unacceptable

[desert hearth]

Surely rust has some mechanism for this

[late oar]

No it's usually crap

[desert hearth]

Lol

[late oar]

Just found this: https://doc.rust-lang.org/reference/items/extern-crates.html#the-no_link-attribute
Imma try it after lunch

[latent anchor]

you can take a look at bevy maybe

bevy has dynamic linking as an option

through a feature

it builds bevy as a shared library (your app still has all the other stuff statically linked

it's to avoid recompiling bevy while doing iterative development

[late oar]

well I tried this and now I have this error:

  = note: i686-elf-ld: __rust_realloc: undefined version: 
          i686-elf-ld: __rust_dealloc: undefined version: 
          i686-elf-ld: __rust_alloc_zeroed: undefined version: 
          i686-elf-ld: __rust_alloc: undefined version: 
          i686-elf-ld: failed to set dynamic section sizes: bad value

[late oar]

and it seems bevy is having the same issue as me right now: https://github.com/bevyengine/bevy/issues/14117

[late oar]

okay so I managed to compile it but now there's a triple fault when I spam the keyboard

(everything else works fine)

[magic cloud]

lol

obos also had a bug like that a loooong time ago

[late oar]

do you remember what caused it?

[magic cloud]

never debugged it

I think it was memory corruption though

at least there was a crash related to that

[shell tusk]

obos had a bug
memory corruption

classic

[late oar]

well I had to touch memory allocation to make the module compile, so that's probably memory corruption too

If you wonder why I had to touch memory allocation, basically the symbols that could not be resolved are special ones that are generated by the compiler when you use the #[global_allocator] thing. So I just removed all of that and now I do it by hand

[magic cloud]

smh isn't rust supposed to be memory safe

[magic cloud]

*memory allocation

[late oar]

safe as long as you don't do unsafe code

[magic cloud]

smhsmhsmh

[latent anchor]

unsafe code is also supposed to be memory safe ("sound")

if it isn't, then it's "unsound"

"unsafe" just means "the compiler can't check this for various reasons and I guarantee that shit will hold up"

unsound unsafe can cause otherwise safe code to have UB too

so basically the compiler has the gun in safe code, in unsafe code the programmer has the gun and if you shoot your foot then give the gun to the compiler then the compiler will shoot you in the head

[late oar]

I think I found it ‼️

The memory allocator returns a NonNull<[u8]>, whose slice has the length of the required allocation.
When the size of the allocation is 0, the allocator has to use a dangling pointer (but non-null) to build that slice (with a length of 0).
I was exactly doing that, but I was using NonNull::dangling, which created a dangling pointer with the alignment of u8 (that is, 1).

However the pointer actually has to be aligned according to the constraints of the type it is allocated for, regardless of whether it is dangling or not (when calling the allocator, we pass it a Layout struct which contains the required size and alignment).
So I just replaced by Layout::dangling instead, using the provided layout

and it does not crash anymore when I spam the keyboard so I think I fixed it!

[desert hearth]

Oh nice

I always enjoy a good read after a bug

[late oar]

was wondering why my kernel was exploding. I moved the address of my page directory to cr0 instead of cr3

[shell tusk]

💀

[late oar]

I am now able to print text with VGA in 64 bits

And then the memory allocator explodes

[young ermine]

i hope maestro won't assume that vga text mode just exists

you really should integrate flanterm :^)

[shell tusk]

but flanterm is not blazingly 🔥 fast 🚀 rust code

[analog crane]

it is blazingly fast C code though (fuzzed)

[errant venture]

i mean on x86 w/ bios its safe to assume it exists

is it slow as shit tho? absolutely

[analog crane]

weeeeeeeeeeeeellllllllllllllllllllllllllllllll

technically no, no it is not

not even so technically, i can tell you of at least 1 machine where there is no text mode

which is 95% of the reason why Limine defaults to graphics mode even on BIOS

[cursive lintel]

I mean I am somewhat working on figuring out how to make it faster

Btw ran the fuzzer for a bit, found nothing

If I do get to building a decent fuzzing farm I'll add it but tbh I doubt it's got many easily exploitable things in it

[young ermine]

don't the integrated graphics on new intel processors (starting with ADL?) lack text mode support?

meaning you need a discrete graphics card for that

[late oar]

no there will eventually be something else than VGA of course

I started rewriting the buddy allocator to make it able to make concurrent allocation (that is, not have a single mutex locking everything). But then I realized this is not the good time to do it. I should just focus on long mode and when it's working well, I can start something else

[analog crane]

yes

but we're talking BIOS

UEFI in general doesn't have it

and they will only boot UEFI

[young ermine]

so those machines will not let you enable CSM?

[analog crane]

not unless you add an external GPU that supports text mode

[young ermine]

that makes sense

[errant venture]

which

[fringe pike]

fuzzing doesnt guarantee the absence of issues

i mean neither does rust but

[analog crane]

yeah rust doesn't say anything about logical errors either, so

[magic cloud]

lies, rust code cannot have bugs /s

[analog crane]

Librem 15 laptop, using their coreboot

it can only use BIOS functions to print text to screen, text mode isn't present so writing to 0xb8000 actually crashes the machine lmao

VBE works though

[errant venture]

well i meant vbe not 0xb8000 ofc

[analog crane]

ah

well i may have misunderstood because i think maestro uses b8000

[errant venture]

flanterm in ada when

[analog crane]

lol ask @floral raft

[errant venture]

should be easy to formally verify since its essentially a data converter

[floral raft]

I mean, yeah

its just globals having correct values if certain things are inputted

[late oar]

yes

[late oar]

I am extending my implementation of paging management to handle 4 and 5 level paging (even though I may not use 5 level paging, idk for now. I am just making the implementation generic enough to potentially handle it)

And also I am laying the foundations for fixing this issue

[floral raft]

If french is so cool why is your kernel name in Spanish Humm???

[analog crane]

it's italian

[floral raft]

No it's romanian

[late oar]

took it from italian

@analog crane wins

[analog crane]

yay

[late oar]

fixed my paging, now I implement support for ELF 64 so that the kenrel can read its own symbols (and later execute 64 bits programs)

[fast halo]

linus showing his age

[late oar]

he's only 54 though. he looks much older

[pastel summit]

in a less unflattering picture he looks fairly average for his age

[fast halo]

still

showing age

[fast halo]

surprisingly young

i thought he was like 60

[late oar]

done. now I'll work on 64 bits programs loading

[civic copper]

he was born in 1969 i think

[fast halo]

yeah late 1969

[fast halo]

hmm yes. maître

[late oar]

I think my ELF64 parsing is good. Now I investigate an issue with interruptions (which don't seem to be caught in 64 bits)

[late oar]

I didn't find the cause of the interruptions issue (yet) but now maestro has a directory containing HAL code for each architecture (well, for now only x86 and x86_64 which are in the same directory)

[late oar]

found it. I didn't read the doc carefully so I didn't see that in your GDT, the DB flag (to choose between 16 bits and 32 bits) should be clear if the L flag is set (the one for 64 bits code). And that the L flag should be clear for data segments

[late oar]

thats today btw, at 18:35 CET

[late oar]

So now I have to fix register save/restore

[late oar]

TSS broken, GPF in a loop, investigating

[floral raft]

just watched the talk, was nice

[late oar]

Thanks!

[errant venture]

Link?

[late oar]

Huuuuu I don't actually know where to find it after the live

[floral raft]

https://www.p99conf.io/session/writing-a-kernel-in-rust-code-quality-and-performance/

[errant venture]

Damn now I understand the idea behind your pfp

[late oar]

[errant venture]

What sort of sw stack is clever cloud built on?

[late oar]

Huh idk if I can say

I can say that they wrote their own load balancer though. It's open source: https://github.com/sozu-proxy/sozu

[errant venture]

i was mostly talking about the vm part, like qemu or

[late oar]

yeah qemu

very powerful servers (I am not allowed to give you the specs) with QEMU virtual machines on them

the VMs are running linux, but the CTO would like to try with my OS when it will be advanced enough

[errant venture]

cool

[late oar]

just discovered this: https://elixir.bootlin.com/linux/v6.11.5/source/arch/x86/entry/entry_64.S#L177

that's SO MUCH simpler than what I did in my kernel

on interrupt, you save userspace registers on the kernel stack and you do your stuff. If the scheduler makes a switch to another task, you just swap kernel stacks. And when the task resumes, you just continue the execution in kernelspace like nothing happened and you restore userspace registers from what's on the stack

[analog crane]

i mean yeah

that's kinda the way™️ of doing it

[latent anchor]

what were you doing before?

well i have done weird stuff myself like uhh

context switch in interrupt handler

by that i mean the interrupt handler stub did the context switch

[late oar]

I have a function written in assembly loading registers values from a structure before using iret to go back to userspace

so instead of returning from the interrupt that called the scheduler, the scheduler was calling this function

[latent anchor]

that's still useful tho don't throw it out

you can use it for new threads

u probably already do

[late oar]

@latent anchor what's ur opinion about using async in kernelspace?

I think that may allow to have one kernel stack per core instead of one per thread, but I have a hard time wrapping my head around how it would be implemented

[late oar]

(I am thinking about this now because I think it would be incompatible with this)

[latent anchor]

no idea tbh idk much about async internals

it's basically cooperative multitasking

[latent anchor]

same here

idk if it would benefit a kernel like maestro's

and you need to keep in mind how it would affect everything else

[pastel summit]

very Managarm

(i'm not sanaana but i comment anyway)

[late oar]

is ok, I need opinions

[latent anchor]

i think they mean rust futures/async/await

right?

[late oar]

yes

[latent anchor]

i don't really see how useful it would be

it would be very managarm if the UAPI was very async

[pastel summit]

well managarm is also doing that

[latent anchor]

but i don't really see what this would help solve in the kernel

[pastel summit]

only they use C++ couroitines instead of rust's async-await

[latent anchor]

hmm

[pastel summit]

that's how managarm does async without a thread pool

[latent anchor]

i feel like I'm not qualified enough to answer this question

but i can confidently say that rust's futures can probably do everything C++ coroutines can

[pastel summit]

i can say that if i had async/await around in c/objc i would certainly use it

as async i/o for instance is useful in a primary way even irrespective of whether it's exported to the userland API

[latent anchor]

would using coroutines affect where stuff could be preempted?

hmm

@late oar maybe experiment with it and see if your hypothesis is correct

https://tryitands.ee

[pastel summit]

you would potentially get some more yield points by virtue of it being a coroutine and you'd probably not want to be preempted at other points

[latent anchor]

i feel like this would be most useful in a otherwise non-preemptible kernel

[pastel summit]

since there are no language coroutines available to me in (obj-) c i use this as the backbone of the async i/o system: https://gist.github.com/netbsduser/f071ddc70b8250fc19f04ba03b30f52f

if i had coroutines available it would make life far easier (since i like async i/o and provide it, and not only userspace but kernel wants it - plus it is just nicer in its own right than having to dispatch work to thread pools)

[latent anchor]

i'm doing a microkernel so this wouldn't help me at all

anything that would need this would be in the userspace :3

[late oar]

maybe Maestro should be a microkernel too

[ancient galleon]

one kernel stack per core is atrocious

it disallows a lot of very neat tricks (including the context switch one), and kernel preemption

[late oar]

I have been thinking about this all day and the answer is: I am not going to bother about this right now. I'll just implement the kernel stack swapping thing and think about async stuff later

I've been hesitating all day because I am scared I will implement something to maybe remove all of it in a few months

[ancient galleon]

having a per-core kernel stack really complicates stuff

especially with apis that can block for multiple switches like pipes and sockets

[young ermine]

i suppose the idea is that state of futures between suspend points is saved in the future itself, so technically you only ever need a single stack per core

but idk much about async so ¯_(ツ)_/¯

[tough onyx]

do you like, not need an async I/O system if you have it builtin?

note: i know nothing about async io

I mean I guess to expose it to userspace but even then, you can just use coroutines under the hood

[latent anchor]

it's just more helpful

in the case of rust, you're implementing most of the thing yourself

rust async/await is just syntax sugar

but syntax sugar is nice

and you can take advantage of rustc and clippy lints

[late oar]

I don't feel like coding right now

[young ermine]

me neither but i just force myself because i've got nothing better to do 😄

way to burn out!!

[errant venture]

Sometimes u kinda force yourself for a bit and then it suddenly gets better and u get into it

At least for me its like that sometimes

[young ermine]

yeah no doesn't work for me lol

i have no discipline so i just give up after a while

i started working on a new kernel project, we'll see how that goes tho

will try forcing myself a bit more, like you said, and maybe i get past the point of giving up

[errant venture]

Progress thread wen

[young ermine]

when i have a working scheduler ;)

[errant venture]

Damn

[young ermine]

last time i stopped on that

[errant venture]

Which language?

[young ermine]

right now it's C

but i might add some C++

for drivers or something

[errant venture]

Interesting

[young ermine]

yeah i hope it works out, i kinda want loadable drivers but we'll see how it goes

[errant venture]

Should be doable

[young ermine]

i wish i knew how to do that! i'll live and learn i guess

not the thread for this talk tho :^)

[errant venture]

True

[young ermine]

i'll probably talk about it in some of the on-topic channels

in the upcoming days

[errant venture]

Ill be waiting

[young ermine]

ill try my best

[late oar]

yeah sometimes that works. But I feel like right now it won't

I need a pause and I'll come back to it in a few days probably

[errant venture]

Yeah we all need time off sometimes

[late oar]

btw I've been removing the mutexes I have around my scheduler and process structures. Now I have 90 compilation errors and I need to fix all of that

(which is my I am not motivated right now)

I will be using interior mutability to lock only the parts that are needed, when needed

[late oar]

Yesterday evening I decided to start implementing pushlocks

[late oar]

actually I am not sure of where I should have mutexes

[late oar]

?

[solid rose]

discord being stupid

[late oar]

[late oar]

currently struggling with refactoring

[nova sparrow]

this OS looks pretty cool

I was reading through this channel and idk why people are so hateful towards any OS that runs on older hardware

[errant venture]

huh?

[late oar]

I have successfully migrated my blog from OVH to Clever Cloud (the company I work for), meaning I won't have to pay for that anymore (my company offers me the hosting)

Since I didn't want to use an external service to collect analytics on that website, I wrote one myself a while ago. While I migrated the blog, I also externalized that service to a separate app, so that I can use it with other websites/service (which will be useful when Maestro has its own website)

[desert hearth]

thats cool - did you say your company is also using maestro internally?

that would be fun to host your own website on your kernel

[late oar]

They would like to try it when it's advanced enough

[late oar]

Indeed!

[solid rose]

Now that's badass

[late oar]

I have 95 compilation errors to fix

zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz

[late oar]

19 errors remaining

[late oar]

currently implementing RCU

[pastel summit]

great, RCU is really helpful

for lock ordering + liveness issues in particular if you can RCU defer free a structure it just dissolves them

[late oar]

yeah I am doing it for lock ordering issues, and also because I can't get my code to compile without unsafe blocks or mutexes that could be avoided

[late oar]

you implemented it, right? do you happen to have a link to your implementation by any chance?

I have troubles with mine

[desert hearth]

https://github.com/Keyronex/Keyronex/blob/master/kernel/kern/rcu.c

[fringe pike]

if you want a less fast and more rust-y solution, you can instead implement it by making a function that sends an FnOnce to be executed on another core once they are definitely outside of an rcu critical region

and then do like ```rs
fn rcu_store(dst: *const T, value: T) {
let old = atomic_swap(dst, value);

let mut rc = Rc::new(old);
for core in cores {
core.run_on(move || { let _ = rc; });
}
}

[late oar]

oh well, I'll implement that later

for now I'll use mutexes so that I can at least compile and test my code

[late oar]

nevermind, that's annoying without RCU too

[late oar]

tbh I don't understand how it works. what is a "generation" is that context?

[pastel summit]

a generation is the period over which every core passed through at least one quiescent state

[late oar]

what happens when it overflows?

[pastel summit]

that would be a problem on the m68k port, i should change uintptr_t to uint64_t

[late oar]

in any case, that means there will be some point at which you will have a problem, right? or will it be after so long that it doesn't matter?

like, if the machine is running for 10 years straight (idk if that's enough for an overflow)

[pastel summit]

generation can increase (if all goes well) at the same rate as the scheduler tick

assuming that's 1/100th of a second, well, it'll last for a long time indeed

namely about 5 billion years

[late oar]

right

[pastel summit]

i still find that a bit dispiriting for some reason, it'd be nice to run forever, but it's safe to say it won't be a problem anytime soon

[late oar]

ngl: I am really struggling to make linked lists in between process structures (to have a list of the process's children and a list of the processes in the process group)

a linked list in itself is simple, but making it so that it fits the typing rules of rust is very hard

[late oar]

okay so I gave up on that for now. I am using a Vec of PIDs to point to other processes (as I was doing before). I just want my code to build (which it does now, but I hate it) so I can iterate on it

The pull request if you're curious: https://github.com/maestro-os/maestro/pull/42

(yeah there's a lot of files that have been modified but that's because I am now doing interior mutability on the Process struct and since it is used everywhere, I had a lot of calls to lock to remove)

[late oar]

It seems I am able to run a 32 bit program with a kernel compiled for 64 bit, but it crashes directly after

I have a Stack-Segment Fault, first time I ever had it. And then a Double Fault

[shell tusk]

Wonder if its your stack frame being set up wrong for iret

User iret and kernel iret are different in 32 bit iirc

Unless it doesnt matter fir long mode

[late oar]

that could be the reason since the kernel does not crash the same way in 32 or 64 bit

by any chance, do you happen to remember the difference?

[magic cloud]

idk if I pulled this outta my ass or not, but I think when returning to 32-bit code in 64-bit, you need to use iret

instead of iretq

[shell tusk]

theres some more things pushed on the stack

[late oar]

how queer

I must enquire this to my supervisor post-haste

[fringe pike]

it's not possible afaik

[late oar]

fixed: #x86 message (tldr: padding in the TSS)

[late oar]

I haven't worked much on it since, because I don't have time for it (having a social life is bad for osdev)

Currently the init process crashes right after it starts but I know why.
When I am unmapping pages of virtual memory, instead of unmapping only the pages in question, I unmap the entries in the same table, page directory, pdpt, etc... because of a logic error (I set the entry to 0 at each iteration without checking if other entries remain in the table)

[soft depot]

having a social life is bad for osdev
nah, having a life in general is bad for osdev, lol

[late oar]

currently trying to understand why the CI of Maestro can't compile integration tests anymore. I have this errors. I am compiling them for musl and the Rust targets for musl are supposed to be shipped with it included

  = note: /usr/bin/ld: cannot find crt1.o: No such file or directory
          /usr/bin/ld: cannot find crti.o: No such file or directory
          /usr/bin/ld: cannot find crtbegin.o: No such file or directory
          /usr/bin/ld: cannot find -lunwind: No such file or directory
          /usr/bin/ld: /home/user/runner/_work/maestro/maestro/inttest/target/i686-unknown-linux-musl/debug/deps/libstd-124d8ed4ba350451.rlib(std-124d8ed4ba350451.std.d8c575fd57905d02-cgu.02.rcgu.o): in function `std::sys::pal::unix::os::home_dir::fallback':
          /home/user/.rustup/toolchains/nightly-2024-09-18-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/sys/pal/unix/os.rs:743: warning: Using 'getpwuid_r' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
          /usr/bin/ld: /home/user/runner/_work/maestro/maestro/inttest/target/i686-unknown-linux-musl/debug/deps/libstd-124d8ed4ba350451.rlib(std-124d8ed4ba350451.std.d8c575fd57905d02-cgu.06.rcgu.o): in function `<std::sys_common::net::LookupHost as core::convert::TryFrom<(&str,u16)>>::try_from::{{closure}}':
          /home/user/.rustup/toolchains/nightly-2024-09-18-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/sys_common/net.rs:210: warning: Using 'getaddrinfo' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
          /usr/bin/ld: cannot find crtend.o: No such file or directory
          /usr/bin/ld: cannot find crtn.o: No such file or directory
          collect2: error: ld returned 1 exit status

[late oar]

I think the docker image that runs the CI might be missing the musl-dev package (although I think it should be provided by Rust ?)

[late oar]

turns out the command to install the rust musl toolchains (rustup target add i686-unknown-linux-musl and its equivalent for 64 bit) have no effect when done in the dockerfile but they work when I do them by hand

[fringe pike]

lol what

im gonna guess that it's because you have rust from outside of rustup

[late oar]

I don't think so. My commands to install Rust look like that:

RUN curl https://sh.rustup.rs -sSf | sh -s -- -y
ENV PATH="/home/user/.cargo/bin:${PATH}"
RUN rustup target add i686-unknown-linux-musl
RUN rustup target add x86_64-unknown-linux-musl

the full dockerfile: https://github.com/maestro-os/github-runner-docker/blob/master/Dockerfile

[fringe pike]

ah okay then wtf

[late oar]

yeah

[late oar]

I think the rustup commands are just missing --toolchain nightly. I'll test with it

[late oar]

so, I've got my integration tests to work again on 32 bit Maestro. Now I will attempt to run 64 bit tests on 64 bit Maestro, and then 32 bit tests on 64 bit Maestro.

[late oar]

okay so I think the 64 bit program has been loaded correctly. It is now attempting to use the syscall instruction but I didn't enable it, so imma do that

[late oar]

okay so I am implementing support for the syscall instruction and now I have random GPF because of stack corruption when I have a nested IRQ 8 I think?

I'll go sleep and debug this tomorrow

[white monolith]

This is a very interesting project.

[late oar]

thanks

@white monolith are you working on an operating system too?

[late oar]

fixed: wrong setup in the MSR. I was writing a 64 bit address in 0xC0000081, which clobbered the space for CS/SS

[white monolith]

Sorry for my late response. Not yet, I have plans to write one but haven't yet gotten around to starting.

[worn cosmos]

I'm super late to this conversation by almost a year, but this kinda annoys me tbh. Idk it's just unnecessarily attacking a project. This has already been settled and talked about a shit ton and it's not really my place to say anything but I will anyway cos yeah.

[analog crane]

if you're late by almost a year why are you even feeling the need to comment on this?

[worn cosmos]

eh I was just looking through near the start of the thread and felt like mentioning it. I really don't need to (and I agree it's not really a meaningful contribution) but I tend to just say stuff when things annoy me tbh. Maybe unnecessary but yeah.

[analog crane]

it is unnecessary

you know, sometimes the good will i have towards others yields nothing in return but shit like this

i shouldn't have defended you against an unprompted attack yesterday and that was that, thanks for letting me know

[worn cosmos]

sorry I'm not trying to attack you specifically, it's just a certain thing you said. Thanks about that yesterday btw.

I don't want to be offensive to you (and I apologise if I have very much).

that was not the goal.

[analog crane]

it's more that the convo was settled and there is a whole thread about that including myself apologising to the creator of the project (which is a literal mod nowadays) yet you felt the need to reply (and ping me) after 1 year of that conversation happening

that's all

[worn cosmos]

yeah sorry that's true, makes sense.

[worn cosmos]

(just btw I've also defended you in other servers where you aren't there when you've been attacked as mod - just saying, it isn't one way. I thank you tho)

[analog crane]

well thanks for that and apologies accepted

and also don't feel obligated to defend me in other servers, though i appreciate that

[worn cosmos]

nah not obligation, you're just a good mod/admin and half the ppl that complain are just people who've been quite fairly banned xD

also half of them are people who are just anti-queer and they really piss me off personally so that's also part of it lol

anyway sorry to clog up your thread rfc

[nova sparrow]

No, you deserve being called out for this. When I read through this thread I was also bothered by your comments. Attacking a project for choosing to target an older platform is just stupid; some people want to target older machines. Not everything needs to use smp or use uefi. Not everything needs to be the next mainstream os

With that said, if you apologized then fair enough, I do think your initial comments were shitty but I respect that you were willing to apologize

Hating for no reason is bad

[tough onyx]

that is not why it was attacked though

[magic cloud]

-# here we go

[tough onyx]

and anyway this is a year old comment, no need to bring this up again

[nova sparrow]

What valid reason was there then

[tough onyx]

read the actual convo first

the problem was it getting so much attention on HN

[analog crane]

i deserve being called out for this... 1 year later after i already apologised? not sure what is the worth of apologies to people who think ones who apologise should deserve to be constantly called out for something even after the apologies

also like abbix said, the whole thing was about how much attention the project got while other projects here and elsewhere were more technically competent yet got orders of magnitude less recognition

the way it was expressed was bad though, and it seemed, rightfully so, like an attack on maestro or rfc

[nova sparrow]

That is no good reason to call out the author, that's not their fault

I read through the context and it didn't excuse what happened

[analog crane]

exactly, and that is why i apologised, but i still hold the same opinion with regards to HN and the techbro collective

[tough onyx]

this happened a year ago, no one cares anymore

[nova sparrow]

Well tbh on that front I agree with you 100%

If you want to attack HN I understand, the kind of shit that gets their attention isn't always the best

There are some good discussions there but it's the minority

[analog crane]

it is not rfc's fault the techbro collective decided to hype the project up all at once one year ago

[errant venture]

Rfc himself agreed lol, it's not like he doesnt know how his project compares to others

[analog crane]

the attacks that were, or seemed to be, directed towards rfc or Maestro were erroneous and wrong and i apologise for those, which were said when everyone was kind of seething and riled up anyways

not that the latter is an excuse for wrongly attacking someone or their project, but you should get the point

[errant venture]

Serenity os has more stars than the Linux kernel

Let that sink in

[tough onyx]

what

no

[analog crane]

damn

wtf

[tough onyx]

linux has 184k

serenity is like 30k

[errant venture]

Nvm

[nova sparrow]

It's not the weirdest thing they've latched onto but tbh I think the problem is that most of the HN community has no idea about OS development and what really makes a given OS project notable in the grand scheme.

[errant venture]

I misremebered Linux star count lol

[analog crane]

thank god

[errant venture]

But more than the bsds for sure

So by that metric its a better os

Freebsd has 8k

I guess serenity is at least 3 times better

[analog crane]

it's not just about OSes, they are like that for other stuff too, especially when they see something written in rust they all go "awoooga" without regards for whether the project is good/bad/deserving/etc

i bet if like uACPI was in rust infy could pull something like "ACPI reimplemented in Rust: Why every OS should use this library for safety and performance 🚀 " and get 3k stars overnight

[errant venture]

X written in Rust gets tech bros excited

[errant venture]

Lol

The acpi crate exists unfortunately

Although its worse than lai

[analog crane]

same boat with the bootloader crate :p

[errant venture]

Lmao

[analog crane]

or x86-64 crate

[errant venture]

Is it as bad as I think

[analog crane]

yes

[errant venture]

Lmao

[analog crane]

i think up until a while ago it was BIOS only and text mode only, but i may be misremembering

idk how much it has been worked on since

[errant venture]

Lool

[nova sparrow]

Anything remotely low level they just have no clue about. There are some legitimate old school programming wizards hanging out there but they're few in number

[errant venture]

Rust users are used to writing cli apps so that will fit right at home

[tough onyx]

maybe the techbros' parents should have used more safety

[nova sparrow]

Nothing wrong with good ol text mode or bios

[analog crane]

depends

on the definition of "wrong"

when you're a "cutting edge bootloader/OS 🚀 " i'd argue it's wrong

you can't even run on UEFI like that, which is quite important

if you're targeting old hardware and you're doing something niche for yourself or whatever, then who cares

[errant venture]

Yeah

Nothing wrong with bios and a plain fb since thats forward compatible

But text mode is not

[analog crane]

or legacy VGA modes while we're at it

[errant venture]

Or a banked fb

[analog crane]

the horrors

[nova sparrow]

I've used legacy VGA modes for games

It's not that bad

Well the planar stuff is

[errant venture]

Oh u want to draw a pixel at 430,457? Sure let me just switch the bank

[nova sparrow]

Mode 13h is fine

[nova sparrow]

That's VESA not VGA

But just use a page fault handler to emulate an lfb

Like Microsoft did

[analog crane]

or use an actual lfb :p

unless you really need to target old old hardware

[errant venture]

That's kinda smart actually

[nova sparrow]

Microsoft figured it out in like 1992

VFLATD

[errant venture]

Thats close to when banked fbs were ceasing to exist

[analog crane]

also it kinda depends, you cannot always do that, for example if your fb is smaller than a page and banked

unless you pf on literally every access

though i'll assume they are all 4k aligned

[nova sparrow]

When would that ever happen

[analog crane]

i have no idea, it could be there's some video mode like that

[errant venture]

Then ud have to single step flag or emulate the access itself

[nova sparrow]

In a real practical machine when are you dealing with anything other than banking 64k windows into a framebuffer

[nova sparrow]

I don't think so, the VESA spec doesn't do that

Nor does any practical PC video adapter

[analog crane]

that's good to hear, i guess, for anyone who needs to do that

[late oar]

wtf is happenning here?

[errant venture]

Someone got offended on your behalf

[nova sparrow]

In 1992 they were still pretty common but they were starting to fade away around that time

[tough onyx]

gen z smh

[analog crane]

these damn woke liberals

[errant venture]

Yeah

[nova sparrow]

I don't see the problem with using text mode, it's a lot simpler if you don't have a problem with only running on older hardware, a lot of which isn't that old

[magic cloud]

what about... displaying non-text stuff

[analog crane]

ascii art :^)

or, well, cp437 art :p

[errant venture]

Depends on your goals

[nova sparrow]

Then go into graphics mode but if you don't need to, nothing wrong with using text mode

[worn cosmos]

imho text mode is absolutely fine (especially if you've falled victim to the osdev barebones tutorial) but almost always you'll end up just switching to graphics mode anyway when your project gets large enough or you get interested by graphics at all.

[little escarp]

the problem is that text mode is going the way of the dodo on real hardware

so unless you want your os to be stuck in vms you have to use a framebuffer

[errant venture]

What the hell is the way of the dodo lol

[magic cloud]

dodo is a bird that went extinct

[little escarp]

going extinct

[errant venture]

Ohh

[nova sparrow]

Older hardware still exists you know

[worn cosmos]

yeah, or as has been said, if you have specifically very old hardware laying around then it may be easier. I kinda wanna find some old 16 bit machine and write some sort of OS for it (although it'll likely end up being in real mode - eughhh), or even pdp11

[little escarp]

well my laptop doesn't have text mode

i'd like to be able to test my os on my laptop

so on and so forth

[nova sparrow]

Tbh I mostly stick to text mode and older stuff like that because my OSdev experience is grounded in my DOS game development experience and I try to use the same tools, hardware, techniques

I experimented with vesa but never wrote a game going above 320x200

[shell tusk]

same

[nova sparrow]

Ah, several of mine do

[little escarp]

i do also have hardware that still has it

and well, uefi is not that new

and uefi does not provide you with access to vga text mode

so unless you use csm you're forced to use a framebuffer

[nova sparrow]

I have hardware that supports UEFI and text mode (not at the same time I don't think but it does CSM)

But I just ignore UEFI

[magic cloud]

that sounds cursed

[shell tusk]

wonder if there was some super early efi that did text mode or if its always been a nono

[nova sparrow]

What part?

[magic cloud]

uefi text mode

[nova sparrow]

I mean the VGA card still exists so if you can program it manually

Why not

Execute the video BIOS in virtual 86 mode to set text mode?

[worn cosmos]

tbh half the reason for me is that I don't really like the text mode font 🤣

[nova sparrow]

Oh I love it

What's wrong with it

[worn cosmos]

well more that there's a specific font I love for osdev which I like to use tbh

[ancient galleon]

you can reprogram some vga registers and change it don't worry :^)

some old dos applications even changed it on the fly to get a mouse cursor in textmode

[keen turtle]

That reminds me of how I once tried to set it to 1 scanline and then have a font whereby the glyph corresponded to the codepoint (e.g. 0b00000000 would be empty, 0b11111111 would be filled), in order to have a black-and-white display with custom "pixels" ._.

It didn't work

[agile venture]

I've ignored this a few times already because I mainly lurk here but I'd appreciate if you'd not slag my crate off like this - I've been very open that it's less developed than uACPI, it says it won't be able to parse most tables in the readme, etc.

It's a personal project that I've not had time to work on, but it existed before uACPI was an option

You've repeatedly openly said that it's shit, poor quality, which is unpleasant and not constructive

[errant venture]

yeye sorry

its called "acpi" which sounds like its the ACPI crate to use

so id expect flagship quality

but sorry for shitting on it explicitly

[agile venture]

that's more a lack of imagination on my part tbf

unfortunately it is the most developed pure-Rust ACPI implementation

[errant venture]

fair enough

I thought there was some sort of false advertising going on initially

but u can definitely do better!

its still recursive right

[agile venture]

feels like a stretch - the names exist within the rust crate namespace, do you think the fat crate is developed by microsoft?

[errant venture]

is that a common thing in rust to name library-for-thing as thing?

[agile venture]

yeah I've realised later that I probably shouldn't use parser combinators - you use a more traditional VM approach no?

AML's weird in that it's half a normal bytecode and half a weird full declarative languaage I feel

so it's hard to parse properly with either approach

[agile venture]

I'd say so

[errant venture]

yeah aml is basically the source language encoded in compressed format

[agile venture]

Maybe I should've called it acpi-rs or something

[errant venture]

what i found works best is have a lookup table per AML opcode that gives u a "specification" struct that contains an array of micro-ops to execute to run the opcode

some of the micro-ops pause the execution of current opcode and move on to the next

those that would recurse basically

[errant venture]

nah if thats a common thing in rust, first come first serve u get the acpi crate

also feel free to use my tests, i have like 65 at this point, and they test quite a lot of edge cases and ms-specific behaviors

[agile venture]

interesting, yeah I need to dig into how you're doing it at some point, but yeah lack of time currently

[agile venture]

cheers, will do! And I appreciate the apology

anyways sorry didn't mean to derail this thread

[errant venture]

yeah i have a tendency to shit on this if it goes unpunished

since u werent here and we couldnt have a productive discussion about it

sorry for that

[agile venture]

thanks, and yeah that's fair, I've been meaning to talk here a bit more but stuff like this is offputting

[errant venture]

yeah fair

[errant venture]

i can explain in depth when u have time if you're interested in exploring other approaches to parsing

[agile venture]

yeah cheers I'd appreciate that when I get round to a rewrite!

[errant venture]

cool cool

[late oar]

This thread has become the drama agreggator

[late oar]

I wanted to remove only one insertion from the first message of the topic to have only neofetch displayed on it, but clicking the cross removed both insertions and now the topic does not have images anymore and I don't know how to put it back (I think I can't)

[lunar plover]

You can't

[late oar]

I'll make a new thread when I have stuff to show then

[late oar]

so, I now have support for the syscall instruction. Now, let's make a new syscall table so that the 64 bit syscall IDs match those from Linux

[late oar]

so I have a few syscalls executed, then the program segfaults. turns out it also does so in 32 bit, so I checked the commit history to know when this bug was introducted and it's when I started loading the ELF starting at 0x1000 instead of 0x0 (I don't have ASLR yet). Relocation issue I guess?

[late oar]

(turns out the kernel does not have to perform relocations. the linker or the program itself (if statically linked) are doing it themselves)

Aside from that, I think my goal I am setting myself for my OS for 2025 is self hosting

(only building the OS on itself. not having qemu running on it)

well maybe that's a bit ambitious. I need Python to work in order to build rustc

or I can just try to install it from rustup. That would require network support though

[late oar]

I've got fork and company to work for 64 bit programs

Same for execve now

[late oar]

|| actually no, I failed register initialization ||

[late oar]

so now it seems I have memory corruption

[late oar]

ok so it seems I have a page table being used as a stack during an interruption for some reason

okay turns out that was a stack overflow

4 pages is not enough for the kernel stack. I have 16 pages now

[fringe pike]

you should add a dynamic instrumentation for this

mine looks like this: ```arm
.text
.extern stack_bot
.extern stack_danger_zone
.extern stack_exhaustion_fail
.global mcount

mcount:
blt gp, sp, 1f
li t1, 4<<10
sub t0, gp, t1
blt t0, sp, stack_exhaustion_fail
unexpected_stack_pivot: j .
1:
ret

stack_exhaustion_fail: j .

.bss
in_stack_exhaustion_panic:
.quad 0

this is riscv asm but same ideal

i set gp to the bottom of stack + 4k

and if the stack is within [gp - 4k, gp] then i hang in a stack_exhaustion_fail infinite loop

[late oar]

that's indeed a good idea

[fringe pike]

mcount is called at the start of every function if you compile with -Zinstrument-mcount iirc

yeah

[late oar]

I'm putting this on my todolist

First I'll make sure my integration tests work

currently implementing stat, fstat and lstat. I didn't do it earlier because 32 bit musl is using statx instead

[late oar]

‼️‼️

I've got my integration tests passing in 64 bit

incredible

now I just need to make sure everything still works in 32 bit, then I'll try to use the installer with it to make sure everything works, and then I'll update the documentation and merge into master

and next I'm doing the page cache

[soft depot]

🔥 let's go

[late oar]

turns out I have a scheduler issue

[late oar]

So Maestro compiled for 64 bit is able to run both 64 bit and 32 bit programs, but Maestro compiled for 32 bit does not work anymore because of another scheduler issue

Since I can't find why it doesn't work, I think I'll got update the kernel's documentation to add the 64 bit version to it, and I'll got back to the scheduler issue later

[late oar]

currently trying to cross compile the maestro installer to check that it is still working before merging 64 bit support into master

[analog crane]

do you use uACPI yet :^)

just curious

you were probably already asked many times

[errant venture]

whats the ironclad integration status btw

[analog crane]

⏳

[errant venture]

lmao

[analog crane]

i intend to get it done soon™️ though, so don't worry

[errant venture]

lesgo

[late oar]

I will likely try to implement it myself instead of using a lib

[analog crane]

oh yeah i do remember you saying that

[errant venture]

big if true

(if you understand the scope of that)

[analog crane]

big if true (pun definitely intended)

[errant venture]

or use the rust crate

but no the acpi rust crate owner told me they were going to rewrite it

to make it non recursive

and support missing ops

like iirc it doesnt support references at all rn

[late oar]

(I very likely don't )

[magic cloud]

Side effects include smashing Corvettes

[late oar]

I have memory corruption

I want to die in Minecraft right now

[errant venture]

not possible in rust

[cursive lintel]

https://github.com/Speykious/cve-rs

[errant venture]

lies

[late oar]

that's very likely a memory allocator issue

returning a pointer to memory that is already in use

the issue is hapenning only when the kernel is compiled for 64 bit

huuuuuu

maybe I should add build and running the installer into the CI, but that's a pain to build

[late oar]

can't wait to be working on SMP support to scrap parts of my memory allocators to make them support concurrency

[late oar]

okay so I just found why and fixed it and I really want to bang my head in the wall in minecraft

https://github.com/maestro-os/maestro/pull/37/commits/a5c72df5866969eae7ae88387ba156fe0064db94

suprising that the issue didn't arise earlier

[errant venture]

btw assembly memmove is slower than a naive implementation for LTO

[late oar]

huh

[errant venture]

at least that holds for C

but id imagine for rust as well since that uses the same backend

[late oar]

well maybe idk. One thing's for sure: I cannot implement it in Rust since Rust's libcore is expecting it to be present to work

iirc it may call it implicitly

[errant venture]

ah right

[late oar]

but I may be able to do it in C I guess

[magic cloud]

Nono that isn't safe

[late oar]

assembly isn't safe either

[magic cloud]

Smh no wonder you got memory bugs, everything must be written in blazing fast, safe rust

[late oar]

you always need some unsafe somewhere. When you write casual Rust, that unsafe is already written for you in the standard library

[fringe pike]

you don't need unsafe

you can use compiler bugs instead

[late oar]

yeah I would prefer using unsafe :3

[fringe pike]

my personal favorite is the one that lets you convince the type system that two types were the same all along

its like transmute, except better!

because there are no pesky checks

[late oar]

how do you do that?

[fringe pike]

https://github.com/rust-lang/rust/issues/135011

[late oar]

so I just lost 4 hours trying to figure out why a kernel module could not find the kernel's symbols when loaded.
Turns out I was just using the wrong disk so the module was not compiled against the right kernel

[fringe pike]

lmfao

you should probably have a check of some kind

[late oar]

well I don't really know how this could be checked

It just knows the symbols do not correspond because they don't have the same name (the hash at the end differs)

I usually only work with a single disk. I just modified my grub.cfg temporarily to point to an initramfs to debug it and I forgot to undo the modifications

[civic copper]

why not limine boot loader

[worn cosmos]

they must just not want to be part of the limine cult group :P

they have actually talked earlier in the thread already about limine tho

[late oar]

I think I will likely add it as an option in the installer someday

[analog crane]

i am so sorry

in any case i'd be more interested to see if maestro boots at all as a mb2 kernel with Limine and that's it tbh, i wouldn't really care about much else personally

idr if we tested that already

[late oar]

well I've not tested it myself yet

although limine looks nice so that could be a potential replacement for grub

on a side note, this is me trying to stabilize 64 bit support since a few weeks:

[desert hearth]

Lol

Honestly it's quite impressive where maestro it at. Did you end up getting 32bit userspace on a 64bit kernel working?

[late oar]

yes I did

I have a mix of 32 bit and 64 bit programs launching each others

[desert hearth]

Haha cool

[late oar]

I have a deadlock when trying to run a signal handler right now though

[errant venture]

Can maestro configure and compile gcc?

[late oar]

I didn't attempt it, so probably not

although I want to have a page cache and SMP support before attempting this (otherwise that's going to be very painful)

[late oar]

okay so now bash is crashing when receiving a signal

[late oar]

well signals are completely fucked up. let's go to sleep

[analog crane]

signals are so bad

and that's not even coming just from a nobody like me, mr korona PhD agrees

[errant venture]

maybe they would be better if there was an anti-signal userspace cli

[little escarp]

there is its called sigprocmask with SIG_BLOCK

[errant venture]

🤯

[little escarp]

or well, thats for the whole process

theres also pthread_sigmask

[pastel summit]

they are evil

the ones that are used to forward synchronous exceptions (sigsegv, sigbus, sigfpe etc) to the thread are alright, the asynchronous side of it is horrible especially in how it interacts with multiple-threaded processes

[nova sparrow]

yeah, but aren't they a necessity when cloning Linux

[shell tusk]

Theyre a posix thing yeah

[late oar]

btw this is the PR of the implementation of long mode: https://github.com/maestro-os/maestro/pull/37

[brisk gulch]

is maestro live ???

[late oar]

live?

[brisk gulch]

alive

[late oar]

well yeah, I am continuously working on it

[brisk gulch]

🦆

[analog crane]

i was just complaining about them

not saying they shouldn't be implemented

[nova sparrow]

Ah fair

[late oar]

I now have an integration test to check whether signals work, so that I am aware next time they stop working

[late oar]

I have 1973 IP addresses reading the RSS feed of my blog everyday

The day I post a new blog article, it's going to be everywhere lmao

[elder sonnet]

spicy

[late oar]

neofetch seems to be working again, with the kernel running in 64 bit. Nice

although cat seems to make the kernel deadlock? (currently investigating)

[late oar]

grub-install running successfully under x86_64

now I am attempting to install a full system to see if all of it works

[late oar]

bash fork bomb working

[late oar]

I am currently rechecking everything, but it is very likely that x86_64 support will get merged this evening

[late oar]

oh I know what I forgot about: fp state save and restore for signal handlers

[late oar]

and, merged!

now has come the time to implement the page cache

[late oar]

(I didn't do it in the end, I'll do it when it becomes an issue)

[late oar]

I have just made a flamegraph of my kernel running ls -lR / with 1GB of memory and here it is (open it in a browser to explore it)

87% of the CPU time is spent in the filesystem, so I think I really need to implement that page cache

[elder sonnet]

@balmy plume idk if we can do this too or if ostrace and the profiler can provide the information to pull something like this off?

[balmy plume]

ostrace can do this already

[little escarp]

the kernel profiler would require sampling the whole stack for this no?

[balmy plume]

well, not generate a flamegraph but it can tell you how much time set spend in libblockfs code / block device code / etc

sampling the whole stack is not the problem but somehow making sense of the data

as the kernel doesn't know where DSOs are mapped etc

[elder sonnet]

Ahhh yeah that’s a thing

[late oar]

when I have the page cache and SMP, I may attempt to build gcc or clang on the kernel (Astral moment)

[late oar]

Currently implementing a LRU for the page cache

[late oar]

trying to find motivation to work on this

[mystic kestrel]

https://tenor.com/view/carrytheboats-davidgoggins-pump-lift-benchpress-gif-23301293

[late oar]

update: stuck in refactoring again while trying to implement the page cache

I think I figured how I should implement it, now I just have to manage to actually do it

[late oar]

been kinda obsessed about that since a few days: https://www.youtube.com/watch?v=fks3PBodyiE

I want to do it too

[tawny drum]

is it x86?

[devout blaze]

No. It think it's arm or riscv

[tawny drum]

lame

[soft depot]

It's ARM

Still very impressive

Highly recommend a watch, it's quite a nice video

[inner pilot]

its "just" a rock 5 compute module

[latent anchor]

yep but it's still impressive

board design is hard when there's pcie or usb involved

impedence matching and so on

[young ermine]

imo that video was good from hardware standpoint (i know nothing about hardware) and painful to watch from software standpoint

[inner pilot]

well

that's about the same as it is on normal arm sbcs

[young ermine]

i mean, the software part was painful because the person barely knew what they are doing

or at least it seemed like it

and idk how good it was from hardware standpoint but i enjoyed it

[late oar]

If I try to make a computer, it will likely be ARM or x86 (most likely ARM)

[latent anchor]

i like system on module designs

like the MNT reform

[late oar]

(yes I am still working on the kernel, still on the page cache and implementing file mapping with mmap at the same time)

[late oar]

So I finally got my code to compile.
For now it is crashing during the boot process, I am fixing the bugs right now.
Although, it seems to be MUCH faster than before. I will measure when I get everything working

[late oar]

update: now with the page cache, ls -lR / is taking 0.7 seconds

I am not used to it being so fast. I am actually stunned right now

[fringe pike]

does ls -la / cause SMAP violations with the page cache?

[late oar]

why would it do that?

[fringe pike]

i mean myldero complained it did that on the master branch

so

[late oar]

mmmmmh

[late oar]

I think I fucked up memory management. Basically when I execute a command, when it exits, bash does an infinite loop in malloc, so I guess the memory page has been shared with the other process even though it should not?

Today I will add more integration tests to figure this out.

[late oar]

I rewrote the tmpfs to make it simpler. Now I need to make all the integration tests pass

[late oar]

Currently implementing that thing where you check the dirty flag in page table entries to figure out if the content of a page should be written back to disk

Also I am more and more convinced that having kernel module source code in different Git repositories was a bad idea

[teal dock]

I am now

[late oar]

🎉

[latent anchor]

how did i forget to leave a star

[late oar]

😔

[late oar]

Currently implementing kernel threads so that I can have a thread periodically writing back pages that are too old

[late oar]

kernel threads are almost working, just need to fix somthing with the interrupt disable flag

[late oar]

turns out I am currently removing the transaction system I described in https://blog.lenot.re/a/mapping-consistency because it makes everything too complicated

I'll just call the oom killer to have non-failable memory allocations

[fringe pike]

what's with the font size on your blog btw

[late oar]

I like big text

[fringe pike]

i see

[fringe pike]

kinda cringe tbh

[late oar]

failable memory allocations are more complicated to handle and slower because I need to gather data to rollback the operations that won't be used most of the time. If I have non-failable one, when there is no memory left, I can just shrink the cache most of the time

[balmy plume]

It's not obvious that failable allocations require the ability to rollback anything

[late oar]

when you chain several operations that require memory allocations, if the first allocation succeeds but the next doesn't, then you need to rollback the first operation to retain consistency before returning an error.
If you have only 2 operations that's fine but when you start chaining a lot, that makes everything complicated

[balmy plume]

You can first allocate everything, then commit everything

[nimble grove]

I did it it was fine and not that difficult

[balmy plume]

I don't see how rollback can even work

Since concurrent threads can observe intermediate states

Unless you halt them all

[nimble grove]

i think he meant just like

a = new thing;
if (!a)
  return;

b = new thing;
if (!b)
  free a;
  return;

oops

early enter

[fringe pike]

they can't

because you do it while locks are held

[nimble grove]

this type of thing

[nimble grove]

also this

if relevant

[balmy plume]

They can observe it from userspace

They don't need to enter the kernel

[nimble grove]

how

hes just talking about unwinding intermediate steps upon failure p sure

very typical and common thing to do in kernel code

[fringe pike]

its kernel state AFAIK

[balmy plume]

If he's just talking about kernel state, it's trivial to unwind

[nimble grove]

thats what we were saying

[balmy plume]

And this should be handled by refcounts and object ownership

[nimble grove]

she took the kids

[balmy plume]

I understood rollback as: "we first try to map this new mapping and if that fails we restore the old one"

which is certainly not possible without either halting every thread or user visible side effects

[nimble grove]

yeah usually if theres something difficult like that, you can avoid having to deal with it by just getting all the error cases out of the way before you do the thing thats hard to recover from (in this case, unmapping a range)

so like you could preallocate the new map entries you might need, ahead of time, stuff like that

[nimble grove]

well, there are ways

in particular you can invalidate the range and make any thread that faults on it block

you only allow them to proceed when this whole thing is done

[balmy plume]

that's true

[nimble grove]

this is easier if you have disposable page tables because then you dont need to worry about losing information about private pages or whatever when you invalidate the range

itll just Come Back as threads fault on it cuz it was stored elsewhere and the page tables were just caching it

[late oar]

I currently have a architecture-independant thing to store mapping inside. For that I think I am keeping the rollback thing.
However for the architecture-dependent thing (page directory/table/etc) it's a lot more annoying to rollback, and this is what I am removing right now

[late oar]

I've never thought of it that way. I've always filled it directly instead of doing it lazily but I think that would actually be a lot better than what I am doing right now

[late oar]

is there a non-annoying way to have reference counters on page tables?

[desert hearth]

you can use your struct page equivalent

[worn cosmos]

I may be misunderstanding you but I think you can use the avaliable field in the page table

[nimble grove]

Definitely not enough bits

[worn cosmos]

oh wow I just noticed now how small that field is

I never really looked at it properly

[fast halo]

like for each page table mapping level or just the top level?

[late oar]

Each level

[late oar]

My kernel now has the ability to make a process sleep for a given amount of time (needed that so that the kernel task that flush dirty pages to disk doesn't waste CPU cycles)

fixed my clock at the same time

[inner pilot]

nice

how do you do percpu data in maestro?

[late oar]

I don't (multiple CPU support is the next thing I am working on, before I attempt to run gcc)

[inner pilot]

oh

[late oar]

that's probably the best solution btw. I think I'll do that

[inner pilot]

how would that work?

[desert hearth]

You have one struct per page. Whoever is using that page can store some metadata there there (so for pmm I store freelist linkage there, etc). If the page is used for a page table, it stores a count of the number of valid ptes. Once it's zero you can free the page.

For me the tricky part was scrubbing the pte that points to the page to be freed, but I found it was only during unmap calls - in which case I already had the parent pt's address.

I hope that makes sense, that's written pre-coffee

[inner pilot]

ah i thought you meant refcount of pages in a single pt, that makes a lot more sense

[late oar]

@mystic kestrel have you tried using https://github.com/maestro-os/kern-profile with the last version of QEMU? I think it does not work. The flamegraph is all flat

[late oar]

I've got my CI passing for the first time since 2.5 months

I think I'm gonna cry

[errant venture]

Congrats

[inner pilot]

easy fix

just have a cargo clippy as ci

[late oar]

I have that, + other stuff

[inner pilot]

i have a clippy + debug build ci

[late oar]

I have clippy + build + build doc + miri + unit tests + integration tests (for x86, x86_64, and x86_64 in compat mode)

[inner pilot]

how do you do tests?

i have yet to figure out the custom harness stuff

[late oar]

I do my unit tests with that

for integration tests I have a userspace program that uses system calls and verifies that it did everything well

as an example, I try to create a file and write stuff into it. I check there is no error doing so. Then I try to read its content to verify it's there, then I do other stuff, etc...
And I do that for each filesystem (currently only ext2 and the tmpfs)

so now that I have the page cache I have noticed something weird: everything is much faster than before for the first commands I write, and then at the 4th command, or when I try to run neofetch, everything becomes super slow

also I think I have filesystem corruption

[inner pilot]

how do you test stuff like allocators?

wouldn't that need some sort of privileges?

[late oar]

I do it in unit tests, so in kernelspace

[late oar]

did you read that? https://os.phil-opp.com/testing/ this is where I learned how to use it

[inner pilot]

yea i read it but it's been a while

(so long as a matter of fact that back then i was still using the bootloader crate)

[teal dock]

I very much like cfg(test) in rust

[inner pilot]

yyes

i need to incorporate more rustisms in my code

i might have a look at how maestro does allocations, because i have no way of doing frame allocations rn 💀

i use the talc crate which just uses the hhdm as memory

[inner pilot]

@late oar is it okay if i cross-reference some parts of your buddy impl?

[late oar]

that's fine 👍

[inner pilot]

cool thanks

[mystic kestrel]

uh i havent

do u have it compiled agaist the correct qemu

[inner pilot]

@late oar how do you determine which memory goes towards which zone?

i saw that you use the hhdm address for the kernel zone? that didn't really make sense in my mind

[teal dock]

why even have zones for physical memory?

[inner pilot]

idk

ask the man

im learning how this works lol

[desert hearth]

for peripherals, some may only support 32-bit physical addresses.

[teal dock]

what would require 32 bit physical address?

[desert hearth]

or booting APs, where you need memory < 1M

[teal dock]

apart from isa dma

[desert hearth]

really old devices

[teal dock]

I mean, you could just reserve first 1 mib, but what about whole kernel, userspace and mmio zones?

could it just be for statistics?

[desert hearth]

hm

mmio could make sense in a platform-sensitive context - like riscv usually reserving the first 2G for mmio

but the idea of whole kernel/user/mmio zones I'm not sure about, maybe it's a typed memory thing?

[late oar]

On 32 bit systems I reserve the first GB of physical memory for the kernel, which is mapped at the end or the virtual space. This is represented by the kernel zone

The remaining is in the user zone

[inner pilot]

so user zone = kernel + user?

[late oar]

On 64 bit systems, everything ends up in the kernel zone, but when allocating for the user, the allocator can fallback to the kernel zone

[late oar]

The user can allocate from both the user and kernel zone, but the kernel can only allocate from the kernel zone (since otherwise it is not mapped)

For the mmio zone, that's just an unfinished thing for now. I don't really have mmio yet

[inner pilot]

ah

[late oar]

I think so. Anyways I just rollbacked qemu. I'll worry about that later

[late oar]

I'll write a blog article about the page cache. I have a lot of stuff to say about it

[inner pilot]

@late oar wait i just realized, your allocator doesn't actually care about holes

[late oar]

like holes in physical memory?

[inner pilot]

yes

[late oar]

indeed it doesn't

[inner pilot]

that changes so much lol

[late oar]

I'll have to fix that someday

[inner pilot]

i kept asking myself how tf this can work if you only ever register a single start + size

then i saw this

[late oar]

I was gonna implement SMP before testing gcc on Maestro, then I realized this is not necessary if I just want to compile a hello world

I can just test a hello world, and then implement SMP later when I will be willing to build more complex stuff

So I guess I will just merge my current PR when I don't find any bugs left (currently I have a deadlock and still filesystem corruption), then I am writing my blogpost, and then I port gcc and attempt to build a hello world with it

The PR, for reference: https://github.com/maestro-os/maestro/pull/46

[late oar]

just randomly discovered the du command works on Maestro

df seems to work too

[errant venture]

i hope i can reach this point as well

im also doing syscall compat

well and the vfs layout

[late oar]

maybe I should record videos of my OS

how

[errant venture]

yeah

or do streams

[late oar]

I think I've managed to make a good graph to represent how files management is made in Maestro

[inner pilot]

what software did you use for this? this looks like doxygen graphs

[late oar]

https://mermaid.js.org/

with the jetbrains plugin

[late oar]

I'm almost done writing my new blog article (about the page cache). I just need to re-read everything, do spell-checking, add a flamegraph and find a cover image (probably the graph I've just sent)

[late oar]

I like this font for Maestro (when I will have a desktop env): https://fonts.google.com/specimen/Nunito

[late oar]

or maybe I should make my own font(s)

[late oar]

Okay, time for me to review all of this:
https://github.com/maestro-os/maestro/pull/46

I will likely post my blogpost and Monday

[inner pilot]

holy shit 9k line diff?

[worn cosmos]

oh wow

[late oar]

yeah I tend to do that

[inner pilot]

lil

my current pr to remove the allocator crate is about 4k changed lines

[late oar]

I refactor stuff, then everything is broken, so I fix it, and then I get that amount of modifications

[inner pilot]

SAME

I happened to change my entire arch abstraction in the same pr

because why not

[late oar]

@inner pilot https://github.com/maestro-os/maestro/pull/17

:3

[inner pilot]

what the hell

[late oar]

That's the main issue I have with the way I manage this project

[balmy plume]

there are ways to do that without having 10k sloc change sets

[inner pilot]

yes, by pushing directly to main

[balmy plume]

No. We refactor Managarm code all the time without 10k sloc change sets

[errant venture]

yeah im not a huge fan of this ngl

[late oar]

btw I didn't talk about this, but in this PR I am removing the mutex I had around MemSpace (my equivalent of Linux's mm_struct).
Having a mutex around the whole structure real isn't a good idea

I still have one around the scheduler. I swear this is going away when I implement SMP

[late oar]

When I run bash into bash, I have both the child and parent bash crashing. I was investigating why and it turns out they somehow manage to swap their MemSpace???

like the child seems to be using the parent's memspace and vice-versa

[late oar]

I can't figure this out

help

[late oar]

I am now suspecting there might be a buffer overflow somewhere that is overwriting a binary tree

[late oar]

I now believe this is not the case