Managarm and related projects

[trim eagle]

Indeed

But no image viewer

Yet

[lament grove]

GN*ME 🤢

But fr nice progress though

[trim eagle]

GNOME DE best DE (I use GNOME BTW)

[lament grove]

The real problem is that they don't implement shit like server side decoration, holding all of wayland back

It looks fine if a bit too plasticy for my liking

[trim eagle]

java bringup ok

[lament grove]

nice

[golden maple]

waiting for prismlauncher port day 1

[rare prism]

ooo, when gimp

[carmine current]

more bug squashing progress: we fixed a subtle deadlock that caused spurious boot failures in ~2% of boots

and we now also run a few of our testsuites (posix-tests, kernel-tests) on github actions with KASAN enabled

[carmine current]

there was a missing irq lock in a capability transfer function that opened a small window where the following could happen:
irq -> reschedule -> ipc completion -> another capability transfer to the task that was just scheduled out

and that'd deadlock

[vestal sapphire]

ig what helped us is that the many-boots.py script was really good at reproducing that issue for some reason

[vestal sapphire]

os-test is now upstream

and I'm working on fixing a few issues it catches

new state

[carmine current]

also, more CI improvements

[native prairie]

Letsgo

[trim eagle]

Nice stuff

[vestal sapphire]

testing will continue until morale improves

[golden maple]

what's this

[vestal sapphire]

https://sortix.org/os-test

[vestal sapphire]

fwiw I reached out on sortix IRC asking is they have any suggestions for how I should implement machine-readable output of os-test

we'll see what happens

[vestal sapphire]

https://managarm.org/2025/11/03/os-test.html

[dense umbra]

holy shit new managarm blog post just dropped real

[trim eagle]

Managarm runs minecraft in the browser!

[odd schooner]

nice job!

[forest bear]

Bro tryna be astral so hard

[carmine current]

Nah, we're currently trying to make a newer jdk work

Both on astral and Managarm

It's blocked on mlibc locale debugging

This screenshot is not really a new achievement of Managarm, it's "just" running the WASM (or whatever that website uses) version of MC classic, this was already possible before

and it's not really playable because the controls are stupid (same on Linux)

[trim eagle]

Rage bait denied

And I’m pretty sure that it (Java Minecraft) would just work as is with LWJGL patches but there’s some other stuff and potential instability that we’re debugging first (and astral has the same issues)

In case you missed the memo, Minecraft is a collaboration

[dense umbra]

Yeah I dont see why itd not work with lwjgl ported over

Especially since we fixed the mlibc bugs

[trim eagle]

Yeah

[forest bear]

run fortnite and ill be happy

unironically i have trouble thinking of cool ports

[dense umbra]

wine64 fortnite.exe

[forest bear]

managarm pretty much has everything

[dense umbra]

ez

[forest bear]

fortnite doesnt even run on linux btw

[dense umbra]

skill issue

[forest bear]

epic games issue

[trim eagle]

Never. Blacklisting fortnite on the spot

[forest bear]

fortnite is fire

[upbeat smelt]

we should port easy anticheat :^)

[vestal sapphire]

Steam first tho

[upbeat smelt]

compile csgo from source :^)

[vestal sapphire]

The hardware survey dump would be hilarious

I mean honestly, with arsen's glibc port it can't be that hard to do?

[dense umbra]

me becoming part of the 0% that uses managarm

[high river]

Port Stardew Valley

Or Dolphin

[forest bear]

ooh stardew valley would be really neat

[wary wing]

Based! Good job!

[valid heath]

Who created the logo for Managarm?

[trim eagle]

@carmine current ^

You know who did right?

[valid heath]

Ah

@carmine current how did u create it?

[trim eagle]

As in he knows who did cuz I forgot lol

Idk if he himself made it

[valid heath]

Oh ok

[carmine current]

I didn't

I don't remember his name. It was some member of the old osdev server

Maybe @upbeat smelt knows

[fresh hornet]

bzt maybe. 😁 joking. I remember his avatar was like that. Some wolf.

[upbeat smelt]

i think their nick was brianush or something along those lines? i dont remember exactly though

[trim eagle]

That name does ring a bell

[upbeat smelt]

i think you could probably find out in the managarm server if you search for it

[trim eagle]

Brianush1, they’re still in this server (tho they left Managarm)

Source: #678613590646849576 message

[slender wharf]

its genuinely insane that i could realistically run this on my PC with no driver issues

maybe its worth a try

[carmine current]

Driver issues are not that rare :^) mostly with xhci hubs that need more debugging

[trim eagle]

Managarm can now run a minecraft server that other people can connect to!

@brittle mauve made it happen

[native prairie]

Huge

[rare prism]

how well does it perform?

[trim eagle]

according to qwinci quite decent, no keeping up logs or whatever

@brittle mauve perf reports?

[carmine current]

i think f3 shows the mspt (= milliseconds per tick) in newer versions

[brittle mauve]

Ill check that, though I don't think its that much because eg. when breaking stuff the drops appear basically instantly

[carmine current]

nice

[mild jetty]

iirc when connected to a dedicated server that only shows the client side mspt

[brittle mauve]

I didn't see the mspt at least in this version when in the server

[upbeat smelt]

install forge to be able to run /forge tps :^)

[dense umbra]

fuck it host a gtnh server in managarm

[spring oak]

oh yes

[brittle mauve]

ig I can try lol

[brittle mauve]

at least gtnh doesn't really work, Ill try just plain neoforge

[dense umbra]

😭

[spring oak]

what fails on gtnh?

[native prairie]

Damn what are we going to do without gtnh

[carmine current]

could you pull a backtrace of virtio-block here?

that's probably not too hard to debug

ah, I think this is writeback happening after shrinking the file

I guess we should just ignore the writeback for regions that are outside of the file at writeback time

[valid heath]

https://tenor.com/view/managarm-libc-osdev-shilling-porting-gif-11338385317884560538

[median wharf]

we should add a managarm netty backend

[trim eagle]

[vestal sapphire]

testing continues ...

[carmine current]

it's somewhat stupid that os-tests aggregates everything into one score

in particular, that header completeness dwarfs everything else

like, a kernel that uses glibc headers but fails all functional tests would still get 84%

on the functional test side, Managarm is looking quite good though

we're now better or even compared to MacOS in all categories

🔥

[trim eagle]

Managarm is now a dedicated AI OS (yes we run ChatGPT, of course we do)

[native prairie]

Ask it to count the number of asserts in the code

[fast silo]

lmfao

[carmine current]

~/Projects/Ultra$ tokei -t 'C,C Header'
===============================================================================
 Language            Files        Lines         Code     Comments       Blanks
===============================================================================
 C                      33         6005         4506          417         1082
 C Header               66         3187         2289          288          610
===============================================================================
 Total                  99         9192         6795          705         1692
===============================================================================

vs

$ grep -ri 'assert\|ensure' --exclude-dir subprojects managarm/ ports/libasync/ ports/frigg/ ports/bragi/ ports/lewis/ mlibc/ | wc -l
7930

Yes, we do have more asserts than total SLOC in Ultra ;D

[native prairie]

lmao

thats what i call a formally verified os

ive added some asserts myself even

[onyx cloud]

really cool!

[vestal sapphire]

btrfs support coming along ...

[carmine current]

sub second time precision, the future is now

[rare prism]

what other filesystems does managarm support?

[upbeat smelt]

ext2

[rare prism]

ah

[vestal sapphire]

also, with mlibc#1564 we now implement the entire mandatory set of pthread stuff for POSIX 2024

first OS on os-test to do it

[vestal sapphire]

WE BALL

[zinc remnant]

Better than Linux?

[lament grove]

I'd guess so, as Linux is also on os-test

[vestal sapphire]

it's in the screencap ...

[carmine current]

