I actually wanted to fix it and I already began doing that in the morning, Ill have to actually test it after I figure out why I can't boot into kmscon/weston at all anymore (it just times out and systemd kills it)
it was broken because mlibc started checking symbol versions, the new solution I came up with for now is that you use a script that does a bunch of patchelf --clear-symbol-version on all symbols with glibc versions and set the osabi field of the executable/library to solaris (so I can still determine whether the caller is a glibc binary or not as the old logic relied on the versioning info)
#Managarm and related projects
1 messages · Page 9 of 1
going forward it might be nice to tag binaries with an xattr or similar for this purpose
or something less cursed than marking them Solaris 
(we don't have xattrs yet btw)
yeah, it was just the first solution I came up with lol
the versioning solution was good but I couldn't figure out a good way to make it work with the mlibc changes (without changing mlibc that is, if that would be an option then ig there could be some env variable or whatever that'd disable version checks for the binaries/libraries listed in there or something like that)
you'd literally need a library full of stubs forwarding to mlibc functions for every single function (though idk if it would be that bad except for the performance overhead it'd cause, it could probably be autogenerated with a python script similar to the rust bindgen one and would avoid the need to patch away all the version info + osabi hack)
PSA: if you want to help managarm (and linux devs as well), you can submit DRM info dumps as explained here: https://drmdb.emersion.fr/
it takes about 5 sec to do
I can compare what managarm has to what is reported there
and it's a nice reminder of what I need to implement
drm_info is ported to managarm ofc 
I got nvidia-smi to start properly now, ig Ill have to redo the annoying proper gpu setup to be able to go further
holy shit lol
if you pull my current nvo branches you should get the nvidiactl device
hopefully that's enough
I pushed them literal seconds ago tho
also remember to repatch nvidia-open 
nice, Ill try
I also updated the udev rule so you shouldn't need to change that any more
it will autodetect any nvidia GPU
it still gives the error, idk which ones of the files it accesses it wants but from an strace on the host it tries ```
/sys/module/nvidia/initstate
/sys/bus/pci/devices/<addr>/config
/dev/nvidiactl
/proc/devices
/proc/driver/nvidia/capabilities/mig/config
/proc/driver/nvidia/capabilities/mig/monitor
the first one and the last two don't exist
the last two were introduced with r570 for blackwell so they're probably optional
it's probably the first one I'd guess
yeah maybe, ig the log could help but it has some weird format lol
maybe I can figure it out using ghidra
no
nvml debug log decrypt Source Code
we should probably set up a package with utilities for nvidia stuff, I have some utils locally as well
government-grade encryption on the logs
yeah they don't give out the decoder for GSP logs either
What the fuck why do they encrypt logs
NVML LOG
Build branch : r575_92
Build date : Thu-Apr-10-15:34:31-UTC-2025
Build CL : 35813551
Build Type : Local build
NVML Log 5/20/2025 16:37:46.019
DEBUG: [tid 77] [0.005513s - nvml.c:207] Entering initWithFlags_Underlock(void) ()
INFO: [tid 77] [0.006452s - nvml.c:295] -1
INFO: [tid 77] [0.006662s - nvml.c:304]
DEBUG: [tid 77] [0.006852s - nvml_checkpoint.c:605]
ERROR: [tid 77] [0.007086s - nvml.c:310] 3
CRITICAL: [tid 77] [0.007706s - dmal/common/common_nvml.c:171] 26
CRITICAL: [tid 77] [0.007993s - unix.c:38] /dev/nvidiactl No such device or address (ENXIO) 6
DEBUG: [tid 77] [0.008335s - dmal/common/common_mig.c:2614] 1b
DEBUG: [tid 77] [0.008685s - dmal/common/common_mig.c:2640] 1b
WARNING: [tid 77] [0.008873s - dmal/dmal_init.c:56] rmDMALLayer.init
ERROR: [tid 77] [0.009072s - nvml.c:327] Driver Not Loaded 9
DEBUG: [tid 77] [0.009225s - nvml.c:346] Returning 9 (Driver Not Loaded)
yeah sounds like it wants the first file here
wait no
why does it not find nvidiactl
do you see it in /dev?
ok only 4 CUs left
idk where it should get the header from tho
ah I might have to just patch it out
I think that what haiku does but it's hidden behind layers of macro defs
I didn't realize that the plainfb force ENV line was added lol
ah yeah
I boot with plainfb.force=0 and gfx.vm=0
ah more compilation errors
brb after dinner
now it wants some ioctl at least
yeah and the display works fine too (as in kmscon is displayed in there though its a little slow when typing)
kmscon is a little funny and idk why yet
I just used weston for the time being
idk how flip completion should work ngl
wtf
it wanted NV_ESC_CHECK_VERSION_STR and NV_ESC_CARD_INFO (which is supposed to return a list of card infos), with that returning a zeroed list it died in nv_get_ctl_state as that's stubbed (and its supposed to return a properly filled nv_state_t, ig that's not too hard as its pci info + bars + other stuff like that along with rm_init_private_state to fill some other fields)
ah we need to implement those ioctls ourselves iirc
for the version one there was a helper but it needed a special case as its not handled by the generic rm ioctl yeah
we currently unconditionally defer to rm_ioctl, whereas linux handles them in nvidia.ko
I just changed it to a switch and added the other ones there
based
though the card info one should also be properly implemented
Hello managarm people
I was reading this: https://github.com/managarm/bootstrap-managarm/blob/master/bootstrap.d/managarm-build.y4.yml and I see there are several gccs.
Do each of them somehow match to the 3 compilations of gcc in the LFS book?
no, kernel-gcc is used for building the kernel and system-gcc is used for building the system (ports and servers)
i'm not sure what bootstrap-system-gcc is used for though
I'm not sure how LFS gccs work, but we have a separation between kernel and userspace
for building userspace, we first build a bootstrap-system-gcc which is a simple cross-gcc + libgcc
that is used to build mlibc, which then is used to build the final cross system-gcc that's used for cross-compiling programs
also iirc bootstrap-system-gcc builds freestanding libstdc++ too
in that case bootstrap-system-gcc is kind of like a stage 1 gcc and system-gcc is a stage 2 gcc
stage 3 gcc is not applicable here since cross compilation but managarm does also have a gcc package
Thanks!
local man creates uACPI basically single-handedly
yet says shit like this
last time i checked it couldnt modeset nvidia 
I've been able to modeset it for a few days already
i mean uacpi lol
but yeah porting it took like 2 or 3 weeks, half of that time was spent dealing with stupid skill issues
is porting 3d accel next?
yes but the NVK shit is borked af
I'll try to actually get it to work on linux first
that's at least pretty simple to test
makes sense
Does this mean that if I switch to mlibc, the Nvidia drivers would probably magically just work?
The Managarm port assumes the existence of a lot of existing DRM infrastructure
trying to managram on physical hardware (a HP ProBook 440 G9, my old school computer) gone wrong
Tag managram not found!
(keyboard input doesn't work)
.!t managarm
managarm
It's Managarm, not Managram
hey at least EC works lol
this might be non fatal if you just let it sit for a bit?
btw my discord is bugged and I don't see what the bot writes lol
It's Managarm, not Managram
what boot option is that even
physical hardware kmscon but I removed serial
they might work
but won't boot kmscon
(we kinda forgot to update those entries)
just use the default kmscon entry?
should I remove the bochs?
still I get the following:
thor: No sink for IRQ io-apic.2:1
thor: IRQ io-apic.2:1 was nacked (synchronously)!
thor: Unstalling IRQ io-apic.2:1 after 100ms
Maybe we should add a msi only boot option
ok nvidia modeset is upstream now, we ball
incredible
Damn
pogchamp
peak osdev
xd
there you go
snakemake
wtf is it
no idea
wtf is alex
dmidecode works
Hmm I wonder how difficult it would be to extract register definitions from the PRMs, kinda like the x86 instruction reference at felixcoultier
There is only a single supplement that has an overview table, and that is only for a part of the register space and for sandy bridge
It would be very useful as the register layout seems to have changed between sandy bridge and haswell a lot, mostly because of more hw support for things
Most
none of the chicken ones for example
They are listed in the workarounds volume
ah ok
Not a register spec but "set this bit in the register at that offset"
There are some powerup things that are undocumented but I don't think you need to care about them
Worst case is that you do need to set them, but you can basically treat that like a quirk
And I'd prob discover them with vfio tracing or re'ing GOP
Sometimes Intel provides the xml that they built the PDF from
never seen that
ok I have utmpx stuff working enough for systemd to not complain
however
I get no keyboard input at login????
yeah whenever I enable logind for kmscon I get no kbd input
Cringe
ah okay the keyboard input thing is probably some sysfs or udev meme
I patched around it for now by removing a part of qookie's original kmscon patch (0001)
still not quite there tho
btw dennis the fix to the --no-pager thing is easy
PR it in I’d say
export SYSTEMD_PAGER=cat
lmfao
ah the no keyboard meme is due to your missing inputX eventX sysfs representation
god I hate that shit tho
I already tried to implement it 3 times
Doesn't it make sense to focus on the syscall cancellation PR before starting another project? :^)
I got fed up from being stuck yesterday so I looked at logind
Ah
I think we need PAM
and proper shadow
I don't think we can get around that
sounds like we want that
recheck the syscall cancellation PR for my "fix"
last commit
that's the best that I could come up with
that doesn't include IRQ await cancellation stuff tho
oops wrong remote, fixed it now
I'll check in the evening
IRQ await cancellation is not necessary anyway, I don't mind if that doesn't work
@trim eagle do you happen to have a PAM recipe I can yoink
Hahahaha you need Pam? Legit?
Yes for logind
I have it, but it’ll take an hour at least to access it
Figured
I'm not home anyways
GitHub is also fine idc
Including patches for whatever needed
Free reminder, needs config files (I’ll provide them too) and a rebuild of at least shadow outside of systemd
ez
Oh yeah been there done that
I think I'm close to logind working btw
So far everything that I tested outside of PAM worked
But PAM is needed for sessions
I mean we kinda need it for greeters anyways
Agreed
God I love threatening myself with a good time
I have more stuff that can use or wants pam
Id love to help with this damn it why is this week so fucking busy and why am I going on vacation after this week fuckkkkk
Bruh
dw
Yes I’ll worry
I’ve been working on this shit for a while off and on and just passing it off feels wrong

ping
I see you don’t need PAM anymore
Yes very happy
Please submit PR then I can take a look at it hopefully today otherwise Friday or Sunday (mind you that after Friday my availability is severely limited and VC is out for 3 weeks due to vacation)
I just ported it lol
I wrote some PAM configuration and put it in extrafiles
I install it as a step in the PAM package
ah I also have a degraded systemctl status
it tries to set up [email protected] which does a few things
I don’t like that
Oh yeah that’s a thing
Kinda need that probably
Any specifics it complains about?
I'll fix that, I commented out some OOM and cgroups stuff
We don’t implement that do we
we're close tho
the PAM side of things looks smooth so far
it's just some systemd memes
Expected
systemd[83]: Trying to run as user instance, but $XDG_RUNTIME_DIR is not set.
systemd[1]: [email protected]: Main process exited, code=exited, status=1/FAILURE
systemd[1]: [email protected]: Failed with result 'exit-code'.
this is quite annoying tho
Why is that not set
it shows up in env
Shouldn’t systemd set that (specifically logind?)
yes
Bruh
I'm as confused as you
Time to trace systemd code then I guess
I have no idea what is wrong with that
Neither do I without looking. There is a small chance I can look on Friday in an afternoon VC? But no guarantees as it fully depends on how quickly I can pack my shit and clean my room
And how early I’m back on Friday
After that VC is a big unknown for 3 weeks
yeah
what I can do is to clean up the mlibc side so far
and push the new packages and patches somewhere
given that user@<UID>.service is degraded I don't think we should upstream it as-is
Fully agree
Can you make a draft bootstrap PR so I can take a first look at that and maybe take bits and pieces for upstream and then PR the mlibc side in so that is already merged and updated
the mlibc side will take some effort
it's ugly parsing code so tests are obligatory
Yep
but overall, the changes so far are very tame if you can look past the utmp(x) stuff
I'm happy about this so far, ngl
So am I

yeah I'm happy to pass this XDG_RUNTIME_DIR shit off to you 
Yeah that’s a small hurdle hopefully for secret project 6
god I wish I did half as much as I get credit for
Lol
The only thing missing was utmp here right?
and some configs and some light patching
Idk man u do crazy amounts of work
Aight. Then I was on the good path locally (I just didn’t have utmp, that is all yours)
Hahahahahaha funny man over here thinking I can do work. Funny funny funny
You’re on your own as it stands for the next 3.5 weeks
Wanna know why?
Cuz my FUCKING LAPTOP DECIDED TO NO LONGER LIVE OF COURSE IT DOES
bruh
LITERAL 2 DAYS BEFORE I GO ON VACATION. THIS BITCH DIES
feelsbadman.jpg
BRB GRABBING EMOTIONAL SUPPORT ITEM
YES I FUCKING BROUGHT IT FROM UNI
CUZ FUCK THIS SHIT
one man down, so this is inching more towards reality now
And people wonder why I’m so fucking unstable. Wonder why
just bring the box + monitor 
grab the cheapest laptop that you can find and ssh into a remote machine 
The GF would kill me (I do plan on moving the box to the GF for the three weeks after vacation)
You mean the remote machine that my mom straight up turns the power off on? Funny
if you have some machine on the same LAN you could use wol
just develop from your vps
I have enough stuff. But my mom is a freak and will literally switch off the extension cords
Can’t WOL if there’s no power to the network
ok so I tried to enable util-linux's login instead of shadow's
it's completely borked
Ideally we should use util-linux login tho?
No?
why
I thought util-linux
LFS pulls it out of shadow
ok then
What’s the problem you’re running into atm?
Makes sense
however [email protected] doesn't have it set
idk why
pam_systemd.so is the only place that sets it
I thought you handed that off to me for debugging in the vacation (laptop is currently away for diagnosis, here’s to hoping it’s fixed in time)
Else i can tackle it after vacation
Real
is it maybe that we need some more config?
But no hurry on logind as it’s not required by anything atm
Post PRs so I can check
so that the user service inherits its env from login?
Wouldn’t be surprised
Euhhhh idk. Lemme pull up the systemd repo on my phone rq
Question
I mean looking at the kmscon upstream service
We use kmscon upstream no?
we might want to use some of that
agetty for instance looks like a thing that might do funni stuff
Im a big fan of agetty but it brokey
This runtime dir, is that /run/user/id?
yes
using the upstream service file while adding the wait-for-devices thing gets me a new funni
Do we do anything with user-runtime-dir.service? Or is that newer systemd
I fear it's getopt memes
Again, I’m pretty sure I stole the kmscon service file from upstream?
that's successful, the dir exists
nope we nuked half of it
Ah
Of course I did
Noted
But yeah if you want that then agetty needs to work
And it does not
Util-Linux provides it
I think we need that ngl
it's a getopt_long meme
Of course it is
oh god
mlibc: pututxline() failed to seek in 3: Unknown error code (?)
agetty[83]: -: not open for read/write
getopt_long was an easy fix tho
Nice
$ login --version
login from util-linux 2.41
Interesting
same here
LFS en Gentoo don’t agree
Very interesting
I would recommend to use the one from shadow. Apparently the util-Linux version is usually a fallback? (Okay basing on ChatGPT but w/e)
Honestly surprised Debian defaults to this
on arch it's util-linux as well
Very interesting
Lemme do more research
I see I see. Util-Linux requires PAM for this stuff. It’s also not clear if u-l can replace the entire shadow stack. If not, we need to hand remove conflicting files from shadow as shadow does not support configure switches to disable installing them
bruh
okay I'm getting further, now it wants some ioctl
okay I have kmscon with agetty
also spicy
Interesting
okay the mlibc side of syscall cancellation should be good I think
I'll clean up the managarm side next
Mlibc utmp after that
?
I'll do some smaller fixes first
utmp needs some work + tests
it would also be real nice to get #924 reviewed + merged
half of that is just yehuda's tests
Understandable
I’ll be out for most of the day, considering I just had the graduation of the GF and we’re going out for dinner now
ah have fun then
Will do
Also
#1344765127383322659 message @vestal sapphire
Check that
And laugh with me

I pushed some cleanup to the managarm side of the cancellation stuff too
there's still a few open comments but I don't really know what to do about them
anybody in VC today?
me
👍 i'll also join, but probably only at 9pm or so
just ping if I'm not here as always

Okay laptop update: apparently it starts again?
I expect to be able to grab it this evening and then it can go along on vacation
We ball
nice
re the syscall cancellation signal changes
it seems to mostly work
except for the small detail that if I run cat, press Ctrl+C, cat does get killed, but bash's wait never succeeds
I don't really understand why
do we make it to Process::terminate()?
yes
but it's being weird about it
the code block with the split signal handling is a bit too verbose rn but should work
if (!delayedSignal) {
async::cancellation_event ev;
ev.cancel();
auto active =
co_await self->signalContext()->fetchSignal(~self->signalMask(), {ev});
if (active) {
auto handling = self->signalContext()->determineHandling(active, self.get());
if (handling.killed) {
co_await self->signalContext()->raiseContext(active, self.get(), handling);
break;
} else if (handling.ignored) {
co_await self->signalContext()->raiseContext(active, self.get(), handling);
} else {
if (self->checkOrRequestSignalRaise()) {
co_await self->signalContext()->raiseContext(active, self.get(), handling);
} else {
self->cancelEvent();
delayedSignal = active;
delayedSignalHandling = handling;
}
}
}
}
i think this should be relatively easy to trace though
so did I but I don't see the problem
the terminated process gets added to the parent's notifyQueue
it can basically only means that either the process is not terminated correctly in posix (= we don't make it to the end of terminate() where we enqueue the notification for the parent)
or the wait() in bash doesn't return
but for some reason Process::wait never returns
are there any changes in wait()?
iirc there was some change to make wait() cancelable, maybe that should be reverted for testing?
it's not the awaits that wait for signal and request handlers to exit btw, those return
maybe bash has a the SIGCHLD handler (not unlikely) and that messes up the wait?
i guess the should cause wait() to return with EINTR
upon receiving SIGCHLD
but i'm not entirely sure how the interaction works
I think the easiest option is to not make wait() cancelable for now
hmm ig in the race_and_cancel the awaitEvent never returns
guess I'll trace this a bit better tomorrow, gtg now
might try that tomorrow
ok what's happening is that in the race_and_cancel, Process::wait returns
but the other lambda doesn't get cancelled?
so the race_and_cancel ends up hanging
so basically I get the log Process::wait done but I don't get AwaitEvent done, or WAIT pid={} done
sounds like a bug in the kernel awaitEvent cancellation
Yeah I suspected that to but I didn't see anything wrong
I should try stashing the changes to that code tho
I didn't do that yet
Stashing the changes is probably not a good idea since the previous state was broken
You could push the current state to a branch though
ok what's super weird is that even when I comment out the race_and_cancel for the wait() call, the userspace's wait request never returns
oh wait it does, it just doesn't show up in wireshark
wtf
ok I see the problem now?
the returned bragi message reports a PID of zero?????????????
what
ah no
ok so the wait returns
but userspace is stuck on this apparently
this is some shared library, I assume libc
in the currently pushed mlibc changes, waitpid() has no SignalGuard anymore
that looks like a problem
I have one locally
the lock cmpxchg may be the one in _waitProgressFutex
but that loop should terminate
and then go into helFutexWait
unless that futex wait is repeatedly interrupted
which would be weird though
I just came back after lunch
and now it works
I am getting royally trolled
okay only kind of
but at least bash now gives me a prompt after cancellation
the read doesn't terminate entirely correctly now tho
Progress tho
ok I have had a few instances where I want to wait for any one of a set of cancellation_tokens to be cancelled
could we have a helper for that?
I don't know if that's correct but something like this
template<std::convertible_to<async::cancellation_token>... CancelToken>
async::result<void> race_cancel_tokens(CancelToken... tokens) {
async::cancellation_event ce;
auto cb = std::forward_as_tuple(async::cancellation_callback{tokens, [&ce]{ ce.cancel(); }}...);
co_await async::suspend_indefinitely({ce});
}
why is that necessary?
Does that always involve race_and_cancel?
yeah
ig it makes sense in the observeThread stuff where we get a generation->cancelServe
otherwise the Process lives on (indefinitely?)
We need to make race_and_cancel cancelable
By letting it take a cancellation_token and then adding a cancellation_observer to its implementation
bruh
That shouldn't be very difficult

ig what happened is that I didn't cancel outstanding stuff for signals that kill the process
however if I do that I get hangs
I'm confused ngl
I have implemented the wait_if changes in libasync that should make the recurring_event::async_wait() return more useful ig
Work update, I might be able to start looking at secret project 6 later today
based
based
i wonder what secret project 6 is
it seems like it’s secret project 6
Indeed it is secret project 6
you can write servers in rust
soon™
speaking of, I should prob rebase our rust upstreaming work
I’d rather use noose ngl
Be right back grabbing the emergency 12 gauge
hmm ig what I could do that doesn't touch other code is making everything use the note passing mechanism for passing data from eir to thor
That’s a good thing. Yeah
btw why do we have a split /usr/(s)bin
Why not
it's annoying 
Why is it annoying?
when you have to figure out if something is in sbin or bin
That would be cool
Meh. No effort here
At least all fixed size data could easily be converted
Did no work cuz network dogshit. I think we fixed that shit tho so maybe today?
apparently we have kcalc
when vs code port
after chrome
we did run chromium
once
would be funni to get that going again but effort
managarm, the dedicated ___ OS
would be especially funny when paired with qwinci's audio work
ngl a vscode port would probably blow up osdev reddit
lmao
managarm the goon os
how they posting some
i even cant post some my post gets immediately removed by reddit filters 🙏
cross post from Managarm server: some basic hardware CI infrastructure
this turns a rpi4 on/off programmatically and captures serial
Failed assertion for that native
feel 
if you ask me, failing with a missing initrd is better than executing garbage instructions ;D
One day
SYSCALL CANCELLATION IS MERGED
what is syscall cancellation
assume you have a blocking read like with cat
and you get a signal like SIGINT
the read should then return EINTR (if nothing was read) or a partial read
if you don't cancel the syscall, the read wouldn't get interrupted

leo made a test that works but only under strace 

the general computer experience

this is super cool, very nice
managarm is a concept, not a functional os
my systemd booted Managarm into a wayland compositor running KDE apps and Discord (in the browser) begs to differ 
on what architecture?
Managarm is closer to being a functional OS than almost all hobby OSes
huh
its not daily drivable but definitely not a concept lol
what I said was a joke (bad I admit) in response to this meme
AMD64 of course. The one and only
Kinda got that
(I suspect systemd to work on aarch64 too but I didn’t test it myself, and full disclosure the browser kinda broke, it’s on the to fix stack but it is big and I’m on vacation)
which browser
I have never been able to test a good version of managarm because I do not master the compilation toolchain, is the policy still not to offer a release for those who want to test?
We make nightly images
Webkitgtk
ditch webkit embrace chromium
https://builds.managarm.org/projects/managarm/2025-07-24T16:17:13/repo/files/x86_64/image.xz latest successful CI run produced this
Yes yes one day
thanks you
https://docs.managarm.org/handbook/getting-started/trying-out.html for qemu instructions
I'm going to test it on VirtualBox, because I can't configure the network cards properly on QEMU.
Sure thing. If something doesn’t work please do open an issue on https://github.com/managarm/managarm (oh and the sway boot option won’t work by default as the nightly image doesn’t install sway into it)
ok I think I implemented the logic for SIG_IGN-ing SIGCHLD
also SA_NOCLDWAIT
doesn't even need mlibc changes 
nice
does this fix exiting out of bash in weston-terminal not closing the terminal window?
or is that something else entirely being broken
that's like one of the longest standing bugs
i recall it being there when i was first poking at managarm in 2018/19
nope
Ctrl+D on that is still borked
ig it would be nice to figure that out, maybe with wireshark?
i need to look at ptrace at some point
or at least the bare minimum for implementing some simple strace-like tool
it would also be kinda based to be able to debug with gdb
running and being able to live debug something would be way more fun tho
but coredumps are based too
for testing the weston-terminal thing it might be easier to test weston-terminal --shell=/usr/bin/true
so you don't get any bash stuff in the logs
and only get a blank terminal that's supposed to close immediately
I'm looking at the wireshark dumps for bash withing weston-terminal, it's looking fine tho
btw i think next best request to implement cancellation for would be poll :^)
so you can ^C x/wayland apps
or well, you can do that now, but you need to do something that causes an event to be sent over the socket for it to wake up from the poll and try reading instead
the only funni log I get from that is pts.slave not implementing handleClose
maybe it's stuck in a poll with the master fd?
and is waiting for it to end with POLLHUP?
hmm sounds plausible
static void
io_handler(struct task *task, uint32_t events)
{
struct terminal *terminal =
container_of(task, struct terminal, io_task);
char buffer[256];
int len;
if (events & EPOLLHUP) {
terminal_destroy(terminal);
return;
}
len = read(terminal->master, buffer, sizeof buffer);
if (len < 0) {
terminal_destroy(terminal);
return;
}
terminal_data(terminal, buffer, len);
}
:^)
ok
I have to leave in 5 min so ig I'll implement that tomorrow
pls review #975 in the meantime tho 
interesting that it doesn't wait anywhere in the terminal though?
hmm weird, naively making the master end of the pty just return POLLHUP when the last slave closed leads to weston-terminal instantly closing

weird
if I understand the logic correctly, handleClose should be called when the last fd refering to the file closes?
SA_NOCLDWAIT my beloved
Nice
coredumps work 
What's required to generate one?
How complex is it?
and then you just dump memory
fairly easy
Do u dump it from the kernel?
nah the posix server
Damn
in a classic monolithic system it'd be the kernel though right
yes
just for future reference if I ever get to implementing it
Like the .data and .bss or dynamically allocated stuff also
no, you just iterate the VMAs and dump some of them
you list all VMAs as PHDRs
and the ones with a fileSz != 0 are appended at the end of the file basically
Ill definitely do that as well
yeah it's pretty easy
there are a few note sections that are annoying to compile the data for
and dumping them is super annoying
Why is that?
readelf treats them as binary data 
you need to use eu-readelf -n
it took me a while to figure that part out ngl
elfutils
Ah
now let's see paul allen's elfutils
launching on the raspberry pi is now basically as fast as starting qemu
this is over an internet connection, not local LAN
4 seconds from launching the command to first line of raspi firmware
Nice work!
Does this contain the intel iGpu driver collection thingy in this thread?
@vestal sapphire LIL questions asked
Yeah so are there any plans to eventually add support for amd integrated graphics? Or is the plan to be intel only?
if someone contributes amd drivers, sure
I'm not doing it tho
amdgpu driver looks like significantly more effort than both intel and nvidia
mlibc#1398 and managarm#995 gets us to desktop on riscv64 :^) hopefully after doing some more signal memes we can get a working terminal
yooo
I don't have it handy the next couple weeks but lmk if you want to test on my HiFive Unmatched
that would be cool, but i'm absolutely unsure about hardware support but if it can run limine (needs uefi) then maybe it's worth a try?
It definitely does
I do that for running BadgerOS on it already
Last time it didn't boot because of some bug in thor IIRC but that's a while ago now
There are 31 GPRs, not 30. 32 including PC.
isn't it x0-x31?
so excluding x0 (constant 0) it's 30
wait x0-x31 is 32 ☠️
- for(int i = 0; i < 30; i++)
- regs[i + 1] = thread->_executor.general()->x(i + 1);
+ for(int i = 1; i < 32; i++)
+ regs[i] = thread->_executor.general()->x(i);
does that look correct too? seems more correct to loop over all gprs skipping x0
Yes
I use the spot where x0 would be for the PC but you're probably already doing that.
yup exactly
but pc is not a normal register
well, there are 32 grps (one of which is zero) and PC
x0 is hardwired zero so PC is often put in the first slot out of 32 because of convenience
with signals fixed we can run a shell :^)
damn and u say u cant do anything
i was just filling in holes
the only original piece of code i kinda wrote is the msi allocation and routing for riscv
but i am happy with this result ;) getting something to work with not much effort is nice
welcome to the managarm pipeline
getting sway in took 2.5 years
I did take breaks tho
it gets better
sick
this means that Managarm can now boot and run desktop environments on all three supported architectures
now we just need some more riscv drivers for real hw to be able to claim that we can also do it on all three archs on real hardware

Wellllll. Which real AArch64 hardware do we run on now then?
raspi4
Oh I thought we were still missing stuff there
I guess USB boot cuz we don’t have a SD card driver yet right
we're missing some patches by qookie that already exist though
and xhci is not fully functional
Yeah ok that makes sense
good news, I got webkitgtk to compile again
bad news, just opening managarm.org gives me 3 dead threads 
Yeah
also there are the socket leaks in the netserver
uefi exception
idr which one
i think it said synchronous exception
socket leaks?
there was some kind of misuse of a weak ptr where its promoted to a normal shared ptr and stored creating a reference cycle
or actually it wasn't a reference cycle, its just that a shared_ptr<Tcp4Socket> is stored inside a vector in Tcp4 and only removed from there inside Tcp4Socket destructor (that never gets called because the Tcp4 keeps ref to it)
ah
i guess the fix is removing it on close, not when it's destructed
close = the file lane (not the passthrough lane) is closed
what I did for that when I tried to make the tcp server stuff work was to just change Tcp4 to instead store a vector of normal pointers
what's Tcp4 anyway? what is that object supposed to represent?
the entire machinery behind handling any incoming ipv4 tcp connections?
struct Tcp4 {
void feedDatagram(smarter::shared_ptr<const Ip4Packet>);
bool tryBind(smarter::shared_ptr<Tcp4Socket> socket, TcpEndpoint ipAddress);
bool unbind(TcpEndpoint remote);
void serveSocket(int flags, helix::UniqueLane lane);
private:
std::map<TcpEndpoint, smarter::shared_ptr<Tcp4Socket>> binds;
};
so yeah, it's the state used to manage tcp connections i guess
yeah
basically the set of all bound sockets
the IP header tells us if a packet is tcp or udp but not what port it's addressed at
so Tcp4's job is figuring that out
coming to a mlibc build near you soon™
ngl that was easier than I thought
btw I was able to just copy/paste the CFI annotations from the linux sysdep into managarm 
so if 1401 gets merged the managarm sysdep will be ezpz
decided to try and see if the Vulkan based version of glxgears works. It does, after enabling a vulkan driver in mesa, without patching
from Managarm?
that'll probably run out of disk unless leo has a very large image lol
we fixed GNOME Calculator!
What does managarm do for USB?
How do you mean exactly? What kind of information are you looking for?
Do you use existing libraries? How do you handle HID? How about USB MSC devices?
How about devices that use vendor-specific interfaces? Is there any sort of support for that (at least in the sense you could make a driver if you wanted to)?
I'm basically looking into what the USB because I want to be able to use USB HID and USB MSC myself.
all the usb drivers on managarm are in the drivers/usb folder, you could look there
From what I see there, it looks like Managarm has its own USB drivers
yeah
I guess I'll be doing something similar myself at some point
But I don't think I'll support older USB controllers
we just have our own HID driver, and that should support the basics of mouse/keyboard/touch input
for the rest, we have some class drivers like ECM, NCM, MBIM etc
you could just write drivers for vendor-specific interfaces, but we haven't upstreamed any such driver yet
I do have toyed around with a driver for the vendor interface of an ASIX AX88772B and a RTL8153, but that's not ready yet
Here is a book about USB driver development: https://www.amazon.fr/USB-Universal-Benjamin-David-Lunt-dp-1717425364/dp/1717425364/ref=dp_ob_title_bk This is a very good source of information and the author answers questions on the osdev forum.
Have you ever wondered how to use the USB hardware to send and receive data from an attached device? Wondered how to detect and initialize the controller, retrieve the device's descriptors, configure the device, and then communicate with it to send or retrieve its data? This book explains the ins...
Honestly, since I got the book, I haven't needed to ask him any questions. 🤣
managram ded
fake news
Managarm is doing great in the last few weeks
We got a driver for the bpi-f3's NIC
which we can now boot using NVMe over TCP
Also, we (or rather, qookie) upstreamed a bit of work for the raspberry pi including proper DMA barriers for non coherent memory
and @nocturne tide made Managarm boot to userspace on Apple M1 real hardware
with a driver for Apple's AIC interrupt controller
and running the kernel in EL2
also, Leo fixed a lot of bugs and he almost has thread groups and non-trivial Linux clone() flags working
thats ultra kewl
If we’re talking past few weeks, we also got gtk4 to work properly, tested that with gnome-calculator and made the ports collection grow to 400 recently
(And now I don’t have to think about the failure that is Secret Project 6)
btw @trim eagle did you upstream libqalculate?
related pic :^)
sadly you can’t really see it’s a mac so i’ll get a proper pic later
It uses some proprietary nvme command set right
But insane work
you need an rtkit driver for the nvme to work, rtkit is some sort of operating system (???) and it uses shared memory for ipc, im not sure how it ties with the nvme but we’ll see :^)
Wait what the hell
i don’t have nvme yet, all that we did recently is a few kernel/eir changes so it boots and passes a framebuffer, also some changes for correctness because a lot of existing arm code did not anticipate such a dumb interrupt controller
Why did they have to complicate it so much
it would be amazing to get nvme to work but im sure its not trivial
because otherwise it wouldn’t be apple :^(
Real
rtkit has had a few cves in the past lmao
so it’s a great example that complexity only introduces vulnerabilities
excessive complexity* i guess
it could have been a simple nvme hooked up over pci but that wouldn’t be complicated enough lmao
but maybe thats how they can achieve 40+gbit transfer rates for their nvmes without much effort
actually i might be lying, idk how fast they go but i think they can do 10GB/s RW
or maybe 10Gb/s, which doesn’t sound so impressive anymore
they can apparently do between 3-5GB/s depending on the size and model
in some cases up to 7GB/s
30-40Gbit/s is pretty fast
That sounds like a more or less conventional nvme
tbh the apple aic is not that bad
It's actually pretty simple
Aside from the fact that it uses FIQs instead of IRQs for the timer
the apple NVMe situation is objectively just dumb
they get slow ass NVMes that are just special for no reason
with an insane controller that they had to spend time and money on
just for every comercially available SSD to run circles around that
they just shot themselves in the foot ngl
but ig they can charge dumb amounts of $$$ to people for storage upgrades
Was it done purely so people cant put a custom nvme there they didn't buy for 9999999 dollars?
the only other explanation I can come up with is saving on PCIe lanes
sooooo
sounds like the beancounters had a little too much sway there
100%
and I mean there are upgradable SSDs around, it's just not super trivial to install
esp given that you need a second mac 
i wonder how dumb the pcie controller is in the m1
it’s ECAM compatible apparently
idk if that means much or if a controller can be not ECAM compatible but it seems pretty doable :^)
Well RPI controllers only support one device reg view so not ecam compatible
There's a select reg or something
That's probably the plan 
Yeah, the are many controllers that are not ecam compatible
Almost no arm pcie controllers are ecam compatible
Just to get a feeling of how ecam and hence acpi compatible the arm world is: there are 401 device trees with pcie hosts in the linux source and 10 that support ecam 
I think ecam implies dma-coherent ah, actually that's probably not true
Does the dt of the m1 have dma-coherent on the pcie controller?
pcie@690000000 {
compatible = "apple,t8103-pcie", "apple,pcie";
device_type = "pci";
reg = <0x06 0x90000000 0x00 0x1000000 0x06 0x80000000 0x00 0x100000 0x06 0x81000000 0x00 0x4000 0x06 0x82000000 0x00 0x4000 0x06 0x83000000 0x00 0x4000>;
reg-names = "config", "rc", "port0", "port1", "port2";
interrupt-parent = <0x0f>;
interrupts = <0x00 0x2b7 0x04 0x00 0x2ba 0x04 0x00 0x2bd 0x04>;
msi-controller;
msi-parent = <0xbd>;
msi-ranges = <0x0f 0x00 0x2c0 0x01 0x20>;
iommu-map = <0x100 0xbe 0x01 0x01 0x200 0xbf 0x01 0x01 0x300 0xc0 0x01 0x01>;
iommu-map-mask = <0xff00>;
bus-range = <0x00 0x03>;
#address-cells = <0x03>;
#size-cells = <0x02>;
ranges = <0x43000000 0x06 0xa0000000 0x06 0xa0000000 0x00 0x20000000 0x2000000 0x00 0xc0000000 0x06 0xc0000000 0x00 0x40000000>;
power-domains = <0xbc>;
pinctrl-0 = <0xc1>;
pinctrl-names = "default";
phandle = <0xbd>;
i cut off the rest as it contains some hardcoded pci devices
Ah
I think it's not a big deal whether it's dma coherent or not since we need to insert cache flushes into the drivers anyway to support the pi etc
But still a bit surprising that it's not coherent
i think that with a simple-framebuffer, once we write an applespi driver, xhci and nvme we can get to weston :^)
As the more powerful machines have a higher chance of having coherent dma
nvme is optional since we can boot off usb
keyboard is done over spi and touchpad is usb
the dt spec says that dma-coherent can be implied and that then only dma-incoherent is valid (and vice versa)
but idk how the default is determined
does it still need custom init?
yeah but it doesn't look so bad
for each root port you enable the clock, you reset the root port, 100ms and set up the irqs
makes sense
which you can't even do
i think what he meant is that if you want more storage you pay way more than you should for the hardware lol
Just attach an nvme enclosure over thunderbolt 
yeah sure, just write me a thunderbolt driver 
I don't even want to think about how tb works 
Don't you know, would this work. Namely, in uboot's cli, you set bootargs, using setenv bootargs 'blablabla'. The question is would the blablabla reported to the UEFI loader via EFI_LOADED_PROTOCOL's LoadOptions field? uboot's documentation implies it would. Didn't you try to pass parameters for the loader this way? Unfortunately neither fatload nor load not bootefi can pass anything useful in this spirit. Can't check by myself and asking people to do it for my case would be too bold - they would need to figure partition GUID or MBR Signature and offset, then type all that. 😁 but maybe managarm makes use this way for the uboot case. I use it as an alternative way of passing the Boot Volume Descriptor. Works via UEFI shell, not tested on uboot commands.
The LoadOptions field is defined to be binary data (no joke), so ig that could work
For U-Boot tho you can probably also just pass args via dtb
that's basically what you're supposed to do
the standard is a /chosen/bootargs node in the dtb
Yes, when booting from the BootN variable, that field points to the OptionalData part of the load option variable and it can be anything you need (and I use this). When loaded via the UEFI shell, that fields get the command line (as per the EFI Shell specification). I just wanted to know if someone experimented with uboot this way. Well, how it's written in the uboot documentation, looks like it would pass the contents of bootargs.
With no dt involved. It's about uboot integration with the UEFI standard.
idk, uboot uefi is a meme anyway
why would you want uboot to pass bootargs to uefi
that also requires bootloader support
just pass them yourself if you load a bootloader anyway
and if you boot linux directly with efistub the bootargs are baked into the executable anyway iirc
i think uboot can pass args if you do booti/bootm
you still need a dtb with uefi
how else do you want to discover devices on the system bus?
UEFI supports DTBs
Currently yes. In future, hopefully, no. But it doesn't matter, since messing with dt still would be left to the kernel. The loader should be free of this. My loader looks into LIP->LoadOptions and if it's not NULL, inspects the contents. If it's Boot Volume Descriptor, defined by the boot protocol, it means we are getting loaded via our BootN variable - the installed, main scenario. We get needed info from that descriptor (partition, system root directory, file system type). Alternatively, if the BootN got deleted, but the installation is valid, the user can pass the text form of the BVD. As I said, with firmwares, implementing EFI Shell and its protocols, you can pass the text form of BVD during the loader start in the CLI. Or, via implementation's Boot Manager if the latter allows one to create a boot option manually including with allowing to set Optional Data as text. For uboot it was unclear. Now I see it allows via the mentioned setenv bootargs, just need to ensure. As of why not from dt. Even if I have to use it, that would happen in the kernel, the aforementioned logic is in the beginning of the loader. The latter is purely UEFI OS loader. Its code is almost 100% architecture agnostic, no way to screw it up by such an abomination as dt.
update on the rust situation
I can't wait to upstream managarm support to all the crates
You and me both
Managarm rust target is in the current bors rollup
I saw that live as it happened
Based
Nice
And the next nightly ofc
Managarm is now in upstream Rust nightly
$ rustc +nightly --print target-list | grep managarm
aarch64-unknown-managarm-mlibc
riscv64gc-unknown-managarm-mlibc
x86_64-unknown-managarm-mlibc```
:^)
sorry for shitty crop i cant take a photo without my face in the reflection lol, but here’s managarm booted into systemd on an m1 macbook air :^) i wrote an aic (apple interrupt controller), sart (sort of an iommu but for dma filtering), rtkit (apple coprocessor driver, used by the ans2 nvme) and of course an ans2 nvme driver, still got some bugs to iron out + i need to write an spi driver so i can get keyboard + touchpad and boot into weston!
Holy shit damn
Is there any documentation on these apple specific chips/devices?
of course not :^) (other than projects that have reverse engineered it)
one of these projects being https://github.com/AsahiLinux/m1n1
holy shit
absolutely crazy
Progress: Managarm can now boot into its kernel on Radxa Orion O6 which is an ARM SystemReady board with UEFI + ACPI
However, we don't have proper ACPI support on aarch64 yet, so that will be the next step
And also, we can do this over HTTP boot (another new feature)
Cool
thats a 500$ arm board 😭
it's probably a bit less than $500
but yeah it's not cheap
it's quite capable though
yeah, 12 cores for an arm board thats like 3 raspberry pis
WebKit revival in progress
nice
are there any plans for a new post on the managarm website?
yeah we have some content to share
progress on that is slow though, seems that none of us are eager blog post writers lol
oh I just noticed this, holy shit managism is getting more and more impressive by the day
some progress by @vestal sapphire : we can compile + run sortix's os-test testsuite on Managarm and we get more passing tests than Minix and Redox
this is a testsuite that tests posix compliance
getting UDP tests to work would get us another 1.5%+ of conformance
would pty be stuff like ansi support or smth?
https://sortix.org/os-test/pty/#pty
it tests things like tcsetattr
@vestal sapphire it'd be nice to generate the report for Managarm on CI
i wonder if we have any good way to do that
we should probably expand virtual boot
maybe have a python script running on the Managarm side that sends the output base64 encoded over serial
I think improving virtual boot is something i might do next
os of the future
don't worry
Lol
you don't need pty support or ppoll if it's blazing fast 🚀🚀🚀
Balzing fast lmao
let a man typo
Funny typo
now run os-test on menix 
💀 i would need waitpid for that
Skill issue
yeah
flex on redox by building their kernel in managarm
soon
No need to shit on redox, they also have a few cool things that we don't have
Would be pretty funny if Managarm eventually surpassed Linux in these tests
just pay a shit ton of money to be granted exceptions for failing tests :^)
functionality doesn't matter if it's memory safe 😔
rust support with libc 
upstream
that's true but it doesn't really give a huge benefit unless you're building rust programs outside of xbstrap
And where’s your rust target in upstream?
Oh wait
Simply dont have a rust target and use a better language smh
C3
rtkit is also used on embedded devices
and the interrupt controller is dumb because it comes from the iPhone
i think it's originally a samsung design? probably got revamped a lot but it should be related to the A1 (first iPhone's SoC) which is a samsung design
the apple interrupt controller is actually quite nice
except that for some reason they decided to route the timer interrupt to FIQ
some progress from my side: I improved the CI such that we now
- test whether all boot protocols work on x86 (uefi, limine, mb2), both on bios (where applicable) and on uefi
- run posix-tests and kernel-tests on each github actions run
these test run after booting with systemd to check that both kernel + userspace work
Help, Marvin and I have been nerdsniped by microkernels 
Skill issue 

But yeah I want to learn about them. Probably not this instant because of the time of day, but still.
source lines of code is a useless metric, but mlibc has surpassed musl in SLOC
Image viewer based on the GNOME stack. Now with SVG support (GTK SVG support is nasty stuff, Qt does this a lot nicer)
Damn I can taste the DE already
One day
Gnomagarm
we also have a bunch of KDE stuff though lol
