#Managarm and related projects
1 messages · Page 3 of 1
and the 3 digits in the back of your credit card
https://cdn.discordapp.com/attachments/829403502349647952/1072985432066887731/acpi.tar?ex=6604890e&is=65f2140e&hm=c2f43a9d06f9e881ddc4b7fd4195c10c6b9d6c47313d7ada1735890301c81030& should have all the acpi tables, I don't think I have updated the bios or anything since I did that dump
Thanks
Yeah your bios is fucked in the head
But its good because I can test against that
if windows boots its not fucked enough
They dont even look at the windows debugger shitting itself
They just assume if it boots its good enough
I mean, why wouldn't it be fine if it boots :^)
Lmao
Also desktop
Oh interesting
Can you also dump those as well
same thing happens on my desktop
Were there errors above that message?
no
Dump tables pls if you dont mind
unlikely but you can just try running this iso
@brittle mauve ill add additional logging for _PRT to see which one fails, that dump has like 50 different ones
yeah I am just gonna assume its a managarm issue
given limine itself shows up correctly
and I am pretty sure I have used limine on that laptop before
it's not the first report i hear of managarm presenting a blank screen when attempting to boot it
i would still test that iso, which admittedly doesn't necessarily 100% rule out potential issues in the multiboot2 implementation of Limine, but still
might be this thing that fails
obj = uacpi_namespace_node_get_object(parent);
if (uacpi_unlikely(obj == UACPI_NULL || obj->type != UACPI_OBJECT_DEVICE))
return UACPI_STATUS_INVALID_ARGUMENT;
maybe the bus device is not a device but something else
we're about to see
I can remove that check if thats the case
first time i see someone use unlikely() apart from linux
well its all over uacpi 
my CHECK macro usually has unlikely spiced into it
it does change code gen quite a lot
also if the shutdown would work on my desktop it would be interesting to see if wake by usb works after it because as far as I remember when I perform a shutdown from windows then it doesn't for some reason but if from linux then it does work
wake requires quite a lot of code on managarm's side
not from sleep but from s5
as in turning on the pc when I press a key on the keyboard
well thats a full shutdown
yes
can you guys please try this @storm plover @brittle mauve
this has more logging if prt fails
output is still the same
I don’t see any extra logs
what do u see
it doesn't show anything more than with the old image
it just shows the fault
and the line above the fault?
I added this
wait im retarded
i didnt regen the image
for fucks sake
can you just send the changed kernel
yup
it would be faster
\_SB_.PC00.PEG1.HPEV
and the error code?
invalid argument
uhhh lol
thats a method
why does it try to _PRT on that hmm
_PRT exists a level above, in PEG1
oh fuck i probably know why
try this
or actually no
dont
ill make a better version
here
nice, now it works (other than unhandled minor usb revision but thats unrelated)
shutdown worked and also it powered up when I pressed a key so thats nice
yeah it was me being a bit on the retarded side when looking for a device matching an address
great to hear
did it get to desktop or no because usb?
no because it died inside posix
usb 3.2 too?
i see
yeah I guess its usb 3.2
usb 3.2 fails, shutdown works tho
okay dammn
@upbeat smelt imagine on how many computers this could work if xhci worked
shouldn't be that hard to add the desc tho like I already did for 3.1
so we got like at least 6(?) I think different computers tested
dont worry it doesnt work for other revisions as well
@brittle mauve and on these computers lai died for some reason?
on the desktop I haven't tried lai but on the laptop it didn't shut it down when pressing the power button (and uacpi didn't yet work because of the duplicated node thing)
right
lai supports duplicated nodes?
thats interesting
it supports that yet doesnt support some core aml
yeah if you could add the 3.2 descriptor that'd be greatly appreciated
i think that one should be the last one
two from mint where on one of them lai would die
@native prairie if you provide me the latest and greatest test image after all fixes are done (if you have any) I’ll test on a few laptops tomorrow
Maybe fire up the old desktop too
@native prairie ping me once you have something for the duplicated node thing, I am going to go sleep now but I can test again tomorrow
Ill send one tomorrow morning
Sounds good
Sure, we'll see what I can come up with
Thanks
also I made a pr that should fix the usb thing so it should be possible to boot it to the desktop on pcs with 3.2 too (though ig there isn't really anything related to the acpi part that you could do there)
Ill poll them in if they get merged
Although we weren't able to get xhci working on any tested computer today
Even those without 3.2
Really hoping qookie figures it out
Quirks. Quirks everywhere
We really should focus on stability and bugfixes for a bit
And stuff like make our implementation more compliant
Yup
Which I guess we’re doing somewhat (readlinkat, inotify and recently some socket memes from me, acpi from you, usb 3.2 from qwinci) but for some reason I feel like KDE isn’t it
(but I will continue debugging that and InitWare tomorrow)
Isn't it in what sense?
Isn’t focussing on stability and bugfixes but on porting new shit
I see
also disk io performance should be improved somehow
because then wine would probably timeout less often and ig it would be nice otherwise too
yeah
Mind you, probably doesn’t help that a bunch of packages are compiled in debug mode with no optimisations
Including the likes of GTK and QT
aren't most of them built with relwithdebinfo?
All my ports default to debug
ah I guess its just some of them then
Maybe we should do debugoptimized instead
compile everything with -Ofast -flto -s -fomit-frame-pointer to prevent assertions
-funroll-loops
@brittle mauve will you be able to retest with duplicate node support today?
no but i can do that real quick if you're up for testing rn
yeah I could test it if you send it
now it boots, but the power button doesn't work (and I don't really know what the log says because the kernel log is invisible after it boots into kmscon/weston
no
Actually I have your aml dump I can just check
No as in boots fine but no power button?
yes
I see
well I don't really know if the presses work but at least it doesn't shut it down
And on your pc it literally boots into weston?
Yeah I made it so it dies if shutdown call fails so you would've known
it can boot to kmscon but to weston it doesn't because theres some weird resolution issue where it somehow ends up creating a gfx buffer with resolution 1920x1088 when the actual fb res is 1920x1080)
Control Method Power Button (V1) : 1
Control Method Sleep Button (V1) : 1
yeah your PC doesnt have a fixed event power button
hmm
u have this tho
Scope (_SB)
{
Device (PWRB)
{
Name (_HID, EisaId ("PNP0C0C") /* Power Button Device */) // _HID: Hardware ID
I could try hacking together a handler for this
so we can enable the corresponding GPE and handle it
unfortunately your power button is routed in a very modern way
Method (_Q33, 0, NotSerialized) // _Qxx: EC Query, xx=0x00-0xFF
{
Debug = "=====QUERY_33====="
P80H = 0x33
ADBG ("EC PB press")
PWPR ()
}
Method (_Q34, 0, NotSerialized) // _Qxx: EC Query, xx=0x00-0xFF
{
Debug = "=====QUERY_34====="
P80H = 0x34
ADBG ("EC PB release")
PWRR ()
}
you have to have an embedded controller driver, then read the query, then schedule the handler to run
and then that notifies the system that power button was pressed
or maybe it works without an EC as well but we have no kernel logs so no way to check if a GPE gets generated
Device (EC0)
{
Name (_HID, EisaId ("PNP0C09") /* Embedded Controller Device */) // _HID: Hardware ID
Name (_GPE, 0x6E) // _GPE: General Purpose Events
most likely GPE 0x6E gets generated
which uacpi doesnt enable because it has no handler
i should really write an EC driver
Also your PC recommends PM Profile : 02 [Mobile] mobile power profile for some reason lmao
well its a laptop
oh
apparently not, well I guess that makes sense as udev is launched before the launch argument is checked so gfx claims the device and the output is disabled
the solution is to buy a standalone xhci controller, plug that in, boot off of that and let xhci driver crash
then u see logs

sounds like a plan
or remove the udev rules for vga, that looks to have worked
well theres still nothing to be seen when the button is pressed but at least the log is showed
I wonder if the lid open/close event is also using the ec
lets see
sure enough
Method (_Q15, 0, NotSerialized) // _Qxx: EC Query, xx=0x00-0xFF
{
Debug = "=====QUERY_15====="
P80H = 0x15
If (IGDS)
{
Local0 = LIDF /* \_SB_.PC00.LPCB.EC0_.LIDF */
Local0 = ~Local0
Local0 &= One
Local0 += 0x02
If (^^^GFX0.GLID (Local0))
{
^^^GFX0.CLID |= 0x80000000 /* External reference */
}
}
Notify (LID0, 0x80) // Status Change
}
what actually calls that method?
Also just tested on my main pc, also boots and shuts down just fine, but dies because USB revision
The kernel enumerates the namespace, sees an EC device, calls its _GPE method to find the index of the event that it generates what it has outstanding queries, the kernel then enables that event and installs a handler. Then once that event occurs, it reads a register in EC space called EC_QUERY, that returns the index of the event handler in AML to execute, e.g 0x15 for your lid, then the kernel schedules EC. _Q15 for execution, then that handler notifies the kernel of a status change of lid device by doing Notify(Lid, 0x80)
interesting
makes sense tho
yeah its quite involved as you can see
fun roll loops!!!!
Tried it on my laptop and it seems to work fine!
Though it defaults to using /dev/sda as the root
I wonder if there's some kind of way to change it to /dev/sdc since I'm booting off USB
Cool, did it work with lai before?
Haven't tested it yet
By work fine you mean it boots into desktop?
That would be a first
Usually it dies in some driver
he said it doesn’t fully boot though
“waiting for /dev/sda” means the usb drive was not fully detected
it’s not actually looking for /dev/sda to my knowledge, just for a managarm root partition on any drive (that includes usb drives if they are detected)
but don’t quote me on that, check the source code yourself if you want to know
nevermind, it actually does specifically look for /dev/sda0... interesting
i could have sworn i've seen it look for a partition with a specific guid at some point
Pretty sure we do look for GUID
I saw that. Mana game partition

ios autocorrect fucking me over
Relatable
Tho by now I’ve forced it do to it correctly. Managarm Managarm Managarm
Capitalisation it sometimes forgets tho
mangranam
pain
.!t managarm
It's Managarm, not Managram
*Or any other spellings
shouldve put that in the tag ig
Ig time to update the tag
but honestly you cant even tell
i like how you said "not fully detected" 
aka the driver fucking died
very much possible, hard to tell without a full log
@woven escarp can you show us how it died
I believe its actually detected
I saw along the lines of "mounted /dev/sdc"
Which most likely refer to the USB drive
the only message similar to that is "mounted /dev/sda0"
does your laptop have xhci?
Yes
in which case it's even more interesting as to how it failed
can you actually take the photo of the logs
usb is one of the main failure points in managarm to my knowledge
yup
My laptop has two drives. One is an SSD and another is HDD
They're probably mounted as /dev/sda and /dev/sdb in Managarm
So the USB would be /dev/sdc
No. Unless you have a managarm@root partition there I doubt it. We only mount a partition with the managarm GUID
Which was randomly generated by us
So any partition in all available drives with the Managarm GUID?
yes
The first one it finds I think
...or you could take a photo of logs
Mounting the root is quite hardcoded. We want to just pass the partition uuid on the cmdline like Linux but that’s currently not the case
if you have one on your internal drive and it gets iterated before the usb drive does, then that's the one it will find
@brittle mauve i'll try to hack together an experimental EC driver for managarm today we'll see if it picks up your power button presses
The block stack needs some improvements in general (just like the usb stack)
no
or is it just like "oops well no ram :/ HEL_CHECK(false)"
lmaoo
that is one way to handle an oom
Since it's iterated before the USB, do I need to copy the Managarm partition from the image to my hard drive?
I was surprised as well
i wouldnt call it handling
more like "running away from the problem"
thats like a userspace shitty command line app oom handling
does your internal drive have a managarm root partition?
no
in the block device stack
...yes
i want to partition my drive to have the managarm root partition
what are you even doing that allocates
why would you do that
the kernel has all sorts of dynamic arrays @fervent zodiac
including storing allocated memory
theres your problem
not my problem 
im just here to provide a stable acpi implemetation
yeah ik
that handles oom 
does it really handle it?
yep, every possible allocation is checked and propagated
what happens if you randomly fail some allocations
if it happens in the interpreter it cleans up anything that might've been allocated and returns UACPI_STATUS_OUT_OF_MEMORY
also wait, does this mean that aml can run halfway through
yup
is uacpi on managarm running in userspace or kernel?
Kernel
kernel ofc, just like lai
what happens if it dies while holding locks
the interpreter unlocks them when exiting
But yeah OOM handling is also something we need to propagate
okay at least thats good
not that obvious, lil can run in userspace :^)
i've specifically written it with oom handling in mind so every single allocation has a check and a way to gracefully handle failure
Again, the list of things to do is massive. And my time unfortunately not so. But we’re making some nice improvements in the past week or so. Quite happy with development atm
you might want to block on oom
instead of dying
like go to sleep and maybe hopefully that makes things better
i dont control that, the kernel is free to do it in the allocation callback
also @trim eagle do you happen to know what kills performance in managarm?
the whole thing is awfully slow at times, even without debug prints
on linux GFP_KERNEL is basically almost infalliable
ls -la /proc/self/fd takes like >1 second to complete
The entire thing being unoptimized in most places, and several key userspace components running with debug mode
Hmm. That’s just a regular fs operation. 1 second is very excessive even for us I think
@carmine current might know or have ideas what the big points here are
fs operations that never touch the physical fs

does managarm not have a block cache or something
I sure hope we do. I’d like to think we do. But you’d need to check source to know
Not now at least
We all know what happens at the next managarm development session
Which might well be tonight lol
initware
Kernel log ring?
!!
That’s Leo’s thing and he’s waiting on the mbus refractor last I heard
That said, have you seen the screenshot in managarm general?
ok next coolest thing: KDE
managarm general no..
Related to that yes
let me take a look
Current path is InitWare for well, init, get SDDM working, boot KDE
yeah i saw the thread, cool work so far
If only it worked consistently (or at all
)
any idea whats up with the input?
My best guess is eudev being old and not a fan of booting via systemd / InitWare as a bunch of shit was nuked from it. Udev usually reports via sd-notify that it’s ready to do shit but eudev doesn’t have that anymore
So I’ll probably look at replacing eudev
It’s unmaintained anyway
Yeah one second sounds really excessive
Maybe look at the posix trace and check if there's anything strange
This should be just a few calls to posix, right? Like a dozen or so
Probably
And posix can handle many more than that in a sec
Yep
Debug-options.hpp enable logRequests and rebuild system
Warning, will@spam your log
Might wanna redirect to file and inspect after the run
i expect nothing less than that
i got a big scollback buffer
no worries

im only interested in one part of the log anyway which shouldnt be too big
Aight. Enjoy the GET_TID supercall spam
Even on / one second. Weird
What is wrong?
have you not seen qookie's review?
posix log for ls -la / https://gist.github.com/48cf/eabc3ee8428ddd1675310ab46b234dff
i have no idea what im looking at
it doesnt seem to stop at anything for a significant amount of time, so its just a lot of requests and it takes time?
huhh... it might be related to this as well: xbstrap: Running ['@SOURCE_ROOT@/scripts/vm-util.py', 'qemu', '--arch', '@OPTION:arch@'] (tools: []) No hardware virtualization available!
czapek@raptor-wsl:~/source/managarm/build$ stat /dev/kvm
File: /dev/kvm
Size: 0 Blocks: 0 IO Block: 4096 character special file
Device: 0,5 Inode: 81 Links: 1 Device type: 10,232
Access: (0660/crw-rw----) Uid: ( 0/ root) Gid: ( 994/ kvm)
Access: 2024-03-19 09:32:11.769564111 +0100
Modify: 2024-03-19 09:32:11.769564111 +0100
Change: 2024-03-19 09:32:11.769564111 +0100
Birth: -```
¯_(ツ)_/¯
the qemu i built seems to be less than capable
probably missing some stupid dependency
im just gonna reconfigure and install everything i can lol
nope i cant get it to work no matter what
so annoying
Grep the qemu source for the error and trace what it wants
Oh yeah that
czapek@raptor-wsl:~/source/managarm/src/ports/qemu$ rg "No hardware virtualization available"
czapek@raptor-wsl:~/source/managarm/src/ports/qemu$```
hmm
yeah its whatever
we do
Weird
maybe its ripgrep picking up parent .gitignore and seeing ports is ignored?
Oh it might be vm-util.py printing it?
Nah I can rg through ports
czapek@raptor-wsl:~$ source/managarm/build/tools/host-qemu/bin/qemu-system-x86_64 -enable-kvm
Could not access KVM kernel module: Permission denied
qemu-system-x86_64: failed to initialize kvm: Permission denied```
hey now that's something
oh im not part of the kvm group
Are you in the kvm usergroup?
:)
yep it works now
lmao
one could say it is much faster...
0.192s with posix logs to ls -la /
I sure hope it’s faster

hey its still pretty good with all the vmexits for the helout
yep
Well, w/o hardware virt, the perf is obviously going to be bad
We don't optimize for software virt
that sucks
yeah not surprised there
for the record ls on Lyre with TCG is pretty much instant still :^p
with 100% less PhD code
and asserts
there's probably always room for improvement 
But did you do it from a disk image or a RAM disk?
ramdisk
but tbh managarm is still slower even off a ramdisk
i don't think the bottleneck is storage
IPC 
the IPC should be pretty ok. @carmine current benchmarked that a while back no?
have you tried profiling
managarm ipc has fixed requets/reply pairings, right?
so copy every ipc request and reply you send and receive to a buffer with a tsc readout
and then you can see where its spending time
#1217009725711847465 message
@brittle mauve we can now test on your laptop
where power button didnt work
it should now send notifications
nice
also charger, lid, and fn+whatever keys as well
Based
@native prairie could you send the kernel with the ec stuff implemented?
are you dualbooting windows and linux for development?
if so, i'd recommend you look into wsl
wsl v2 is basically a lightweight linux vm that runs a fully functional kernel
supports kvm, and you can use a fairly recent kernel (6.1 i believe) if you compile it yourself
on windows 11 it also supports wayland applications and runs an xwayland server out of the box
i think you could even do pci and usb passthrough with some powershell memes
and i know for a fact you can passthrough raw block devices, so it's really got everything you might ever need :^)
i develop in wsl almost exclusively yeah
for some heavy stuff like managarm i use ubuntu because wsl io is slow as shit
for me its just as if it was running natively
oh yeah that one sucks
ye
just use the root partition lol
i use native clion and native git fork
oof
so i must use it that way
clion supports remote workspaces
so you could edit via ssh
i use it with vscode like that, except there is an official extension that runs a vscode server on the wsl distro
but there is also a vscode extension to do the same over ssh
i see
I have used the vscode open remote extension and it mostly worked fine
except that things like saving are a little slower ofc
idk im kinda used to have things on my windows drive but i know its not good
also my nvme is almost out of space
thanks, Ill try it
this should spam power button notifications
but also try charger and lid ofc
and maybe some fn keys if u want
then its just a matter of installing a notify handler on the button object from managarm
if we want to hook that notify
is there a standardized way to install a "power button" notifier?
there are two standard ways
are these objects named consistently across acpi implementations?
u never look at the object names, u look at the id returned from _HID (hardware id) or _CID (compatible ids)
and yes, they're always the same
object names are internal to the aml bytecode
they are basically reference handles
oh so the _HID and _CID ids are standard and you can basically use those to listen for specific things?
usually u enumerate the entire namespace once its loaded and you have some sort of "bus" where all drivers that support ACPI list their IDs
this is how I find an EC device for example uacpi_find_devices("PNP0C09", ...
they're like PCI vendor_id/device_id and other fields combined
so basically yes
so technically all vendors use the same _HID/_CID for their power buttons and lids?
im sorry if im being dense
they can use their own extensions and make a custom device and make a new _HID, but still list the classic power button id in the _CID (aka compatible)
but i dont know much about acpi as you can tell
ah so _CID is what you want to look for
yeah, but its not present for all devices, so u inspect both and look for a match
some devices have just _HID, some have a _CID with like 10 extra entries
depends on how simple or complex a device is
looks like they all work, brightness/sleep/wlan fn keys, power press/release, lid open/close and ac connect/disconnect
daaamn
u see it trying to Notify?
fr though, good job on this acpi thingy
thank you
mr portmaster is going to have a lot of fun porting new stuff
yeah, it just says that they have no listeners and thor: EC fired but no SCI event
ye makes sense
holy shit does acpi just work™️?
if we wanted to hook those we would install a notify handler
if you have a capable aml parser
yup
thats the hard part
well of course 
also interestingly it looked like long pressing the power button also generates some kind of different event before it powered off
didn't really have time to see what it was
that is fun
yeah there's not really anything the os could do about it
though ig you could try syncing data to disk really quickly 
lol
eh you can probably try to do some cleanup in the few milliseconds before you get killed
i wonder if os can NAK that
it would also mean that the os could prevent force shutdown completely
yea
yeah but for a good reason
you can always just cut power completely
by taking out the battery
:^)
nothing they can do about it
except when its not removable :p
im sure that if you hold the power button long enough it just shuts down with no acpi event
though my laptop still has a hole in the bottom that you can push with some screwdriver or whatever to force disconnect the battery
if there is something you can cancel of course
i wonder how would one control the backlight?
since you get notify events when pressing brightness control buttons
like a method defined by aml?
some are non standard and require a separate driver (aka for thinkpads i think)
yeah an AML method
thats all the standard shit there is?
where do you get that from
thats a small portion of standard methods
oh thats so cool, thanks!
yeah
having a working interpreter allows u to do an absolute shit ton of things
many people dont realize it
just acpid and upower I think
i wonder how wiring it all up to userspace will look like
would thor just expose it all over mbus?
I would think so
and let posix just create sysfs entries for all the shit
Yep. Likely
how would one handle the funny "set backlight brightness" with mbus? does it support rpc?
@nocturne tide for example this is a power button device from qwinci's laptop
Device (PWRB)
{
Name (_HID, EisaId ("PNP0C0C") /* Power Button Device */) // _HID: Hardware ID
in uacpi u would do install_notify_handler(PWRB, handle_button)
? how do you think any other hardware device is handled
i have absolutely no idea
also it was a genuine question, i do not know how managarm ipc works at all
so i was wondering if you guys have rpc
mbus is only a list of objects which have properties, and, when bound, give back a handle to an ipc lane
ah i thought mbus also handled ipc
tbh just starting with ac plug/unplug and battery charge level would be good
then you just construct the request message, send it over the lane, get the response
so you could just have a "set backlight brightness" message then i guess
that makes sense
we don't do automatic rpc where you only see a function and it automagically generates the code to marshall all the in and out parameters into request and response messages, mainly because korona is not a fan of that idea, and it'd make it potentially harder to add support for other languages
yeah i get it now, i was missing some part of how all of that works
so im assuming a server would "announce" an object to mbus and a client can then find it and that allows you to create a connection?
You’d publish it if I recall correctly yeah
yeah you publish an object on mbus, and if the properties match it notifies all pending observers
ok yeah i totally dont get how that works so i'll have to read up on that
im just being extra dense so dw
No worries. Same
Now we only need for xhci to not suck and managarm will boot on most hardware we tested so far
currently it uses a push model, where the server sends messages to clients which have active observers, but on my mbus refactoring branch i've reworked it to a pull model, where you send a request to the mbus server, and it will respond once there are matching objects (either immediately, or only after new ones are added, controlled by sequence numbers)
ignoring the fact you could just not respond to the server messages and get it stuck, the pull model also integrates into async code in a significantly nicer way
that sounds like a good change
are there any docs on how mbus works?
or do i have to read the source code
i'll read the source code anyway but i was wondering if there was documentation
theres even a talk
Yes. But beer
Multiple. But not on mbus per se
yeah mbus itself is rather undocumented
as is the case with most of managarm :^)
some day it'd be nice to sit down and document stuff, but there's more pressing issues to work on, and i'm not that good at writing 
how would one create a new server? what kind of an object do i publish? does the server know which object was used to create an ipc lane?
im assuming creating a new server is just spawning a new process that publishes objects on mbus somehow
every thread is given the lane to talk to mbus over via ManagarmProcessData (obtained via a supercall)
the object you publish is just a set of properties (name-value pairs), and (in the current model) after publishing an object the mbus server gives you a handle to a management lane, on which it sends bind requests, to which you respond by preparing a new stream and sending the handle to a lane back
yeah this is impossible to understand without code examples 
yeah ngl it is kinda confusing
i'll just take a look at posix in a while, maybe i can understand it after staring at it way too long
okay lets take usb as an example
mbus definitely does need some docs
when the xhci driver is done setting up a new usb device, it publishes an object for it, so the other drivers can find it
so like xhci.device with properties like vid=..., pid=..., subclass=..., if=... whatever
here's the code for that in xhci: https://github.com/managarm/managarm/blob/master/drivers/usb/hcds/xhci/src/main.cpp#L436-L461
and thats supposed to be picked up by a hid driver for example?
hm i was close enough
im guessing the hid driver then looks for objects that match usb.class/subclass to look for hid devices
okay makes sense
somehow that feels really inefficient
well for usb class/subclass often are 0 because they are defined by the interface
hey at least the kernel doesnt go down along with the driver
how so, the mbus server is only there to pass the lane of the stream between the two threads initially
after that they talk directly
that filter thing i mean
to check whether the object is what you're looking for
i can see it getting slow with all those string compares when there is a lot of objects
well it's more efficient than serializing all objects and having the client filter them on it's own
unless you're not just mindlessly iterating them all and comparing them
and besides, you usually filter for like 3 properties at most, and i'd guess mbus objects only have <10 properties on average
and you can bail out early if one property doesn't match
since in the server's view of the object they are in a map
device hotplug cant be that common anyway
oh definitely not
i just hate slow code in general
im wondering how would you approach making acpi available to userspace
since it's handled in kernel are you going to have to have an acpi server built into the kernel?
the kernel already exposes an mbus object for rebooting, and dennis was working on extending that to include shutdown as well
you could eventually move the interpreter into userspace
so it is sort of a server built into thor
i wonder though how would one handle acl so not everyone can reboot the computer
with posix you have uid/gid
but you probably can't utilize it effectively for that purpose
does managarm have some system wide credentials?
threads have a set of kernel-controlled credentials that they can present in ipc messages
via ImbueCredentials/ExtractCredentials
lol imbue
well we'd limit the access to that so only posix can access the mbus object directly
the word i found out about because some c++ helper used it
and you have to send a request to it to shut down the machine or whatever
ahh that is smart
currently mbus doesn't have access control though, but i'm working on that on my mbus refactoring branch
all that phd code finally pays off
to help with that i added token credential objects, which just represent credentials you can send via ImbueCredentials
in place of thread credentials
the idea is that after publishing an object, you add credentials to the acl for it, and then when someone wants to bind to it they have to send the right credential in the request
and to help servers have common credentials, the kernel can have some named ones that it gives to servers, based off of their svrctl configuration
so posix-subsystem would list that it needs the power credentials, and then it can include them when it binds to the mbus object
Just thread UID/GID cuz reboot / shutdown from userspace should be (and will be) handled via posix
shutdown from userspace can very well be initiated by a random program that just talks to the kernel
If it runs as root it’s fine 
or at least thats my assumption with how mbus works
a random process could very well say "hey i want to bind to reboot"
Hmm
unless there are some checks that i am not aware of
Yes that would work in the current situation I think
well currently yes, but as i've just said i am working on it
Yeah fair
i like the mbus rework acl approach though
managarm kernel sounds like a lot of fun
It is. Same for server
Until you go insane on PhD code. Like I went almost 4 years ago
yeah, phd code is the not so fun part of it
but im sure once you spend enough time around it you learn how to read it
just like with any project
Supposedly I should be able to handle it. If I go by the PRs I sometimes can too. Idk how the fuck I’m doing it 
Korona started it. Korona has a PhD. Korona code is PhD code. It’s usually good, but not always the easiest to understand (but that’s also cuz it’s quite advanced sometimes)
lol
ill try and fix one managarm issue today on stream
assuming dennis is going to come home 
why twitch
Discord stream better stream
true
but why
I’m too shy for twitch stream
It is planned
But
i could stream on yt but its not gonna be very entertaining
I might try twitch one day but I like the two way voice comms
same
And on twitch I won’t have those
i mean u can still be in discord voice
I’ll consider it once again
Maybe it is time to try it
Most of my stream is spamming swear words in logs lol
oh i dont think hours of dennis saying stupid shit and typing "kanker" all over the place would be educational

lol

if dennis did more coding it could be educational though
That requires me to have more than one braincells
same
i tend to do good but my adhd is bad and i cant focus for long periods of time
and sometimes i just dont have the braincells laying around
a long while ago i did some streams on twitch of me working on managarm
I Just don’t have them
well it's nice in that it forces you to focus on something at least
so it doesn't end up with you just watching youtube videos on stream or something :^)

the problem is i often just cant focus at all
so i end up forcing myself to do something rather than watch youtube
I’m just too damn stupid
sometimes listening to music even distracts me
Literally negative iq here
i really need to start working so i can either get insurance through my employer or afford it myself so i can go to a psychiatrist and get a diagnosis lol
just microdose regular meth instead of prescribed meth
It doesn’t always get better with a diagnosis. But yeah
I’ll consider it
@brittle mauve do u wanna try the final version on your laptop? I just submitted the PR to managarm
I hooked up a notify handler to the power button as well
so that should work now
sure
....and you said that right after i booted into windows
well I can just build it myself
yeah, Ill have to make a new clone of managarm tho as I only have an aarch64 copy locally and then apply the pr
cant u just clone my fork directly
or just u know git remote add uacpi-fork <url>
yeah that would work or just git fetch origin pull/642/head:uacpi-rewrite
the pr lacks uacpi itself btw (a wrap or submodule or whatever)
oh yeah
well I just cloned it there
/var/lib/managarm-buildenv/build/tools/system-gcc/lib/gcc/x86_64-managarm/13.2.0/../../../../x86_64-managarm/include/c++/13.2.0/optional:477: _Tp &std::_Optional_base_impl<helix::UniqueDescriptor, std::_Optional_base<helix::UniqueDescriptor, false, false>
>::_M_get() [_Tp = helix::UniqueDescriptor, _Dp = std::_Optional_base<helix::UniqueDescriptor, false, false>]: Assertion 'this->_M_is_engaged()' failed.
posix: Unsupported flag in recvMsg
thor: Illegal POSIX request type 38
HEL_CHECK failed: recv_resp.error()
In file ../../../src/mlibc/sysdeps/managarm/generic/fork-exec.cpp on line 459
End of lane
thor: Panic in server /usr/bin/netserver
``` I wonder what is this about (this is unrelated to the pr tho)
also it seems to prevent it from going to the desktop like it did on aarch64 too
it looks like the power button doesn't generate the ec notify's anymore 
or at least it doesn't print/do anything
fn keys and lid open/close do work yeah
still the same
like literally nothing gets logged?
yeah it doesn't log anything
hmmm
i wonder what changed
its not like u somehow enable separate events...
we can try experimenting tomorrow a bit
if u dont mind
spam a bit more logs
yeah
Ill try that
i moved ec init to post namespace load
idk it shouldnt matter but who knows
also enabled trace logs
it appears to work now
yes
damn
i see your embedded controller is doing tons of shit in the _REG code
maybe it relies on that being run after init
@brittle mauve and this laptop is the one with duplicated objects right?
yeah
okay so you have no ECDT table
this means the firmware is not asking for early access to the EC
this is probably why
ill make it so its only regged early if firmware asked for it
Method (_REG, 2, NotSerialized) // _REG: Region Availability
{
If ((Arg0 == 0x03))
{
OKEC = Arg1
OSTP ()
ECFG (One)
MSFG = (S0ID & One)
PBOV = (PB1E & One)
}
}
usually this is implemented as a write to one global variable
but your aml is doing tons of shit
@brittle mauve okay i implemented that properly i think
can you verify that it works from the PR head that you built locally?
so that we rule out other stuff
dont forget to fetch tho
yeah it does work
YEsss
Amazing
thank you
lucky guess on my part
@brittle mauve btw how old is this laptop?
iirc it was released in 2020
interesting
do u know the model?
also i think i traced why it didnt work, in the _REG method it sets feature bits via SMI and it detects those based on the OS type global variable. That global variable is not yet initialized at that point if we run _REG too early
so it sets the barest feature set possible
acer aspire 5 a515-56g
interesting
cool, thanks
incredible...
i believe in supporting our community
so uacpi is as natural a fit as limine and mlibc for me
i will go figure out what all i do with lai (i have been playing with the m68k port of keyronex almost exclusively lately and i need to refamiliarise myself with the amd64 port) and i'm sure uacpi will already provide for it all
this is the way
congratulations on getting uacpi merged
i'd probably be rushing to replace lai with it in my OSes if i used any ACPI library at all :p
well thank you!
do you have your own ACPI stuff, or do you just not touch ACPI?
latter
omg based!!!
Managarm, now booted by InitWare (based on SystemD)
I'd like to thank @quaint fern for the help (and @upbeat smelt and @carmine current and @nocturne tide for the debugging today, good session)
amazing work 🎉
interesting
Is InitWare still maintained
I am pleased to announce that an agreement has been made to merge Keyronex and Managarm into a new OS, to be called Keyrogarm.
The tech industry in general and software engineering in particular has a rich history of successes borne of mergers that promote the interests of all parties. Who can forget the golden age for IBM technologies in operating systems after their dealing with Bill Gates? Where would modern UNIX be without the acclaimed Project Monterey, the unification of HP-UX, AIX, and DYNIX/PTX?
Managarm is recognised as the greatest profoundly-asynchronous pragmatic microkernel on the OSDev server. Keyronex is recognised as the greatest operating system, targetting Motorola 68k-series CPUs, that was created within the 2020s.
By leveraging common technologies, not least the asynchronous I/O frameworks, the new Keyrogarm can break ground as the greatest profoundly-asynchronous pragmatic microkernel on the OSDev server targetting Motorola 68k-series CPUs that was created within the 2020s.
Immediate directions for the new kernel include a comprehensive rewrite of C++ components into traditional Objective-C, the immediate prioritisation of support for 68k-family machines by repurposing manpower previously allocated towards porting KDE and driving Intel GPUs, and the replacement of kmscon by systemd-consoled.
I look forward to this partnership!
Would unironically be cool
looking forward to learning objective-c
most intriguing
looking forward to future updates!
I assume you will be making the transition through Objective-C++
Are you planning to stick to bragi? Or are you going to replace it with a more Objective-C-flavoured interface?
Obviously it needs replacing
We’re also considering rewriting uACPI in rust so we have blazingly fast AML execution
we are reviving NeXTSTEP PortableDistributedObjects
Does it though? I mean it might be possible to adapt even Protocol Buffers and gRPC to work natively with Objective-C
I feel like a modern reimplementation of NSDistributedObject's might not be too difficult
i already have the code to pluck out data and pointers from the parameter & return passing stack/registers on amd64 as well as m68k and dynamically serialise the whole lot
Also, what are your plans wrt security on those objects? I believe that one of the reasons they aren't used in macOS much anymore is because of security issues
Is that fast? I would have thought a more traditional DSL would perform a lot better
i think the bigger problem is that it's slow as fuck!
to briefly explain how it works
yeah i get it
you could use an optimized JIT compiler to avoid most of the performance bottlenecks though
message sent to a proxy object -> method not found handler contacts the remote object to ask for the method signature -> NSInvocation built by consulting stack/registers and interpreting according to the method signature -> serialised and sent to remote -> remote constructs an NSInvocation and invokes it -> remote serialises return value and sends it back -> return deserialised on the other side and stuffed into registers/stack
that sounds ultra slow
it's evil to have to make a roundtrip just to decide how you're going to serialise
actually, you could do a funny meme with a JIT here
NSXPC forces you to designate protocols of proxy objects and permits proxy objects to be given only when in a position where the protocol that the proxy object should understand, so it eliminates that roundtrip, and it also goes asynchronous, and instead of return values, you can pass a block as a parameter, and remote can evaluate the block
a method not found handler saves all the registers, does the lookup roundtrip, builds a proper JIT thunk, restores registers and runs the thunk
and you bind the JIT thunk retroactively into the class
so that you only need to do this once
oh so it's basically apple wayland
this is quite dangerously based actually
in fact on all of {arm, x86, riscv} enough codegen for marshalling doesn't even need any fancy anything
i mean not even fancy regalloc
because ~all registers are ~equal
Fast and safe
yes, its actually what i would do if i had to do this and optimize aggresively for speed
Ah yes how could I forget
Oh we were also thinking to compress the IPC data with xz for that amazing security
based
i say we link xz into every binary by default on managarm
everyone will need compression at some point right?
Yeah
i propose you link every managarm binary with libsupplychain
(which dlopens all dynamic libraries available)
ah yea, good idea
just in case u wanna use another lib
hey bro I heard you liked shared libraries
Omg, thank you so much, thats what i needed all this time
let me just say i think it's an outrage that despite a PR open for over a year, managarm has still yet to be added to the http://www.microkernel.info website
there are even 2 prs open lol
Lol
fork it
Cringe
not the worst idea actually
you managarmers should establish a secretive organisation cloaked in mystery as to what dark money funds it, to be called the Microkernels Group or something like that
managamers
Portable Systems Group
after losing my mind only slightly i got mammogram booting on my laptop off of an usb stick with the usb keyboard working at the same time
still need to debug why usb hubs don't work, and fix the usb hid driver dying when i give it my mouse (although this i can test in qemu)
the laptop touchpad is out of reach for now, i don't feel like writing an i2c driver just yet
me when 15 AML blobs, and this is not even including the potential dynamic blobs that arent loaded by managarm yet because no cpu power states
AML moment
reviving the managarm thread to show how our network stack is actually reasonably fast if you compile everything as release with -O3 
its a bit random but i dont know if thats my internet or managarm, the highest i got was 65 mbit/s
this is using the minibrowser
Nice
what is it on linux?
also
how well does it perform if you use comcast --device=whateverbridge --latency=250 --target-bw=1000000 --packet-loss=10%
atm 60 mbit
so you are losing about 20 megabits not bad
what about that though
looking at how id set that up atm
lol comcast
the docs sound easy enough
lmfao yeah the only reason i remember the name of the tool
I think managarm wants you to run
don't worry about it
i wonder if its less omegakanker to get thor booting without eir rather then relocating thor or eir to a different virtual address, since thor want to be loaded where limine would load eir 
you can ask limine to load eir at a different address btw
Not into lower half lol
no but you can relocate it above the kernel
I managed to get phone tethering over USB working on managarm
very nice
very nice
very nice
very nice
very nice
very nice
very nice
very nice
very nice
nery vice
vicy nere
very nice
very nice
very nice
very nice
very nice
very nice
nery vice
yere nivc
very nice
very nice
vairie naïsse
ベリーナイス
Managarm now shows a notification if a network interface gets an address. May not look like much considering it’s just a window, but it’s a complex operation with multiple moving parts (just like it is on Linux). Of course, this goes over netlink, so we need to broadcast that a new address has been assigned to an interface. On Linux, NetworkManager listens for this and does things with it, here it’s netlink-notify which just notices it and sends away a call with libnotify to the notification-daemon over dbus. We chose for lxqt-notificationd, as we were having some issues with notification-daemon (gnome and kde ship their own in the shell). The daemon then uses Qt6 (in debug mode, so it’s quite slow atm) to display the notification. This process goes over the dbus session bus, not the system wide one, so some dbus memes were needed to not hard rely on elogind. All in all a fruitful endeavor as this work can also be used with mail clients notifying you of new mail for example
pretty sure that's all handled over dbus
i see i see
new irc client just dropped (this is konversation)
yooo
when paired with the notification daemon work, I can get notified of incoming messages
happy with that
Have you ever compiled Managarm on a machine running Managarm?

BTW: I notice it's always root@, have users not been implemented or is it just configured this way by default?
iirc you can change to a different user but no checking of any kind of privs exists
havent actually tried changing user now thinking about it
You can’t (unless you write a program yourself and call setuid). I can (shadow is marked as broken and hacky, but I can do it). If configured correctly (and by that I mean workarounds) it’ll auto login as managarm, but only in kmscon
Permission checking is very limited, but I’m 75% sure we check (e)uid and friends on calls to setuid 
the managarm way
write the most half-assed internals possible
but we have ports
where we just carbon copy linux
did yall go through with the strace """port"""
Nah. But we’ll get one eventually. Needs ptrace tho