we need to fix 20 tests to surpass freeBSD in overall score :^)

[vestal sapphire]

done

[carmine current]

very nice

a low hanging fruit is probably also fixing/implementing OFD locks

[native prairie]

how legit are those tests? Why does linux have such shitty percentages

[carmine current]

why shitty?

Linux has the highest score

[native prairie]

but it still sucks

why is it not 100

[vestal sapphire]

the distribution is obv biased towards suites with many testcases

but it covers the API surface and namespace pollution of POSIX 2024

[carmine current]

because linux is not 100% posix 2024 compliant

[vestal sapphire]

and some functionality tests

[native prairie]

on purpose or missing some stuff?

[carmine current]

both

[native prairie]

hm

and i thought macos had some sort of a posix certificate

[carmine current]

It does but for an older version of POSIX

[native prairie]

interesting

so sortie wrote this entire 3k test suite?

[carmine current]

some of it is auto generated

like tests for presence of structs or constants

[native prairie]

damn

still sounds like a lot of work

[vestal sapphire]

they target SUSv3 apparently

[native prairie]

thats kinda sus

[vestal sapphire]

the API definitions are extracted by parsing the HTML tarball of the spec

[native prairie]

sorry i had to

[native prairie]

lol

[vestal sapphire]

https://gitlab.com/sortix/os-test/-/blob/main/posix-parse/posix-parse.c?ref_type=heads

it's a small 77 KiB c file, don't worry

[native prairie]

looks like the kind of shit linux does to calculate module version checksum

[vestal sapphire]

honestly I'm considering using it for generating API definitions that we can then use to check against mlibc on CI

[native prairie]

makes sense

[vestal sapphire]

it's surprisingly robust as long as the script for generating the HTML version of the spec doesn't get changed

[forest bear]

Is this mostly managarm work or mlibc?

[carmine current]

both

[vestal sapphire]

MOM GET THE CAMERA

[dense umbra]

[forest bear]

How many fps?

[trim eagle]

decent. Mouse is borked tho, cant look around

[stiff knoll]

[lament grove]

I've heard stuff about syscall cancellation here occasionally, what would you use that for? Processes that get killed?

[vestal sapphire]

so that calls get interrupted

like a read() either returns partial results or EINTR for instance

[lament grove]

Well yeah lol

[vestal sapphire]

when you Ctrl+C interrupt it

[lament grove]

ah

[jaunty charm]

Are signals the only reason syscall cancellation exists?

[carmine current]

yes

[stiff knoll]

are signal implemented using interrupts?

[carmine current]

By interrupts you mean hw interrupts?

Some hw interrupts cause signals, yes

For example, a page fault to unmapped memory

[native prairie]

"software" interrupts

the kernel pushes a fake frame onto the stack

[stiff knoll]

Aight

[native prairie]

and then the user uses sigreturn to go back to where it was signalled

[carmine current]

yeah the concept of signals for userspace programs is more or less the same as the concept of hw interrupts for the kernel

and it comes with the same problems

plus on the user space side, the tools to deal with them are even worse

since lots of C functions cannot be called from signal handlers

including common ones such as printf

imo signals were a mistake except maybe for handling of synchronous faults

and even for synchronous faults, signals are just the solution with least boilerplate, not necessarily the best

it would be better to redirect synchronous faults to a separate process to handle them

[trim eagle]

minecraft epic gameplay on Managarm

[spring oak]

now try gtnh

[rare prism]

This runs way better than I expected it to

[spring oak]

well, they have nvidia drivers

[rare prism]

This is QEMU and I don't think they have hardware acceleration yet, just modeset

[spring oak]

in qemu you can use the nvidia gpu

[rare prism]

If they would be using proper hardware accelerated Nvidia drivers it wouldn't run at 20fps man

[spring oak]

is it 20 fps tho?

[rare prism]

Well maybe 30 but still

[carmine current]

this is with software rendering (= llvmpipe)

[spring oak]

ah

[vestal sapphire]

Only in passthrough which is finicky

Theoretically it is just PCI passthrough, but you need to make sure a few things are correct

It's not as bad as Intel iGPU though, which either needs special driver support or a PCI option ROM override to fix up some things

[full slate]

and you have to turn a bunch of knobs to make it actually fully compliant

[full slate]

how many file locking APIs does managarm support now

you should look at the F_SETCONFINED extension that XNU implements, it's actually pretty cool

it ensures that the underlying file handle (file glob in xnu/bsd parlance, struct file in linux parlance iirc) never escapes to another context - so there's a unique owner pid for the lock

[lament grove]

Does Managarm actually bother to make target triplets like *-unknown-managarm-mlibc or does it just use something else, merely replacing the libc?

[serene portal]

yes

what else did you have in mind?

[lament grove]

Dealing with compilers is a PITA mostly

I'm looking at my best options to get something working without spending a year figuring out how GCC's build system works or some stupid shit

[serene portal]

just steal menix patches

[lament grove]

So I'll probably look into what y'all did here

[serene portal]

[lament grove]

You know what that's probably fair

[serene portal]

managarm doesn't carry gcc patches iirc, it's a fork on GitHub

[trim eagle]

Yep

[carmine current]

And it's upstream in LLVM

But yeah you need a proper triple. That's the easiest part of porting programs (after making it work once I guess)

[serene portal]

oh yeah @lament grove if you want to use llvm, the mlibc environment is already upstream

[rare prism]

plasma?

[trim eagle]

Don’t worry about it

[golden maple]

is this spoiler 🤔

[nocturne tide]

Don't worry about it

[trim eagle]

Don’t worry about it

[limber grail]

when do we get qemu in managarm so we can run managarm in managarm

[golden maple]

https://tenor.com/view/doakes-james-doakes-dexter-dexter-morgan-sus-gif-2943806044988383855

[trim eagle]

Already a thing (tho idk if we tried running Managarm in Managarm recently)

[limber grail]

ah cool

[upbeat smelt]

there was some issue with disk reads in qemu (maybe its fixed now?) but i did boot aarch64 managarm in qemu on x86 managarm and it was running from the initrd fine

i should try booting hurd again :^) since thats where i ran into issues with disk io

[carmine current]

I tried booting the ironclad iso in qemu on Managarm some time ago but it didn't work

as in: qemu didn't load it

[upbeat smelt]

hmm i'm trying it again now out of curiosity

and with the sdl2 window it seems to get stuck before seabios initializes the display or after seabios prints the first line

with -nographic i got

this is trying the latest hurd image again

it's also really really slow, it took a few seconds to print GRUB, then a few seconds until loading appeared

[trim eagle]

Sadge

[true kernel]

doesn't managarm implement kvm

[upbeat smelt]

no

also i'm pretty sure disk io is at fault

[true kernel]

hmm I thought czapek did some work on that

[upbeat smelt]

i'm not sure if it's a bug in the stack or if qemu's access pattern is just particularly bad for us

[trim eagle]

That is indeed true. But it never got finished. @nocturne tide plz fix?

[nocturne tide]

talk is cheap

[trim eagle]

However, braindead over here

[trim eagle]

Only one way to find out. Time to profile that stuff

[golden maple]

btw is kvm is really hard to implement

[trim eagle]

@nocturne tide do you remember what you were stuck on?

I don’t

[true kernel]

I have never tried it

[trim eagle]

Once again, me retarded

So can’t do

[vestal sapphire]

It's just a bunch of ioctls

[carmine current]

iretq had a kvm implementation already and lost it when he reinstalled his host OS

[trim eagle]

It’s lost?

Damn

[carmine current]

That's an understatement though

It also needs page walks and instruction emulation

etc

And non trivial memory management

The memory management is relatively straightforward in Managarm because Managarm has CoW etc abstracted into memory objects that can be mapped into multiple locations already

but for OSes that don't have that abstraction, it's going to be hard

[nocturne tide]

shit not working basically

something in vmx was borked

[carmine current]

I think it was just doing mmio

And we never implemented the page walk in thor

[carmine current]

there is an earlier revision on a branch

not the one that actually got into seabios in qemu though

[trim eagle]

Rip

[nocturne tide]

i think it was doing add [ax], al

lol

i never actually bothered to double check wtf it was doing

but linux does not handle the rmw mmio instructions

[carmine current]

did we handle pio?

[nocturne tide]

i believe so

or, well, we did at some point

but i don't think i can get most of that code back

[carmine current]

if i look at seabios code, the first mmio is probably to xhci

[nocturne tide]

well, i don't think i was even reaching seabios proper

as i said, i think i was executing garbage

[carmine current]

which is the first hw device that it initializes

https://github.com/coreboot/seabios/blob/master/src/hw/usb-xhci.c#L552

fwiw seabios can debug to serial

if that's configured in

which it isn't by default

[vestal sapphire]

It's a repeat is the crypto story lmfao

Poor soul

But also, poor memory on his part

[nocturne tide]

I will punch you until you become unconcious

[serene portal]

so is drm

[vestal sapphire]

it never occursed to me to post this funny screenshot

[stiff knoll]

BROWSER ON MANAGARM!!!

[vestal sapphire]

we've had that for a while

[dense umbra]

https://mathewnd.github.io/mlibc-linux-os-test mlibc-linux hits 95% on os-test!

[carmine current]

23 tests until we surpass musl

[trim eagle]

Imagine the best libc is mlibc. Soon!

[serene portal]

what if we tried convincing void to also support mlibc

[trim eagle]

Maybe after we upstream ourselves into shit like gcc?

[serene portal]

yeah

[dense umbra]

How far are we from that anyways

[golden maple]

someone should make good linux distro on mlibc

[trim eagle]

Mostly time

[dense umbra]

nice

[trim eagle]

In the works and in the cards for 2026

[vestal sapphire]

slowly cooking (dis on linux tho)

[cold loom]

the cookage is real

[fresh hornet]

I wanted to have a look at the magic of btrfs support in mammogram, but I didn't find it in the repository. Am I this dumb unfamiliar with the "modern C++" or it's an undisclosed yet magic?

[native prairie]

@vestal sapphire

[trim eagle]

Pretty sure it’s not upstream yet

[vestal sapphire]

it's WIP on my local branch

I have directory traversal and metadata retrieval wired up, but that's about it

the base primitives are there though

[wind hamlet]

working on it gimme 5 years

[trim eagle]

working on it (see https://github.com/managarm/linux-mlibc)

[wind hamlet]

mine is technically a port of an existing distro so it's not entirely the same thing

i have a huge package repo that is already written (pro) but I need to deal with an upstream (con) and i want package tests to pass (slower but a pro imo)

[vestal sapphire]

https://managarm.org/2026/01/13/end-of-year-update.html

[cold loom]

kilogram

[icy verge]

kilogarm

[vestal sapphire]

meson just works™ 🎉

[native prairie]

Nice

[lament grove]

yoooooo

One step closer to fully self-hosting?

[carmine current]

true

i guess it depends on what you consider self hosting

imo being able to develop Managarm's kernel + drivers on Managarm itself would be pretty neat

and is within reach

building all ports is more difficult

[trim eagle]

Mlibc is probably already possible now

Clang hasn’t been build yet but I tested it years back so should work

[carmine current]

For Managarm itself, the most annoying part is just fixing our Meson build system to work outside of xbstrap

since rn we rely on some symlinks that we create before running meson

Leo fixed a lot of that already though

[cold loom]

peak lunix

[storm plover]

ts so linux

[rare prism]

real gaming

[trim eagle]

Meanwhile, slowly we’re working on a proper mlibc based Linux distro, which can also serve as a testbed to rule out libc issues. This is based on work that is years old and back then sysvinit was way easier than systemd. And tbh it still is. But in systemd 259 they added experimental support for musl, and building on that support, the actual patchset adding mlibc is surprisingly small

https://github.com/managarm/linux-mlibc/blob/master/patches/systemd/0001-Add-mlibc-support.patch

(There’s a second patch with like 3 hacks that need proper solving either in mlibc or systemd)

so maybe one day systemd compilation comes to a mlibc near you for free (Linux option required, I said nothing about it working )

[carmine current]

I feel specifically called out

[golden maple]

alphamanagarm

[cold loom]

openai

[quaint fern]

That's numberwang

[quaint fern]

Why Lewis btw? Because of the Norse heritage of the western isles?

[carmine current]

No, lewis was picked by @reef steeple , I don't know why (probably vibes?)

[reef steeple]

made sense mentally

lewis is spiritually called lewis

[forest bear]

What is lewis

[quaint fern]

https://en.wikipedia.org/wiki/Isle_of_Lewis

[forest bear]

No yeah I know but in managarm speak

[lament grove]

Where do you draw the line at drivers that are in vs. out of the kernel? Presumably stuff like CPU-local timer and interrupt controller drivers would be in the kernel here?

That begs the question of DTB and/or ACPI table parsing: I suppose part happens in the kernel and another part happens in the init server?

[forest bear]

yes

[forest bear]

depends

you have some enumeration in the kernel

and complete enumeration in userspace

[lament grove]

I see, thank you.

[upbeat smelt]

acpi and dtb nodes are parsed and exposed over mbus, then userspace drivers can find them to implement drivers

e.g. the bcmgenet driver looks for mbus objects with a ⁨dt-compatible=brcm,bcmgenet-v5⁩ property

likewise for pci, we have it in the kernel and it's also used to populate mbus (as well as applying some quirks before userspace drivers are reached)

for quirks, consider ehci/xhci port muxing on intel chipsets, we want to do it before either driver is started to avoid problems

[rich glade]

worth reading 100%, wish yall best of luck continuing improving managarm.

[forest bear]

I think doing it all in the kernel is a bit heretic

You have to include uacpi in the kernel and stuff

Which is a no-no to me

[carmine current]

It's definitely possible to move acpi to userspace but it's non trivial and introduces other isolation issues

[upbeat smelt]

we're just being pragmatic that's all

[carmine current]

If you put acpi into userspace you need some "access arbitrary physcial range" capability/syscall

which Managarm doesn't have

[carmine current]

And also you need to relay some data from userspace to kernel space that the kernel has to trust

The main advantage of doing it in userspace is that bugs in your aml interpreter are more contained

[forest bear]

What I had in mind involved giving access to the entire non-kernel physical memory to init and it carves it up and gives it to its children

I'm not sure about the relaying from userspace either, like what?

[carmine current]

Like values that need to be written to the reset registers etc

And probably device related stuff

You obviously also need to trust userspace to run the control methods correctly

Otherwise you cannot suspend/resume/poweroff etc

[native prairie]

userspace real mode resume code is funny for sure

[carmine current]

But yes, it's definitely doable and many (most?) microkernels do acpi in userspace

I think the extra trust that you gain is more about bugs in the aml interpreter, not issues in the aml itself etc

[mild jetty]

well yeah issues/attacks in the aml itself don't go away if you interpret it in the kernel

[native prairie]

daamn

[vestal sapphire]

we ball

[trim eagle]

Modeset no artifacts. Fuck yeah

Now do 3D accel and show the gears

[dense umbra]

vkcube

[rare prism]

just how old is that webkitgtk screenshot

[trim eagle]

About 14 hours and 15 minutes?

[icy verge]

I think he means the one on the website itself

[trim eagle]

God knows lmao

[nocturne tide]

gnome 3 is a bit old

that probably gives you a good estimate

[cold loom]

the first release of gnome 3 came out in 2011 i think

[carmine current]

We fixed EHCI on real hw and it even works with USB 2 hubs (and USB 2 devices on the hub)

[vestal sapphire]

(as long as you keep the logs enabled)

[vestal sapphire]

btrfs file reading works

[serene portal]

[quaint fern]

remarkable

[vestal sapphire]

https://github.com/managarm/managarm/pull/1241

this is a bare minimum impl tho, it literally only supports the simplest of cases

[carmine current]

that's really cool

[vestal sapphire]

ah shit this depends on the async generator stuff I wrote

[carmine current]

time for some automated race condition debugging with many-boots.py

[vestal sapphire]

ok I improved the btree traversal to traverse internal nodes

(I basically put the entire managarm source onto a btrfs image so that I get a larger one)

[native prairie]

very nice

[vestal sapphire]

caching a bunch of stuff makes it performant

[vestal sapphire]

fwiw implementing support for zstd-compressed blocks was ezpz

[rich glade]

What are yalls future goals, what is the next thing you're gonna implement

[carmine current]

Perf, stability and driver compat improvements such that Managarm can be used as a daily driver

is one of them

[rich glade]

ohh yea driver support is good to have

[rich glade]

Do yall have ported any webbrowser to it?

[vestal sapphire]

we have webkit

[upbeat smelt]

booting off of an usb stick plugged into an usb hub connected to xhci

[native prairie]

big

[upbeat smelt]

i also tested an usb 2 hub i have (the black one in the photo is an usb 1 hub), and with it usb 1 devices work, but usb 2 devices don't (and for some reason it's trying to do split transactions?)

which is obv wrong

also cc @knotty lotus a bit over a year ago you asked whether we had any ideas why usb fs/hs devices behind hubs would fail with an usb transaction error on the address device command, i found at least 2 bugs in the managarm xhci driver that caused this:

1. root port number was not determined correctly for devices behind hubs
2. we were setting the parent hub slot and parent port number for all low/full speed device behind a hub, even if the hub was not high speed, which confused the controller and caused no traffic to be sent to the device (checked with a usb protocol analyzer) and the address device command to fail

[knotty lotus]

Thank you so much, my system too still has the bug. perfect.

[upbeat smelt]

still need to figure out why hs device behind hs hub is borked, but there it seems to be some other misconfiguration that causes it to try and perform split transactions

i have a draft pr with the fixes: https://github.com/managarm/managarm/pull/1242

[upbeat smelt]

the hub code is reporting that the hs device is actually usb fs

ah, we are trying to get the device speed too soon

immediately after setting PORT_RESET but before the port has PORT_ENABLE set

[upbeat smelt]

yeah if i wait until the port is enabled before getting the speed it actually works

now also working with usb 2 devices behind usb 2 hubs :^)

hmm usb 1 hub -> usb 2 hub -> xhci doesn't work (fails on address device so likely something with the slot context still)

usb 2 hub -> usb 1 hub -> root port (so essentially usb 1 hub -> usb 1 hub -> root port) works though

[coarse rune]

im more curious to how you got a costa branded USB stick

[carmine current]

with this PR (+ a DMA allocator change that we still have to do), xhci now works correctly on the raspi4

[lament grove]

Managarm doesn't happen to have any image-editing software ported, does it?

[trim eagle]

Not yet

But if requested that can be arranged

[lament grove]

It would be nice. That's one the the criteria Jenny uses for the daily drivers review series.

[trim eagle]

Gimp good enough?

[lament grove]

yes

She uses that normally in fact

[trim eagle]

Hefty dependency stack

But nothing I can’t solve

I can’t start on it directly as I’m working on init system upgrades (so I can’t boot now which means no gimp testing )

And I presume a custom image with gimp and friends pre installed would be requested?

[lament grove]

yeah that would be nice

[trim eagle]

I’ll make something happen and preload it with all kinds of goodies

[lament grove]

Very cool thanks

[trim eagle]

I plan to have init work done this week / weekend so hopefully I’ll have something ready this weekend

[golden maple]

is mlibc linux dead

[carmine current]

no?

[serene portal]

it's not dead but stale iirc

[carmine current]

No dennis updated it a couple weeks ago

[trim eagle]

I’m working on the init system but mlibc changes for that break Managarm. So tangent acquired and now debugging that

I hope to have that finished this weekend, then I can finish the next tangent (funny image) or continue work on mlibc-Linux

[lament grove]

infinite tangents

[trim eagle]

Always infinite tangents. Unfortunately no fucking time lmao. Today I wanted to do more systemd debugging but I did overtime at work and am still traveling home. I already know I’ll do fuck all today

[vestal sapphire]

how cancerous can aio really be

[trim eagle]

Meanwhile, progress on mlibc Linux has resumed with the systemd on Managarm sidequest resolved. Several more ports were enabled and the Linux support in Mlibc was improved by implementing more sysdeps for Linux. While systemd itself is still being debugged on Linux, I have good hope that that will be done soon. My next priorities on this project is getting a proper boot to a console of sorts up and running and getting the image generation upstreamed for it. Eventually after that the plan is to add it to our builder fleet and get an actual distro for it up and running

[forest bear]

the chroot works, but is there any way to run gui apps from it? Like if I ran glxgears from the chroot would it show up on my system?

[trim eagle]

No(t without extra work / hacks / investigating if that’s possible at all)

[forest bear]

I'm interested in profiling mlibc glxgears against glibc because fishix' is much faster than astral

[trim eagle]

Im working on image generation and boot bringup exactly so we can do stuff like that

[forest bear]

ok nice

is there some kind of mlibc gcc for linux? (outside of the distro)

like there's musl toolchains available

[trim eagle]

Pass the correct toolchain values to configure and ball. Alternatively, once mlibc-Linux is on xbbs and assuming you run with cbuildrt one can download-tool-archive it

[trim eagle]

Euhhh not pre compiled I think

[forest bear]

I dont mind compiling it, are there available scripts to do it?

[trim eagle]

Essentially one can copy the steps from mlibc-Linux and script it

But no premade script that I’m aware of (as I just invoke xbstrap obviously)

[forest bear]

mhm ok I see

I suppose I can probably just use my own gcc and override the libc.so with mlibc's too

[trim eagle]

Also you should coordinate with @dense umbra as he has plans to profile mlibc too

[forest bear]

I'm mostly just curious as to why glibc is getting like 10x the fps

[trim eagle]

Probably. I know we do memes with patchelf on Managarm to just change out the Managarm version of mlibc to the Linux version of mlibc to please GOI

[trim eagle]

So are we all

[forest bear]

it's more than likely a mesa thing

well no

it's 100% a mesa thing

[dense umbra]

its more like 2x-3x, just that my computer sucks (on iretq's machine we got like 2.3k fps)

[forest bear]

maybe if you ran my thing instead you'd get more FPS

(unironically you probably would)

[dense umbra]

talk is cheap fix build

[forest bear]

(it doesnt compile tho)

[dense umbra]

[forest bear]

the only issue is gettimeofday?

ill fix that real quick

I'm actually curious, because on my system I do beat mesa

I'm not even sure how to fix it in a portable manner actually

[median wharf]

there used to be

not sure what happened to it

[carmine current]

one thing that i know for sure is a perf problem is that qsort() is garbage quality

since it uses a O(n^2) bubble sort or something like that

aside from that, i don't know of any obviously bad algorithms in mlibc

[carmine current]

it should probably use a quick sort with fallback to mergesort if the quick sort takes more than K * log(n) rounds or something like that for some constant K

[worn rampart]

qsort
Looks inside
Bubble sort

[trim eagle]

Progress report: after fixing some final issues preventing boot (logind wants dbus, I knew that trust me ) and enabling shadow, we are now at a point where one can make an image and boot it, and it’ll boot into agetty. Work is ongoing on being able to fetch files from the internet, but systemd-networkd and systemd-resolved are not happy with me yet. We’re also missing / not yet enabling pretty common items like kmod, procps and psmisc. This too will be worked on with time. I hope to have this on xbbs soon so one can just pull-pack the packages and, time permitting, finish up image generation and exportation on ci so you can literally download a base image. Xbps enablement is planned after network is up and running

[carmine current]

I've been lately working on some kernel improvements and we have no removed per-address-space locking from all code paths except for mapping, unmapping and changing mapping protections

So page faults or operations such as reading/writing remote address spaces do not take per-address-space locks anymore

[carmine current]

And all of these operations can now run in parallel as long as they do not need to revoke page permissions (which requires shootdown)

[blissful bluff]

Are you using locks in individual pages instead?

Because it sounds very complicated

[carmine current]

No, we're not using any traditional locks on these code paths anymore

unless you hit a code path that needs shootdown, then it needs to wait for prior PT changes to complete

[blissful bluff]

How do you do shootdowns then? Or handle cases, where you make page invalid, and then change it, without it producing a segfault in a different thread

[carmine current]

When we do hit shootdown code paths, we wait for all prior PT modifications that revoked page permissions (= that either unmapped a page or reduced its perms) to become visible on all cores

[blissful bluff]

Or stuff like two threads immediately accessing the same address when doing CoW

[carmine current]

There can still be locks taken when a physical page is not available (when it needs to be read from disk etc)

but they do not lock the address space

[blissful bluff]

Ok, very cool in any case

[carmine current]

If the physical page is already available, this will just cause both threads to change the PT at the same time

one thread will think that the page fault was spurious

the other thread will think that there was no page mapped before

[blissful bluff]

But that would mean that both threads would allocate a new page, what if one of it fails, but the page was already installed by the second one?

[carmine current]

No, as I said, if the physical page is not available, there are still locks (at a smaller scope than the address space though)

[blissful bluff]

Ok

[carmine current]

But the advantages are still big:

• Page faults are no longer blocked by mmap()/munmap()/mprotect() and can run concurrently with mmap()/munmap()/mprotect()
• Page faults by different threads can run in parallel and are starvation free on the fast path

[blissful bluff]

Yeah, of course

[native prairie]

dont page faults need to lookup the address space object corresponding to the fault?

how do u do that without a lock

[carmine current]

what's an "address space object"?

[native prairie]

e.g. vm_area in linux

or is that microkernel memes

that u dont handle that in kernel at all

[blissful bluff]

I think this is how everyone usually handles it?

[native prairie]

either way u need to tell whether to send sigsegv or not

so how do u decide without locking the address space?

[carmine current]

Ah, we do still use a spinlock for that but we could make it lock free in the future

by using RCU

[native prairie]

so your statement was wrong then

[blissful bluff]

But it's not a lock on page tables?

[carmine current]

That's an implementation detail of the tree data structure though

[native prairie]

there's a separate page table & address space management lock?

[carmine current]

There is no page table lock

[native prairie]

what was the lock taken before this patch?

[carmine current]

A lock that ensured that mappings couldn't change

[native prairie]

like per-mapping lock?

[carmine current]

• a per mapping lock to synchronize unmapping and mapping of pages

the latter is completely gone

the former is only used during mmap/munmap/mprotect now

[native prairie]

but yeah you could use an rcu i guess, like linux maple trees are designed to be rcu safe so its probably a lockless path for them

so it's just preempt_disable/preempt_enable

[carmine current]

the Linux code has a lot more locking as far as i'm aware (unless something changed recently)

the linux code has a per-vma rwlock

[native prairie]

https://elixir.bootlin.com/linux/v6.19.7/source/mm/mmap_lock.c#L245

the vma is looked up without locks

[carmine current]

that function locks the vma

that's the point, right?

Lookup and lock a VMA under RCU protection.

[native prairie]

yeah it takes a readlock, but the lookup procedure itself is lockless, if you have all cpus page faulting at the same time none of them will block since its a rw lock taken on read

whereas in mangarm they would all block here

[carmine current]

and this is taken in each pf: https://elixir.bootlin.com/linux/v6.19.7/source/arch/x86/mm/fault.c#L1325

[native prairie]

yeah like i said its a read lock right

[carmine current]

and worse, if it fails, the pf locks the entire address space

[carmine current]

No

[native prairie]

i mean yeah makes sense, if it fails the page fault was likely on an invalid address

[native prairie]

#1091278035686268928 message

[carmine current]

That spinlock is an impl detail of the tree

[native prairie]

lol

[carmine current]

It's not taken across the pf

[native prairie]

does it make it magically non block then?

wdym by across

[carmine current]

It's literally only taken for tree lookup

[native prairie]

you mean its released once the lookup is done?

[carmine current]

yes

[native prairie]

yea

[carmine current]

Whereas on Linux, the VMA is locked after lookup is done

[native prairie]

where did u see it lock the entire address space btw?

[carmine current]

https://elixir.bootlin.com/linux/v6.19.7/source/arch/x86/mm/fault.c#L1357

[native prairie]

i wonder why thats even needed

[carmine current]

So on linux, a concurrent mmap() will stop all page faults

whereas on Managarm this won't happen

[native prairie]

right

i dont understand why they retry if it wasnt found first try

maybe its for threads spamming mmap/munmap

gently touch the lock

[carmine current]

apparently on Linux, the VMA start/end can change at runtime (?)

If I understand the code correctly

[native prairie]

maybe via sbrk or something?

[carmine current]

also, afaict this will happen even if it doesn't take the full mmap lock code pth

[native prairie]

yeah

[native prairie]

you mean doesnt?

[carmine current]

yeah

[native prairie]

why

[carmine current]

https://elixir.bootlin.com/linux/v6.19.7/source/include/linux/mmap_lock.h#L203

[native prairie]

as far as i can see its used on free paths

or i mean

if mmap touches the vma which is faulted on then yes

[carmine current]

yeah

[native prairie]

thats not the case on managarm?

[carmine current]

nope

[native prairie]

how did u achieve that?

[carmine current]

^

[native prairie]

PT or address space?

Like i see this is talking about tlb shootdowns but not software operations

like splitting a vma etc

[carmine current]

splitting a VMA can run concurrently with page faults

[native prairie]

how does it resolve a race where e.g. a core is doing munmap in the middle of a vma which is faulted on at the same time?

[carmine current]

If the VMA is already marked as in-progress-of-being-unmapped before the PF starts, the PF will re-check the mapping tree and either take the new mapping that replaced the old one or cause a segfault

If the page fault does not see the in-progress-of-being-unmapped state at the time of check, the page fault will go through

but munmap will wait for all prior PT modifications to finish

[native prairie]

hmm

[carmine current]

so munmap will remove the page again

[native prairie]

how does it know there are outstanding modifications

[carmine current]

it has per-mapping RCU domains

[native prairie]

hmm

by mapping u mean a vma?

[carmine current]

yeah

[native prairie]

ah interesting

how does managarm implement rcu

does it wait for all cpus to be preempted once?

[carmine current]

It has two implementations. For this address space protection case it does something that requires atomics on the reader side

[native prairie]

so its some sort of adhoc special rcu?

[carmine current]

It's a variant that requires no registration

[native prairie]

wdym by registration?

[carmine current]

of threads/CPUs

[native prairie]

hm

[carmine current]

It achieves that by counting how many readers are in a grace period

which is ofc more costly than the preemption based RCU (which we also have) but not more costly than a rwlock

[native prairie]

ohh

so who does the notification or like whats the point at which it realizes there are no more readers left

[carmine current]

But compared to preemption based RCU, the advantage is that the grace period is not extended until CPUs/threads have reacted that are not even in a RCU client side

[native prairie]

or is it polling based?

[carmine current]

the barrier advances the grace period and then waits until the previous period's read count hits zero

the last reader unblocks the barrier

[native prairie]

aka spins in a loop?

i just need to read the code ig

[carmine current]

guard: https://github.com/managarm/managarm/blob/master/kernel/thor/generic/thor-internal/rcu.hpp#L31 barrier: https://github.com/managarm/managarm/blob/master/kernel/thor/generic/rcu.cpp#L119-145

[native prairie]

ah ok so the last reader to exit raises an event

[blissful bluff]

57 bits paging has to be enabled explicitly

[forest bear]

Isn't that a bit more similar to EBR rather than RCU?

[carmine current]

the names are used mostly interchangeably in the literature

that's why i called it RCU

[native prairie]

isnt it just a way to implement an rcu

also isnt it how userspace rcus work

[forest bear]

Both are ways to implement SMR

Safe memory reclamation

Which is also the name of the freebsd thing (also named GUS)

confusing I know

[native prairie]

what the hell is gus

the guy from breaking bad?

[forest bear]

GUS is very nice, maybe even better than RCU

[forest bear]

Global unbounded sequences

[native prairie]

☠️

[forest bear]

It has been benchmarked to perform better in some cases afaik

And XNU also uses a variant of it

[native prairie]

whats the diff exactly

[forest bear]

It's a bit atypical because it relies on allocator integration

[forest bear]

You use sequence numbers instead of waiting for a grace period

basically

I'm not super informed about it, I've only started going through it recently

[native prairie]

ah

[forest bear]

But it results in having less outstanding to-be-freed memory

I'm not sure it can do arbitrary calls though, it's mostly a memory reclamation thing

[carmine current]

SMR is also kinda misleading since we're not using it for memory reclamation here

[forest bear]

Which is fine, since most times you use RCU for SMR anyway, but RCU can also do generic stuff

[forest bear]

Have you looked into GUS?

[carmine current]

Yes but I'd have to refresh my memory to say something qualified about it

[forest bear]

I'm not sure whether I want to implement it, since RCU can do generic operations while GUS only works on memory afaik

I suppose I could have both

[carmine current]

Okay, I re-read the FreeBSD header

I think you can actually have a generic barrier with its GUS as well but you need to poll

[forest bear]

Yeah you're right they have generic smr functions

https://man.freebsd.org/cgi/man.cgi?query=smr&sektion=9&manpath=FreeBSD+14.2-STABLE

[carmine current]

fwiw the Managarm preemption-protected RCU is very simple. It's ~100 lines including comments that explain its correctness

but it builds on pre-existing abstractions

        transitionWg_.add(getCpuCount());
        for (size_t c = 0; c < getCpuCount(); ++c) {
            auto cpu = &cpuData.getFor(c);
            // TODO: We can do this without allocation by putting the operations into a member vector.
            spawnOnWorkQueue(
                Allocator{},
                cpu->generalWorkQueue,
                async::invocable([this] {
                    // Perform an explicit fence here since WorkQueue::schedule() may not be strong enough
                    // (e.g., when scheduling to the current thread's WQ).
                    // It may be possible to weaken the barrier here by specifying
                    // the guarantees that WorkQueue::schedule() should provide.
                    std::atomic_thread_fence(std::memory_order_seq_cst);
                    transitionWg_.done();
                })
            );
        }
        co_await transitionWg_.wait();

this is the main part of the barrier

[forest bear]

The main draw of GUS is faster memory reclamation

[carmine current]

transitionWq_ is a wait group, in this case essentially used as a semaphore

[forest bear]

(and simplicity of implementation)

[carmine current]

^ this schedules a memory barrier on all CPUs and waits for all of them to complete

because work queues only run in contexts where preemption is enabled, this is all that is needed

[forest bear]

Do you send an IPI or is there a periodic worker thread on every cpu

[carmine current]

the work queue is essentially a thread

so waking it up just uses the normal scheduler mechanisms

which will usually involve an IPI for remote CPUs, yes

[forest bear]

Yeah but it's not this explicit IPI thing where you send work to other CPUs instantly

It's a thread

[carmine current]

that doesn't matter for correctness

just for latency

[forest bear]

Yeah I know

I was wondering

I've been thinking about cross core call mechanisms like that

They're nice for lock free stuff too

[carmine current]

also, you want to run in thread-like context because you want the read side critical section to just disable preemption and not IRQs

you could alternatively integrate this explicitly into the scheduler but that's probably more ugly

If barrier latency becomes a problem, we could just give the work queue a higher priority such that it will be switched to immediately

or yeah, ig the alternative is letting an IPI set a flag that is checked whenever preemption is re-enabled

[forest bear]

Maybe enqueue a DPC?

[remote jay]

Are such techniques necessary to avoid the cost of barriers in a standard implementation of a reader-writer lock?

[carmine current]

RCU / GUS / etc. is not a replacement for rwlocks

[remote jay]

Ah, I see. I was under the impression they were meant to be a more efficient alternative.

[forest bear]

their use cases overlap quite a bit though

[carmine current]

well, they don't provide any exclusion (but rwlocks do)

you can replace an rwlock by RCU only if you could also replace the rwlock by an empty write side

reader:                         writer:
rwlock.shared_lock()            rwlock.lock()
// do stuff                     rwlock.unlock() // nothing between lock and unlock
rwlock.shared_unlock()

^ this pattern can sometimes be replaced by RCU

(and RCU is still weaker than this because it only waits for past readers while the empty lock()/unlock() also serializes against future readers)

The correct way to think about RCU is as a replacement for stronger barriers, not as a replacement for rwlocks

but a lot of RCU related material on the internet gets that "wrong" as well

[quaint fern]

the analogies made rarely seem to be very edifying

by analogy to a kind of barrier seems by far the most useful one

[lavish pasture]

when I was implementing a variation of SMR, it was thought that a big problem with QSBR was that it's virtually impossible to control the size of deferred reclamations

given that on our arches, where non-contended atomics are very cheap EBR techniques are cost effective

they provide an explicit observable state for being in a critical section which in turn names who is in your way

EBR has the performance of a fully uncontended lock if you write it smartly

I understand why RCU is used on large machines, and yes, RCU can make it faster locally, but this requires a very high quality implementation of RCU

and even then, you’ll still have to bear the costs associated with unbounded peak memory use

[lavish pasture]

FreeBSD's thing is even better because of it's coupled into their allocator's caching layer

It uses the allocator data structures for deferral

which is also a cost that you need to account for in the grand scheme of things

RCU as it’s implemented and tends to be used is very slow to detect grace periods

may sound like an advantage, but while you can’t recycle memory you need to use more and for paths that churn allocations

[carmine current]

FreeBSDs implementation is even worse than Linux in terms of barrier latency, isn't it? Since you need to scan seq numbers of remote CPUs to detect a grace period. AFAIU Linux uses explicit scheduling to force a QS on all CPUs

[lavish pasture]

btw that’s not the barriers that I don’t like about rwlocks, it’s the contended atomic to count readers which doesn’t scale past a couple cores

CPUs can speculate through barriers and are a local concept

[sullen tendon]

i know that with rcu synchronize() can cause threads to wait a long and like never run

i understand it that with freebsds thing its very different?

[lavish pasture]

I don’t understand you

on XNU synchronize still sucks but is at worst as slow as taking Ncpus spinlocks

atomics and memory barriers are still needed (the atomics are very fast and don’t matter here)

but to me SMR is about scalability first

single core performance second

and when you replace something that used to have a lock you’d have atomics and barriers anyway

[forest bear]

they avoid extensive polling via their allocator integration

how it works is they have a global bucket list, and when they notice they can reclaim it they can have one poll for like 256 pointers which is good

what's nice about this too is that it amortizes under load because the bucket sizes change dynamically

[forest bear]

if they didnt do this you'd have to do smr calls on every pointer

and that would be much slower than RCU, yes

[sullen tendon]

were you looking into freebsd's implementation or xnu's?

[forest bear]

freebsd

[sullen tendon]

with rcu a critical section cant make progress happen

?

since as i understand the observed quescent state is independent of the critical section

and a thread can sit inside a read side critical section forever

is this the problem?

[remote jay]

Wouldn’t an infinite loop in a critical section be considered a bug?

[trim eagle]

Linux-mlibc is now on xbbs. We’re still having some ci build issues it seems which I’m chalking up to stuff out of date and not marked as broken and gnu being gnu

[carmine current]

Managarm now scans access bits and makes an effort to keep the working set of a process at a certain threshold

And there is an open PR to make the LRU mechanism use generations

which makes reclaim much faster

[quaint fern]

very nice, i see you do it the more favourable way too (iterate through PTEs)

keep us posted on any further developments

it's a fun and interesting problem space, figuring out good ways to determine a target resident set size, how often and how much to age a vm map, these sorts of questions

[trim eagle]

And we’re green! Nap time now but tomorrow I’ll try to speedrun some graphical environment

[dense umbra]

kde plasma real?

[trim eagle]

Probably Weston first but that’s not really a detour

And I gotta speedrun xbps first

And I might need to speedrun the goi infra. But maybe I’ll skip gnome for now

Idk

[carmine current]

I think if I write an RCU capable btree, I can get rid of all the IRQ disables on the page fault hotpath

[forest bear]

are you becoming addicted to RCU

[carmine current]

no, i'm just thinking about how to make pfs faster

page faults are the most common kernel entry

at least for workloads that spawn a lot of processes

[forest bear]

that's what they all say...

[nocturne tide]

just one more rcu data structure bro

[carmine current]

tbf rn we only have two (radix tree + list) so it's not that bad yet

[bold knot]

Have you studied the linux "maple tree"?

[carmine current]

I looked at it briefly but iirc it is just an rcu capable btree that they gave a different name because it's linux :^)

The strategy of doing tree modifications by copying a node and publishing the copy is not exactly a linux invention

maybe they were the first ones who integrated it with RCU but there were functional implementations that worked like this way earlier

[quaint fern]

filesystems have been doing it for some time sometimes with what are effectively garbage collectors to clean up old nodes

[lavish pasture]

but a thread being preempted for a very long time is not

[trim eagle]

Not something we haven’t shown here before, but I went on a speedrun and Linux-mlibc went from terminal only to running (exactly one) KDE app (as I haven’t ported more yet )

[trim eagle]

The plan is to yolo into KDE Plasma as soon as we can and actually get this daily drivable. With luck (and that depends fully on work, transportation back home, energy and motivation levels after said workday) we get to KWin (the compositor) today

[golden maple]

when managarm age verification

[nocturne tide]

low effort rage bait

didnt even spell managram correctly

[trim eagle]

whenever I enable systemd-userdbd (so fucking never, over my dead body lmao)

[trim eagle]

Another porting spree later and we do have KWin compiling now. Testing nested under Weston is annoying as Weston doesn’t seem to implement everything that KWin wants and KWin standalone sounded like effort at 1:30am lol. Time permitting and some xbbs build bugs fixed, this weekend or early next week hopefully gets us plasma-workspace at which point I can just launch systemd units (or I modify the weston service file to invoke KWin for testing purposes, that’s probably easier to do from the laptop in an evening)

[worn rampart]

Port gnome, It runs under FreeBSD so how hard could it be :^)

[trim eagle]

Well this is Linux with mlibc

So not hard

But GNOME for managarm is also planned

Tho GOI cross compile is pain, and gjs needs spidermonkey and rust

[carmine current]

GOI is solved though, isn't it?

[trim eagle]

Seems solved yes. But I’m always on the lookout for another curveball by GNOME

[golden maple]

what is goi

[nocturne tide]

gobject introspection

[golden maple]

a

i remember that i had a lot of pain with it when i forgot to disable it

[vestal sapphire]

ok so for implementing POSIX aio on linux, I only need to handle three more cases:

• cancellation of requests with sigev != SIGEV_NONE
• suspend on requests that might be on different io_urings
• list_io of with sigev != SIGEV_NONE

I think the rest of the abstractions is pretty nice already, it's just that this plumbing is a bit annoying because I run one io_uring queue per thread + one for the lazily-spawned observer thread that handles sigev != SIGEV_NONE

I wonder if it would be better to use a single (mutex-protected?) io_uring for regular submissions instead of the per-thread model

as handling completions across threads becomes friggin annoying

[serene portal]

gnome doesn't run under FreeBSD anymore

[carmine current]

The annoying part is that you cannot cross compile goi

It needs to run code on the target system during build

[nocturne tide]

you can*

that's the caveat, you need a way to run binaries built for the target system :^)

[true kernel]

then how does managarm do it?

does it just build goi on aarch64/riscv64?

[nocturne tide]

i came up with a kind of a nasty hack

basically, we build mlibc for the host

and patchelf the binaries to use the host interpreter + ld_library_path so it can find libc.so and friends built for host

and that's about it

and for architectures other than x86_64 iirc goi is just disabled

[carmine current]

yeah we effectively run Managarm binaries on linux by swapping the libc

[nocturne tide]

despite being one big hack i think it's quite a nice solution

[carmine current]

Yeah it's not too bad

[golden maple]

why is goi even exists

[carmine current]

It does reflection for C code

:^)

[native prairie]

is it possible to just boot whatever it needs in a vm and get the output?

[nocturne tide]

probably, but imagine doing that during build

[vestal sapphire]

I mean doing the mlibc swapping in qemu-user doesn't sound too bad I think?

except for needing al the dependencies

[nocturne tide]

barely an issue

you already have them

in the sysroot

[carmine current]

In qemu-user, yes

In qemu-system: no

Because it needs to access the host file system etc

[vestal sapphire]

re this, ig we could be a bit funny here:
what if we delegate all io_uring work to the worker thread; we can handle all notification type there. for awaiting requests (aio_suspend), we could just futex_waitv on the int status field? seems like a good architecture

that means we have to use acquire/release on that field tho, but that's what I did before anyway for correct behavior when writing returns/errors anyway, and it's lockless in the hot path

[vestal sapphire]

hell yeah, it seems to work now

I think I have all the pain points solved

[vestal sapphire]

the aio PR gets us pretty close https://github.com/managarm/mlibc/pull/1729

[native prairie]

damn good job

[trim eagle]

KDE on mlibc-linux!

[native prairie]

All that remains is KDE on mlibc-managarm

[trim eagle]

[limber grail]

Mlibc/Linux 🔥

[molten meteor]

wait, why is the window's title Qemu managarm

[trim eagle]

I lifted the qemu run script from Managarm. I forgot to change it

[molten meteor]

aah

[sonic scarab]

I'm jealous. I've still got a lot of work to do before I can run a GUI under the Linux personality on Telix.

[native prairie]

This is literally Linux

[sonic scarab]

Perhaps I overestimated what I was looking at.

[cinder trench]

they were running kde atop their custom libc implementation (mlibc) on linux

mlibc is originally written for managarm (now runs on others), which is a hobby os and is also capable of running some window systems originally for linux

[vestal sapphire]

mlibc is not written for managarm, it's a libc that supports multiple operating systems, one of which is managarm (it was the first though)

it just has a sysdep layer for each OS

[cinder trench]

doesnt the m stand for managarm

[vestal sapphire]

officially it doesn't stand for anything

in the very early beginnings, it might have

might as well just mean megachad libc at this point

[carmine current]

Running it on Managarm is probably not much more difficult than running it on linux-mlibc though

[vestal sapphire]

the types of issues I'd expect (if any) would be either missing DRM features or differences in poll behavior for some fd types

[trim eagle]

Yeah DRM is the most likely issue if we run into issues

[native prairie]

when test

[trim eagle]

Soon

[carmine current]

we do have sddm already even though it's not merged

and various qt apps

so it's not unlikely that kwin just works with minor fixes

[sonic scarab]

I'm trying to do binary compatibility so that I can give Telix a stock Linux distro disc image & run Xwayland + GNOME + Firefox on Telix off it, which might be a slightly different goal.

[trim eagle]

My end goal is to do that. But not with binary compatibility (and I’ll allow a substitution on GNOME and Firefox with KDE and chromium respectively)

[trim eagle]

Yeah I think it’s time that I clean that up next week and then let SDDM be the default (it’ll boot to Weston after login, as there’s no other session available)

OTOH, that does pull in Qt6 into the nightly

Which then raises the question if it’s time for a minimal nightly and a proper nightly

Where the minimal nightly is the one we use for test-image and is just Weston, and the proper nightly would have a DE (once we have it) and probably a browser too

[carmine current]

Yeah we're not doing binary compat

[carmine current]

I think we could just add a meta package for that that ppl can install via xbps

[trim eagle]

That’ll boot into Weston as root by default then tho. Yes I know we’re missing stuff on the security side but that’s a major issue later down the line lol. And I’m sure that we’ll include Qt by default one day, but then the nightly really turns into a live image with installer

[carmine current]

It already has an installer, it's called xbps-install -r

Can't we make it such that kde takes priority over weston when it is installed?

We can have sddm in the nighty image

[trim eagle]

That pulls in Qt

[trim eagle]

With SDDM? I think so

[carmine current]

Is qt that big?

We should stop running everything as root anyway

And at that point we'll need a greeter

Ig we'll also need logind support in Weston for that to work (?)

[trim eagle]

Nah Weston as !root works. I don’t think Weston cares about logind? But I’ll check

[trim eagle]

Yes

[trim eagle]

Yes

[carmine current]

Ah i thought that it might need logind to access drm devices as non root

[trim eagle]

We build with debug sooooo. Maybe split debug to the rescue and release mode is a thing

[trim eagle]

Oh probably. But what are permission checks in the kernel

Or posix-subsystem rather

[carmine current]

Yeah we should build as debugoptimized and do split debug

[trim eagle]

Yeah

Things to tackle once more important issues are done

I want to do more subpackages too (not only for debug info) but yknow time is limited

[carmine current]

The greeter + non root weston could be seen as part of the permission checks / hardening etc for nlnet

[trim eagle]

I might look into SDDM into default and at least fixing it for Qt and the SDDM stack Monday. The rest of the plans might be blocked depending on what we do with the thing in contrib-general

[trim eagle]

It could indeed. Tho they don’t do sub payouts so we’d need to split it manually or make it an explicit subtask

[carmine current]

Wait, they don't do split payouts?

Ig then we should make the task list a bit more granular before finalization

[trim eagle]

Well as in if you have a task that says do A, and I complete it but with significant help from someone else so we want to split it, I can’t request 50% of it. Or so I remember from gloire work. Now if that task was do X and a task do Y, which together makes A, that works

@reef steeple might know more

[carmine current]

There's probably an faq entry about that on the nlnet site

[reef steeple]

Ermm no

The tasks are unitary if you wanted to split the payout you gotta split the task

But you can talk it out with them I'm sure they will accommodate

you havent even signed an MOU yet theres no tasks formalized though, just split it for that

[carmine current]

yeah

[trim eagle]

Alright, seems like i forgot to push some minor items for KDE part 6, fixes are on their way. One fix (SDDM) will have to wait until tomorrow as I’m just straight missing the patch

[trim eagle]

Now that that is resolved, we’re moving on to KDE on Managarm proper. All the stuff we need is compiled but plasma seems to be unhappy somewhere during init. Seems that a bunch of dbus messages aren’t getting handled / are stuck somewhere

[native prairie]

damn getting close

[trim eagle]

Yeah but this one is nasty as in the end it’s all dbus calls to systemd so it’s debugging two pieces of shit. Also the coding style of dbus gives me an aneurysm

[native prairie]

lol

[trim eagle]

So it could take a while to see what the fuck it’s doing. Might try writing a minimal reproducer that I can just yolo from Weston as that startup is quicker with less log spam. But it could also be related to not being root who knows. Tho I’d expect permission errors then

[native prairie]

[golden maple]

https://cdn.discordapp.com/attachments/1013636347019411506/1366388469064273930/togif.gif

[spring oak]

XD you saved my gif, lol

[vestal sapphire]

I'm wondering how to make the mount option parsing nice and reusable

I have this, where you can pass it custom parsing logic as well

opinions? cc @trim eagle

this is something I'd place under core/

[trim eagle]

I think core is fine yes. Both posix pseudo filesystems and “real” filesystems must use it so core makes sense

[vestal sapphire]

these options are all what systemd passes

with this I was able to enable returning EINVAL for unknown mount options, which is nice

[trim eagle]

Oh that is nice. Is that conforming to the spec tho?

[vestal sapphire]

I just ignore size and nr_inodes for now, although it shouldn't be all too hard to impl

[trim eagle]

Or are they silently ignored?

[vestal sapphire]

in POSIX, mount options are implementation-defined lol

on linux, unknown options do EINVAL

[trim eagle]

So spec is Linux

Aight then looks good

I look forward to the PR

[vestal sapphire]

eh this needs some cleaning up first

and I also want to support at least one option for ext2 as a PoC

I'll probably just do sb, where you can give it the location of the superblock to use

the nice thing is that we can probably reuse this options definition for implementing fsmount stuff too

[carmine current]

We should definitely define it in such a way that fsopen can also use it, yes

[trim eagle]

So far after a few debugging rounds with KDE on Managarm, here’s a quick status update
There’s a bug somewhere regarding creating sockets as !root where the permissions and ownership of the socket seem to be wrong. DBus doesn’t like that (oops)
If we work around that by running as root, the next problem we observe is that KDE thinks we’re not using systemd, which might be a DBus meme too, but can also be a systemd user instance issue. Related to that is if we explicitly claim we’re using systemd, we then get more issues which seems to be systemd user related. DBus activation of systemd doesn’t work as there isn’t an user instance. And it looks like there’s some issue with how logind handles sessions as the session state isn’t as expected after booting Weston via SDDM. I think all of them except the first one are related. But more debugging is required

[native prairie]

Damn why is it so damn complicated

[trim eagle]

Sockets have funky semantics sometimes. And KDE is a beast of a software with god knows how many components working together and talking to eachother

[native prairie]

Makes sense

All Linux patchwork coming together

[carmine current]

Hmm, I think we should try to fix the socket perms etc to run KDE as user

instead of debugging what happens as root

that's probably the easier path forward

But I'm not sure if the issues are connected, could also just be separate issues

[trim eagle]

KDE as root should work. Works on Linux mlibc

But yeah I do agree

[carmine current]

yeah true

but the dbus as non-root thing needs to be debugged anyway

[trim eagle]

Yep

[carmine current]

and my thought was that systemd --user as root may encounter errors that we don't encounter as a normal user

it's just speculation though

[vestal sapphire]

https://github.com/managarm/managarm/pull/1330 and https://github.com/managarm/mlibc/pull/1760 may help with this btw

we might also need to generally improve all fs-related functions to properly set/deal with mode etc

[onyx cloud]

😍

[rich glade]

How hard was it to port?

[trim eagle]

has quite a lot of steps to it

and it's not fully there

if you look closely you're missing the panel at the bottom

[carmine current]

We didn't have to add a lot to Managarm in terms of code but debugging these big apps is always quite involved

[trim eagle]

especially stuff like this which is a billion components working together

[carmine current]

For example, the last bug was that an error return from fcntl(F_SETFL) caused it to ignore all input devices :^)

and before that there was a rendering bug where updating DRM planes did not send the right kind of page flip event