#uACPI - a portable and easy-to-integrate ACPI implementation

1 messages · Page 38 of 1

gentle peak
#

and i always use smm=off for that

fiery turtle
#

Its also called by uacpi on fatal init errors

#

But yeah

gentle peak
#

i don't really count those as direct usages

fiery turtle
#

True

#

I guess I have enough fixes to publish a 1.0.1 tomorrow

#

Right now I simulate persistent io, aka all stuff thats written can be read back so I could do that actually, maybe I should

#

Previously it would just read FFs

#

More coverage = better so ig

gentle peak
#

qemu-system-x86_64 -accel kvm -cpu host,migratable=off -debugcon stdio -M q35,smm=off -cdrom proxima.iso | grep -E 'avg 1[1-9][0-9]{6,}' maybe i'm a little ambitious

#

uacpi: info: successfully loaded 1 AML blob, 1705 ops in 0ms (avg 10995672/s)
so fucking close

#

uacpi: info: successfully loaded 1 AML blob, 1705 ops in 0ms (avg 11059937/s)
yep.

dense steppe
#

how much does performance differ if you don't pass ,smm=off?

gentle peak
fiery turtle
#

Lol

gentle peak
#

i can try fixing the pf bug rq

fiery turtle
#

Yeah just move the if statement

gentle peak
#

it has an impact of maybe 200k-300k at most?

#

smm that is

fiery turtle
#

I wonder why there's an impact at all

gentle peak
#

could be placebo

#

could be that i ran it without smm thousands of times filtering for an 11M result and i only ran the with smm one like 5 times and took the highest

fiery turtle
#

Yeah

gentle peak
#

it definitely feels like there's more results in the high 9M range

#

but idk

#

instead of the low 10M

fiery turtle
#

Strange

#

But idk what smm does in qemu

gentle peak
#

still crazy that i'm getting low 9M on a leaderboard-legal build

fiery turtle
#

Yeah idk how thats even possible

gentle peak
#

i really want to clean up the code and put it on git and the leaderboard as the last thing i'll do for the old kernel

fiery turtle
#

Likewise lol

gentle peak
#

but to get a comparable iso i'd have to do some really weird shit with github actions and i'm not really up for that

fiery turtle
#

Maybe you will get there with the new proxima

#

I mean u got a legal 13M as well

gentle peak
#

but it still smells

fiery turtle
#

Force push

gentle peak
#

you make a good point

fiery turtle
#

Lol

gentle peak
#

idk if github actions will even work rn since the last run (a few hours ago) got a 502 from one of the deps' git servers

fiery turtle
#

GitHub actions are so flakey

gentle peak
#

it's not really actions itself in this case, just gnu's git servers

fiery turtle
#

Sometimes stuff just hangs too

gentle peak
#

i've never had that happen

fiery turtle
#

Lucky

fiery turtle
#

Or you don't do apple runners

gentle peak
#

oh yeah i don't

fiery turtle
#

Those love to hang

gentle peak
#

i managed to fix {disable,enable}_preempt's performance problems and i'm still getting low 9M with cpu-local instead of thread-local so i think i will indeed be pushing this to git

north holly
#

I need to setup github actions for obos

#

like CI testing

#

considering how much obos regresses

#

it would be useful

gentle peak
#

yeah i've thought about doing automated testing for my kernel

#

but the way i want to do it requires a pretty large amount of userspace functionality so not yet

north holly
#

tbh idk how I'd do it

gentle peak
#

ah, the way i was thinking was to have a build option that makes the kernel shut down on panic (qemu has a way to do this with a single io port and you can also set qemu's exit code)

#

then just test syscalls with a 'normal' user program

#

and -no-reboot ofc

north holly
#

(launch qemu shit) | grep Arch_KernelMainBootstrap: Done early boot.

north holly
gentle peak
#

the large amount of userspace functionality is mostly to have things to test

north holly
#

fair

#

I think half my syscalls are completely untested

#

as in, no userspace program uses them, and I never tested them manually

#

also wouldn't you need a cross compiler to compile a userspace program?

gentle peak
#

'need' no but it's a good idea

#

good thing my CI lives in the bootstrap repo

north holly
#

what I'll do is have a syscall to test all syscalls trl

#

(don't ask how that would work, I just made something up)

#

I really gotta focus lol

#

gotta finish some homework for tomorrow

gentle peak
#

now i just have to wait 20 minutes and i can get the highest score proxima will ever get (because it's the last score i will submit before switching to a microkernel)

gentle peak
left orbit
#

now that's more like it uacpi: info: successfully loaded 1 AML blob, 1705 ops in 0ms (avg 10054310/s) uacpi: info: successfully loaded 1 AML blob, 1705 ops in 0ms (avg 10235875/s) uacpi: info: successfully loaded 1 AML blob, 1705 ops in 0ms (avg 9958414/s) uacpi: info: successfully loaded 1 AML blob, 1705 ops in 0ms (avg 10038682/s) uacpi: info: successfully loaded 1 AML blob, 1705 ops in 0ms (avg 10152858/s) uacpi: info: successfully loaded 1 AML blob, 1705 ops in 0ms (avg 10271084/s) uacpi: info: successfully loaded 1 AML blob, 1705 ops in 0ms (avg 10113532/s) uacpi: info: successfully loaded 1 AML blob, 1705 ops in 0ms (avg 10092639/s)

#

roughly the same as the cheating iso wtf

gentle peak
#

is that using the iso I just sent or one of the earlier ones I tagged you with

left orbit
#

these logs are from the one right above

gentle peak
#

great, I can use them as my score

left orbit
#

but the cheating iso gets the same results lol

gentle peak
#

what cpu?

left orbit
#

i7-13700k

#

proxima finally works on intel :^)

#

and now my home directory is full of proxima isos

gentle peak
#

alright ty

left orbit
#

np

gentle peak
#

finally an 8 digit score on the leaderboard

left orbit
#

hell yeah

slim panther
#

i'm going to rewrite the pmm today, let's see what i can get out of it

kindred beacon
#

I can try compiling managarm in release mode with lto and such

#

I can also fix the remaining 5 assets that have side effects

dense steppe
#

because of birthday problem you now only have $$4K \cdot \sqrt{\frac{totalram}{4K}}$$ memory

solid pantherBOT
vale isle
#

oh my god

#

13 fucking million

#

wtf

#

i should come back to osdev

#

and port uacpi

fiery turtle
#
--- a/source/uacpi.c
+++ b/source/uacpi.c
@@ -264,12 +264,16 @@ void uacpi_state_reset(void)
     uacpi_deinitialize_events();
     uacpi_deinitialize_notify();
     uacpi_deinitialize_opregion();
-    uacpi_deininitialize_registers();
-    uacpi_deinitialize_tables();

 #ifndef UACPI_REDUCED_HARDWARE
     if (g_uacpi_rt_ctx.was_in_legacy_mode)
         uacpi_leave_acpi_mode();
+#endif
+
+    uacpi_deininitialize_registers();
+    uacpi_deinitialize_tables();
+
+#ifndef UACPI_REDUCED_HARDWARE
     if (g_uacpi_rt_ctx.global_lock_event)
         uacpi_kernel_free_event(g_uacpi_rt_ctx.global_lock_event);
     if (g_uacpi_rt_ctx.global_lock_spinlock)

@gentle peak is this how u fixed the pf?

#

@calm latch im updating the uacpi leaderboard, do u want to change your submission

#

managarm is down to 4th place

calm latch
#

With which score?

fiery turtle
#

u got like 8M yesterday

left orbit
#

wtf u taking that one?

fiery turtle
#

was it not legit?

left orbit
#

god knows lmao

fiery turtle
#

anyway im not unless mishakov submits it and its legal

left orbit
#

i got that only once

#

i have no idea if its reproducible

calm latch
#

This was consistent (?)

left orbit
#

i think i got 7m after that or smth

fiery turtle
#

current pmos score is 3M

calm latch
#

I'm trying to implement fast IPC on x86_64 atm

left orbit
calm latch
fiery turtle
#

right now

calm latch
#

Then use this

#

(Though maybe I'll have a larger one in a few hours)

left orbit
#

i'm happy to test :^)

fiery turtle
#

if its only a few hours i can wait

left orbit
#

yeah put pressure on him

fiery turtle
#

lol

left orbit
#

we need pmos fast ipc on x86_64

fiery turtle
#

inb4 gets less

left orbit
fiery turtle
left orbit
#

big

gentle peak
#

huge

left orbit
#

massive

fiery turtle
#

lol

fiery turtle
#

lmfao

#

ill publish 1.0.1 after the leaderboard update i think

#

and i should mention monkuous in release notes

#

for all the bug reports

calm latch
#

Somehow pushw was not doing what I was expecting

fiery turtle
#

just port your userspace to real mode

calm latch
#

too little memory

left orbit
#

damn that is some old ass uacpi

#

time to update this shi to 1.0

#

im on edc5e219eb7ccefcfc8d0618018fabd51e83444f to be exact

#

tree from may 2024

calm latch
#

Not a lot of diff on my PC...

#

@left orbit can you test? ultrameme

fiery turtle
calm latch
#

btw @fiery turtle

fiery turtle
#

Lol nice

vale isle
#

where's the uacpi benchmark

#

!!

calm latch
#

So I guess uACPI must be fully working to get EC events?

fiery turtle
#

Yeah

#

I read the init logs in the recording

#

It was successful

left orbit
#
[    0.000000] [CPU0] debug(uacpi): uacpi_kernel_acquire_mutex: mtx=0xffffa00000017001
[    0.000000] [CPU0] debug(uacpi): uacpi_kernel_acquire_mutex succeeded
[    0.000000] [CPU0] debug(uacpi): uacpi_kernel_release_mutex: mtx=0xffffa00000017001
[    0.000000] [CPU0] debug(uacpi): uacpi_kernel_release_mutex succeeded
[    0.000000] [CPU0] debug(uacpi): uacpi_kernel_acquire_mutex: mtx=0xffffa00000017004
[    0.000000] [CPU0] debug(uacpi): uacpi_kernel_acquire_mutex succeeded
[    0.000000] [CPU0] debug(uacpi): uacpi_kernel_acquire_mutex: mtx=0xffffa00000017004```
#

what is uacpi cooking there

#

why is it acquiring the same mutex twice

#

hmm it happens in uacpi_install_address_space_handler_with_flags

#

ah so my thread id magically switched, good to know meme

fiery turtle
#

lol

left orbit
#

i return 0 from both calls, hmm

fiery turtle
#

why does your mutex have an alignment of 1 is also curious

left orbit
#

it's a spinlock

#

lmao

fiery turtle
#

lol

left orbit
#

it's just an atomic boolean

fiery turtle
#

and this function is called one after another

#

like in a row

left orbit
#

am i allowed to return 0 from get_thread_id?

fiery turtle
#

yes

left orbit
#

hmm

fiery turtle
#

default thread_id_none is -1

left orbit
#

well okay so im looking at uacpi_recursive_lock_acquire

#

and i see it checks the lock owner id

#

i return 0 twice, first presumably when it locks it the first time

#

and then the 2nd time it shouldn't acquire it again

#

well, at least not by calling the kernel api

frank canopy
#

oh that reminds me i might be able to remove some extra checks in my various mutex and thread calls since i no longer do uacpi init before i start up multithreading

fiery turtle
#

mutex acquires now return a status

left orbit
#

nah i just rewrote like half of it

#

ohh

#

yeah im returning bool lol

#

thanks

fiery turtle
#

💀

left orbit
#

yeah that was it lmao

#

new record [ 0.000000] [CPU0] info(uacpi): successfully loaded 1 AML blob, 1708 ops in 0ms (avg 1708000000000/s)

#

(apparently i init uacpi before time keeping tf)

fiery turtle
#

uacpi is faster than native cpu

hollow elm
#

compile your kernel to aml for free speed benefits

fiery turtle
#

just wait for tomato's python to aml compiler

flat badge
#

Did somebody already port managarm to post 1.0?

fiery turtle
#

not yet

#

to my knowledge

left orbit
#

ok with tsc the zig kernel does 937090/s

#

not bad considering no optimizations

frank canopy
#

not bad

#

someday ill stop having irl things come up and fix my allocator crash so i can measure my zig kernel again

left orbit
#

crashes with ReleaseSafe meme

#

but not before showing me 10899947/s

#

idk how the fuck that happened but

#

¯_(ツ)_/¯

frank canopy
#

nice

left orbit
#

kinda beat proxima, except my mutexes are stubbed

frank canopy
left orbit
#

11050438/s pog

frank canopy
#

niiice

gentle peak
#

i have a whole folder of these lmao

fiery turtle
left orbit
gentle peak
#

how

#

this gets high 10M on my machine

left orbit
#

idk 😭

gentle peak
#

the proxima intel curse continues

left orbit
#

also mine isn't really no mutexes, it more like mutex = spinlock

gentle peak
#

ah

#

i don't have an equivalent build unfortunately

left orbit
#

yeah nw

fiery turtle
#

but no mutex should be faster

#

no?

gentle peak
#

apparently proxima-nomutex is slower than proxima with mutexes because i got the 10.27M result on iretq's cpu

left orbit
#

is 100000000 for tsc frequency correct?

#

or am i missing one zero

gentle peak
#

you can set it on qemu's command line

#

-cpu host,migratable=off,tsc-frequency=1000000000 means tsc = nanoseconds

calm latch
left orbit
#

yeah i was just asking about the tsc-frequency value

gentle peak
#

but if you don't pass that tsc-frequency flag it just uses whatever freq your host does

#

ah ok

left orbit
#

where does that value come from?

#

1000000000 i mean

gentle peak
#

the number of nanoseconds in a second

left orbit
#

ah

#

i was missing one zero :^(

#

so i am actually slow as balls

gentle peak
#

i was wondering lmao

left orbit
#

thank fuck

gentle peak
#

10M with absolutely no optimization and not really stubbed mutexes would've been crazy

left orbit
#

cuz if it was just that fast out of nowhere

#

yeah

#

but 1.1M sounds reasonable

#

especially with the slow as fuck zig GPA

gentle peak
#

definitely

fiery turtle
#

nooo

left orbit
#

also linked list pmm ☠️

#

I ZERO OUT ALL THE PHYSICAL MEMORY

#

ON ALLOCATION

#

wow

calm latch
#

I also do that

fiery turtle
#

UACPI_NATIVE_ALLOC_ZEROED

#

to not lose points

left orbit
#

zeroing out all physical memory you allocate is slow tho

mortal yoke
#

well its not really that slow

calm latch
#

it's what you have to do when you give memory to userspace

mortal yoke
#

like I tried to disable it on my kernel and the uacpi score didn't really change that much

fiery turtle
calm latch
#

also dlmalloc expects it from mmap

left orbit
gentle peak
#

if the flag is set don't zero

kind mantle
#

I only zero pages given to userland

calm latch
#

yeah but then you need to decide when to schedule that daemon, etc.

gentle peak
#

i mean

#

just have it as a regular kernel thread with low priority

left orbit
#

@calm latch i get the same score as with 32 bit pmos

kind mantle
#

IIRC there was a study at some point that concluded having a page zeroing daemon was actively detrimental to performance on modern CPUs.

left orbit
#

lmao

#

~4.1M

hollow elm
gentle peak
kind mantle
#

You're basically filling the cache with dead memory

gentle peak
#

yeah exactly

#

well good to know, i won't waste time implementing that then

kind mantle
#

BadgerOS just zeroes immediately before giving memory to userspace. The instructions to zero it out would be run anyway, so why do it in a way actively detrimental to performance?

mortal yoke
#

I wonder what if you'd use non-temporal stores tho

gentle peak
#

i imagine you could still slightly optimize it by keeping the flag but not the daemon, but yeah

mortal yoke
#

though ig it might still be better to just do that right when you allocate, idk

kind mantle
#

But I'm not sure how well those are actually supported by current CPUs.

mortal yoke
#

yeah idk I just know that the instruction exists for eg. sse2

gentle peak
#

if it's in sse2 that's eh, because on one hand it's guaranteed present on any x86_64 cpu, on the other hand you need simd in kernel

mortal yoke
#

you don't need simd

#

it uses normal regs

gentle peak
#

oh?

mortal yoke
#

movnti

gentle peak
#

ah yeah

kind mantle
#

I know that Linux doesn't actually immediately map pages for processes, only after the first time they access it. Perhaps that could be used to reduce the amount of pages actually zeroed and/or alloc'd at once.

gentle peak
#

i wonder how a page zero daemon with movnti would perform then

#

something i'll have to experiment with sometime ig

left orbit
#

pretty sure that linux also has a shared zero page that's mapped on read fault

#

and then on write it gets CoW'd again for a freshly allocated page that you can write to

#

i know NT does that for sure

kind mantle
#

That's even less zeroing required ahead of time.

left orbit
#

yeah, especially when you map a bunch of memory and read it but never write to it

gentle peak
#

doesn't that need tlb shootdown on the remap so that other cpus see the new phys addr?

#

like if one cpu writes to it, it gets remapped to a new page, and another cpu only ever reads from it

left orbit
#

probably, idk lol

kind mantle
#

To know that you'd have to know how Linux makes its VMM thread-safe.

#

But probably yes

calm latch
kind mantle
left orbit
#

idk, when you have sparsely used data structures in userspace

kind mantle
#

Also, userspace regularly asks for way more memory than it actually needs for the heap.

#

Most of which would be just parked in this not-in-use state.

calm latch
#

But then you (that's what I do) just allocate it on first access

calm latch
kind mantle
#

Would you rather shoot down a TLB a couple times, or poison your caches with a daemon?

calm latch
#

But one is not dependent on another

hollow elm
calm latch
#

But you don't want them zeroed out

hollow elm
#

fair

gentle peak
#

they're also usually not anonymous

hollow elm
#

i wonder if using some cache maintenance instruction tricks to quickly zero out a page after allocating it would be faster than just memcpy

kind mantle
#

Having actually created caches (not professionally though) and understanding how they generally work, I don't think a TLB shootdown is really very bad as long as you're not blocking waiting for those shootdowns to finish at the other CPUs.

hollow elm
#

aarch64 has instructions to explicitly zero out cache lines for a VA for example

calm latch
#

(block and wait that is, for stuff like mmap)

#

Remote shootdowns are a recent thing (?)

kind mantle
calm latch
hollow elm
#

or that shared the shot page

keen marsh
#

but going from ro -> rw is less restrictive so you don't have to do a smp shootdown

kind mantle
gentle peak
keen marsh
#

in the pf handler you can just call invlpg if any other core accesses it

calm latch
#

invlpg only invalidates the entry on the cpu that calls it

keen marsh
#

yeah but the tlb has either old page with ro or new page rw

kind mantle
gentle peak
#

cpu 1 reads from the page -> cpu 1 tlb is filled with the entry for the zero page -> cpu 0 writes to the page -> the ro page is cow'd to a different rw page -> cpu 1 doesn't see cpu 0's writes

calm latch
keen marsh
#

ah nvm

kind mantle
gentle peak
#

the mmap has already returned before any of this has occurred

#

that's the point

dense steppe
#

when going from ro → rw, you don't have to invlpg unless you change the backing physical page, for example because of COW unsharing (which is quite common in this situation)

kind mantle
#

You could check the PTE in the page fault handler and invalpg if it's less restrictive than the fault implies.

gentle peak
#

yes i'm not disputing that

calm latch
dense steppe
#

yea...

#

if you want total consistency, you essentially have to

  1. unmap the old page
  2. tlb shootdown the old page (yes, this must be done before step 3)
  3. map the new page
#

because of SMP races

calm latch
#

Do you have to unmap though?

#

if yes, then my shootdown code is broken bruh

gentle peak
# kind mantle This is just an atomicity problem, if this breaks a process then it's that proce...
static int *ptr;
static atomic_bool mapped;
static atomic_bool read_once;
static atomic_bool written;

// CPU 0
ptr = mmap(NULL, sizeof(int), PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS, 0, 0);
atomic_store(&mapped, true);
while (!atomic_load(&read_once)) __builtin_ia32_pause();
*ptr = 5; // the read-only shared zero page gets changed to a read-write allocated page
atomic_store(&written, true);

// CPU 1
while (!atomic_load(&mapped)) __builtin_ia32_pause();
int i = *ptr; // put entry for read-only shared zero page in tlb
atomic_store(&read_once, true);
while (!atomic_load(&written)) __builtin_ia32_pause();
int j = *ptr;
assert(i != j); // this can fail if you don't shootdown!
calm latch
kind mantle
gentle peak
#

ah i missed that

calm latch
dense steppe
#

yes. imagine 3 CPUs:

  • CPU1 writes to the page. This initiates the page fault, that maps the new page.
  • However, before the TLB shootdown has completed, CPU2 stores something to the page, which doesn't fault since it wasn't in CPU2's TLB.
  • CPU2 now does a release store to memory shared with CPU3.
  • CPU3 does an acquire load, sees the release store from CPU2, and thus reads from the page. But it reads from the old COWed page, because it was in CPU3's TLB.
    and thus, consistency is broken
gentle peak
#

often it's quite hard to make sure that the process you switch to shares the page though

dense steppe
dense steppe
kind mantle
#

In that case I assume you'd be sending an interrupt to all other CPUs to do a shootdown and wait for them to respond.

mortal yoke
# calm latch By hardware

its a relatively recent thing on x86 yeah, on other arches like aarch64 it has been a thing for a long time (armv8 has it)

dense steppe
#

most modern x86 CPUs should support remote TLB shootdowns via invlpgb iirc

#

TLB shootdowns are a hard problem

mortal yoke
#

that's amd only

dense steppe
#

wha

#

...

#

wtf

#

why?

kind mantle
#

Since we're talking about x86 paging, anyone mind helping me get that working? 😅
I have paging on RV64 working since forever but I can't seem to figure out what I'm doing wrong for x64.

calm latch
dense steppe
#

invlpgb doesn't exist on felixcloutier :L

kind mantle
#

The PTE format is different

#

And so are the semantics

mortal yoke
#

there is a different thing for intel but I am not sure if its supported on any consumer cpus so far

gentle peak
#

that'd be a problem yeah

mortal yoke
dense steppe
#

must should, maybe it is implied

gentle peak
#

implied from the ordering yeah

dense steppe
#

it could potentially also be if the kernel uses a sequential shootdown (ie. first shootdown CPU2, then CPU3, etc..) that leaves two other CPUs in inconsistent states for a short period of time

#

... I don't think that a shootdown is needed when COWing if there's only a single other CPU

#

but whenever a third CPU comes along, that's when the problems start

#

here are TLB shootdown statistics on a 16-core 2 threads per core Linux system with an uptime of eight hours

#

(my host right now)

slim panther
#

we are back on 4M

fiery turtle
#

letsgo

#

new leaderboards

kind mantle
#

lol

fiery turtle
#

lol

kind mantle
#

It's a meme PR don't worry about it too much

fiery turtle
#

if u move it to the bottom, change the message to Supports both 32-bit and 64-bit platforms and change the commit message to docs: advertise support for 32-bit *and* 64-bit ill merge it

kind mantle
#

lol sure

fiery turtle
#

lmfao

kind mantle
#

done

fiery turtle
#

forgot to add platforms at the end meme

kind mantle
#

actually done

fiery turtle
#

thanks lol

#

u removed fixes from the commit message btw

#

so it didnt auto close the issue

kind mantle
#

lol whoops

fiery turtle
#

lol

kind mantle
#

embed fail

fiery turtle
#

even embed failed lmao

kind mantle
#

The image explains all you need to know XD

fiery turtle
calm latch
#

u32 physical addresses are stupid

#

what about PAE

fiery turtle
#

yeah like u can support i686, but not supporting pae is stupid

kind mantle
#

I can't think of a platform off the top of my head that doesn't need more than 32 bits of paddr in the maximum configuration.

#

RV32 has 34 paddr bits. x86 has PAE. ARM probably also has more than 32 bits there.

fiery turtle
#

yeah

#

32-bit arm doesnt have acpi, lets start there LULW

north holly
#

What's haiku even used for

kind mantle
north holly
#

I should do something cursed and make m68k acpi tables

fiery turtle
#

acpi is little endian i think

#

or well, uacpi relies on little endian in some memcpies i know that for sure

gentle peak
#

All numeric values in ACPI-defined tables, blocks, and structures are always encoded in little endian format

#

the spec is basically worthless but it does say this

fiery turtle
#

ah cool

hollow elm
fiery turtle
#

i wonder if linux handles that

gentle peak
#

from what i've seen no

fiery turtle
#

i didnt see any endianness stuff in acpica

#

so it probably assumes le too

hollow elm
#

on linux iirc you need to change the kernel config for be aarch64

#

and for userland it's a separate target triple: aarch64be-linux-gnu

fiery turtle
#

no like what im wondering is if acpica e.g. reads multibyte integers correctly if its configured for big endian targets

hollow elm
#

yeah no i understand

#

i'm just saying that it's a kernel kconfig option

#

which might force off the acpi option?

fiery turtle
#

ACPICA has ACPI_BIG_ENDIAN

#

bruh wtf

#

couldnt they make it cleaner

#

ig thats one thing i should add to uacpi

kind mantle
fiery turtle
#

although the only target for that would be aarch64-be

hollow elm
#

hm was itanium big endian?

fiery turtle
#

nah lol

#

its LE ofc

hollow elm
#

im trying to figure out why acpica has be support in the first place

kind mantle
#

PDP endian support when? trl

fiery turtle
kind mantle
#

Technically, RISC-V allows implementations to change endianness (of data only, not instruction) at any time with a single bit in mstatus

#

AFAIK basically all RISC-V cores are LE only

heady pewter
#

isn't there a byte swap instruction in one of the extensions?

fiery turtle
kind mantle
#

Yes

fiery turtle
#

at least the commit is from that year

kind mantle
heady pewter
#

basically htonl()

kind mantle
#

It's a single instruction that does the endianness swap in htonl or nltoh, yes.

#

Actually it's ntohl. Whatever.

fiery turtle
#

anyone with an aarch64-be kernel here so I could test if i add support for it at least lol

mortal yoke
#

I mean I could probably add that just for the fun of it (well its actually kinda annoying and be is retarded meme)

kind mantle
#

Cringe endian

fiery turtle
#

yeah ngl its annoying af

#

id have to wrap everything

#

like all table fields accesses

kind mantle
#

Actually there's a GCC attribute for specifying a struct's endianness.

mortal yoke
#

idk if its really worth tbh

north holly
#

there's a GCC attribute for everything

fiery turtle
#

yeah idk

fiery turtle
kind mantle
#

ah

#

that won't help you then

fiery turtle
#

basically

kind mantle
#

MS tried the embrace, extend, extinguish once against GCC and is now allergic to adding anything beyond the C standard.

strong heath
#

microsoft tried to kill everything good at least once

fiery turtle
#

tbh i have some doubts about acpica support for big endian

#

i see it accesses table fields directly

#

like fadt.length etc

#

oh nvm

#

its not used by linux at all

#
❯  grep -rn ACPI_BIG_ENDIAN
drivers/acpi/acpica/acmacros.h:43:#ifdef ACPI_BIG_ENDIAN
#

OHHH

#

linux doesnt support ACPI on big endian aarch64

#

ok case closed then

#

im not adding it

kind mantle
#

Is that the only thing that selects ARCH_SUPPORTS_ACPI?

fiery turtle
#

does linux support big endian risc-v?

#

apparently not because im not seeing it

kind mantle
#

Maybe, idk.

fiery turtle
#

ok so:

  • x86 -> always LE
  • ARM -> ACPI is never enabled
  • ARM64 -> ACPI is only enabled if !BE
  • loongarch -> always LE
  • riscv -> no BE support(?) in linux
#

no other arch enables acpi

#

makes sense why this code bitrotted in acpica

kind mantle
#

Right.

#

I think it would be really cool if uACPI can get integrated into Linux (and maybe even mainlined because no ACPICA dev)

fiery turtle
#

i think so too but

#

there's so many files calling into acpica directly

#

and they won't accept full-on switch without it being configurable probably

#

so you have to make an abstraction layer

kind mantle
#

That would be one refactor and a half

fiery turtle
#

so it's a lot of years of work

#

yeah

mortal yoke
#

how many uses of acpica functions there actually are?

kind mantle
#

Oh well. At least you're completely dominant in hobby OSes meme

fiery turtle
#

basically every single file in drivers/acpi

#

so a lot

#

a few thousand probably

mortal yoke
#

there are 817 files in there

fiery turtle
#

i mean reactos is on their way, because nt architecture allows to easily replace it

#

haiku maybe

#

potentially bsds but less likely

fiery turtle
#

because it lives in there

kind mantle
#

You've also got everyone on your leaderboard there.

#

And BadgerOS in the future

fiery turtle
#

true true

#

will badger take the top spot

kind mantle
#

I dunno

fiery turtle
gentle peak
#

that's lower than i thought it'd be

kind mantle
#

I'm certainly going to run the benchmark but what I'll do next depends entirely on score.

mortal yoke
kind mantle
#

I'm not willing to make any changes that benefit the uACPI score but compromise the rest of the kernel though.

fiery turtle
kind mantle
#

So there won't be any mutexless BadgerOS builds

gentle peak
fiery turtle
#

to see how much it bottlenecks it

gentle peak
#

did it for fun

fiery turtle
#

lol

gentle peak
#

i mean that too but i was referencing the uacpi on linux in userspace thing

fiery turtle
#

how did you do it?

gentle peak
#

iopl() and mmap(/dev/mem) were the main ones

#

the rest was just easy

fiery turtle
#

daamn lol

fiery turtle
gentle peak
#

oh and for rsdp i did the "search every 16 byte boundary in ebda and bios rom" thing

fiery turtle
#

yeah that should work

gentle peak
fiery turtle
#

ah

gentle peak
#

just default compiler opts

fiery turtle
#

are you going to publish the source

#

this is pretty fun stuff lol

gentle peak
#

probably not because it's pretty shitty

fiery turtle
#

damn

gentle peak
#

doesn't use libc, just raw inline asm syscalls

kind mantle
gentle peak
#

for some reason mknod("/dev/mem", 0600, 0x101) failed with EEXIST but open("/dev/mem", O_RDWR | O_SYNC | O_NOFOLLOW) failed with ENOENT so i had to improvise and put things in /dev/laijfjga/mem

fiery turtle
#

did you do it to have some reference points to compare against your future microkernel?

gentle peak
#

yeah kinda

#

mostly just got the idea and i am powerless against my own curiosity

fiery turtle
#

lol

#

i wonder why its so slow tho

gentle peak
#

i yoinked the allocator from proxima and stubbed all the locks so it can't be that

fiery turtle
#

strange

#

what could be bottlenecking it?

kind mantle
gentle peak
#

if you mean that linux's own acpi stuff is intervening, def not since i compiled this kernel with CONFIG_ACPI=0

kind mantle
#

No I mean /dev/mem access in general.

gentle peak
#

don't think so

#

but maybe

#

hmm

#

hold on

fiery turtle
#

dev mem should just map those pages on fault probably

gentle peak
#

maybe it's this

kind mantle
#

Thaaaat is likely

#

That'll cause lots of overhead

gentle peak
#

depends on how it's implemented

fiery turtle
gentle peak
#

disabled it and it's the exact same perf

kind mantle
#

o

#

nvm den

fiery turtle
#

i think it only works at mmap time

#

on pf time it just maps the thing

gentle peak
#

/* Remap-pfn-range will mark the range VM_IO */

#

this sounds like it might be the problem

fiery turtle
#

Its all uncached?

#

Yeah that would destroy perf

kind mantle
#

No cache?

gentle peak
#

i also don't override libc but given that uacpi's builtin memcpy/memset beats the phd memcpy/memset when lto is involved that shouldn't be the issue

fiery turtle
#

Lmfao

#

Maybe uacpis memcpy was PhD afterall

gentle peak
fiery turtle
#

Lol thats pretty cool

#

Do u want to move this to uacpis org?

gentle peak
#

if you want to sure but i don't really see the point

#

most of the code is just like 200 lines of { STUB(); }

fiery turtle
#

Well idk, but very interesting project nonetheless

left orbit
#

now that i'm getting back into zig i should work on proper zig bindings

fiery turtle
calm latch
gentle peak
#

i could actually use my profiler on this since i have iopl for debugcon

#

yknow i just realized the bad perf might also be because i'm running this off of qemu vvfat

#

i should do the funny rerun it ten times thing

#

nope the later runs get 1.5M

gentle peak
#

it's useful if you don't have the patience to set up proper build stuff

gentle peak
#

i'm looking at this profiler data and there aren't any major smoking guns i can see

#

it all just seems like.. general slowness

#

i filtered it to just kernel api calls and the things they call and everything except map/unmap is faster than proxima

#

map/unmap are both only called once and in total contribute 8.5 microseconds, so that can't be it

#

it might really just be that linux maps stuff as uncacheable

dense steppe
#

I'm surprised that there aren't any ioctls or anything like that to request a different cache mode (although ioctls wouldn't map well to this)

gentle peak
#

oh nevermind it was a me skill issue

#

i removed O_SYNC from open("/dev/mem")

#

now it's 10M/s

#
uacpi[3] successfully loaded 1 AML blob, 1705 ops in 0ms (avg 5671913/s)
uacpi[3] successfully loaded 1 AML blob, 1705 ops in 0ms (avg 10093714/s)
uacpi[3] successfully loaded 1 AML blob, 1705 ops in 0ms (avg 10832549/s)
uacpi[3] successfully loaded 1 AML blob, 1705 ops in 0ms (avg 10885943/s)
uacpi[3] successfully loaded 1 AML blob, 1705 ops in 0ms (avg 9726239/s)
uacpi[3] successfully loaded 1 AML blob, 1705 ops in 0ms (avg 10588615/s)
uacpi[3] successfully loaded 1 AML blob, 1705 ops in 0ms (avg 10722730/s)
uacpi[3] successfully loaded 1 AML blob, 1705 ops in 0ms (avg 10740969/s)
uacpi[3] successfully loaded 1 AML blob, 1705 ops in 0ms (avg 9956146/s)
uacpi[3] successfully loaded 1 AML blob, 1705 ops in 0ms (avg 10806459/s)``` 10 iterations
dense steppe
gentle peak
#

apparently

#

i was looking through the /dev/mem source code and saw this

dense steppe
#

like... why?

#

ohh shit... I map memory as UC- in uacpi_kernel_map_memory

#

is that why I get so bad results lol?

#

(todo: test tomorrow)

gentle peak
#

probably LOL

#

on x86 you can get away with unconditional WB because of the MTRRs

#

on other arches you're supposed to scan the memory map

dense steppe
#

because probably AMD and Intel handle things differently with the caching mode the guest specifies

#

smh my head...

dense steppe
gentle peak
#

well this was the only thing i changed to fix it

#

so unless linux does more special stuff with O_SYNC /dev/mem, i don't know what else it could be

gentle peak
dense steppe
#

ahh

gentle peak
#

that has a significant impact on performance

gentle peak
dense steppe
#

and also different CPUs

#

damn. I really should implement the re-run it 10 times meme

gentle peak
#

it has a less significant impact in an actual kernel because there's no demand paging

#

but it helps yeah

dense steppe
#

you could also just mlockall ();

gentle peak
#

didn't help that much

#

first run is 6M vs 5M

dense steppe
#

L1d/L1i memes? or branch predictor memes?

gentle peak
#

who knows

dense steppe
#

just turn off the branch predictor and look only at L1d/L1i
trl

frank canopy
gentle peak
#

with -march=native -mtune=native (and without mlockall) i get 6.3M on my first run and consistent 11.5M on further runs

dense steppe
#

do you do SSE/AVX/whatever cool things the CPU supports?

gentle peak
#

i mean this is a linux usermode binary so yeah

dense steppe
#

do you do it in your record-holding kernel too?

gentle peak
#

i'm just compiling with -O3 -flto -ffreestanding -fno-stack-protector

gentle peak
#

i do have a build which does so

#

but that's not the one on the leaderboard

dense steppe
#

I 'only' use -O2 (because -O3 code is just fkin ugly)

frank canopy
#

might revisit that though

#

(tbh I kept getting tempted to do a full-scale port of uacpi to zig instead of just idiomatic bindings lmao)

gentle peak
# dense steppe (todo: test tomorrow)
diff --git a/acpi/osl.c b/acpi/osl.c
index 37abdfa..8fe8cae 100644
--- a/acpi/osl.c
+++ b/acpi/osl.c
@@ -187,7 +187,7 @@ void *
 uacpi_kernel_map (uacpi_phys_addr addr, uacpi_size len)
 {
     return vmap_phys ("uacpi_kernel_map", addr, len,
-            PAGE_KERNEL_DATA | PG_UC_MINUS);
+            PAGE_KERNEL_DATA);
 }
 
 void
[    0.111543] uACPI: successfully loaded 1 AML blob, 1702 ops in 0ms (avg 4393516/s)
#

before this patch: [ 0.112889] uACPI: successfully loaded 1 AML blob, 1702 ops in 1ms (avg 872106/s)

dense steppe
#

870k wtf

dense steppe
#

though it is interesting to know

gentle peak
#

oo nice

#

yeah it was mainly just as a comparison

dense steppe
#

I hope to atleast somewhat match the i7-13700K in terms of performance (~6.3M) on my CPU if I fix the caching mode stuff

gentle peak
#

you have a 7950X right? if so you probably will

dense steppe
#

X3D

gentle peak
#

ah

#

make sure to use taskset lol

dense steppe
#

so half the CPU cores are weird

#

:p

#

I just re-run it a bunch of times and filter out the outliers

vagrant hull
#

or are you just relying on Linux and hearsay?

north holly
#

linux does it

#

so he does it

vagrant hull
#

exactly

#

"the memory map" aka the EFI memory map

#

what if you're not even using that

#

you can have ACPI without UEFI

gentle peak
#

"you're supposed to" doesn't always mean there's a spec that says you should. in this case the ACPI spec says absolutely nothing about it, so the best you can do is scanning the memory map

#

as for situations where you don't have a memory map, if you can know the ranges of memory your pmm is allowed to manage you have enough information for the memory map scanning

fiery turtle
#

hearsay is how most of acpi works

calm latch
#

I also map all physical memory ad UC thonk

slim panther
#

is it normal for aml to spam the kernel with battery stuff

fiery turtle
#

who knows

#

you would never know

#

if it didnt log

#

how often does it spam

#

looks like it drops roughly 1000 per notify

#

so probably expected idk

slim panther
fiery turtle
#

yeah probably fine

#

id suspect a storm if there was an aml error in the logs, but this looks fine

#

but can always compile linux with printfs and see if it gets this as well

north hull
#

I finally got a real score but its worse than Nyaux

north holly
#

Submit it to move obos up the leaderboard

north hull
#

nahhhhh

#

I gotta get over 1mil

#

I dont understand how my slab got slower when I added cpu caches

#

💀

north holly
#

You see I would optimize my kernel

#

But it's just a bug cluster fuck of ugly code

north hull
#

lmaoi

#

speaking of, whats a good way of profiling my kernel

#

lol

north holly
#

Check pinned messages

north hull
#

lmao

#

thanks

north holly
#

If I had to guess

dense steppe
kind mantle
#

@fiery turtle How do I use that mode with reading ACPI tables but without interpreting AML?

gentle peak
#

uacpi_setup_early_table_access iirc

north holly
#

Or smth

#

Don't call any other uacpi init functions

gentle peak
#

early table access is guaranteed to only call log, map, and unmap

fiery turtle
#

haiku is migrating to uacpi

deft canopy
#

very big.

fiery turtle
wind fiber
#

YOOOOOO

kindred beacon
#

FOSDEM shilling worked ultrameme

wind fiber
#

WE SHILLED uACPI AT FOSDEM

torpid root
fiery turtle
#

Yeah it literally did lmao

#

Big shilling

#

Thanks a lot

#

Osdev gang at work

north holly
#

uACPI is just being based (as usual)

vagrant hull
#

amazing lol

#

i also shilled Limine to them but there ain't no way they are moving to that :^)

#

i did install the haiku Limine package on the demo laptop they had at their stand though so there's that

#

(actually electrode did because i had no idea how to use the haiku pkg manager lol)

surreal current
#

you have above average social skills for a foss maintainer

north holly
#

With how many times I have falsely reported a uacpi bug to infy when it was obos' fault, I agree

surreal current
#

all you did was be polite but i was literally expecting you to say something snarky like "excuse me? did you even read the code? of course there's 32 bit support. and even if there wasn't, send a patch instead of wasting my time with begging"

north holly
#

(I only found two real bugs)

surreal current
#

most foss guys seem to have the like rice-grain of power go to their heads instantly

north holly
#

Yeah

#

SerenityOS comes to mind when you say that

kind mantle
#

Finally integrating uACPI into BadgerOS and...
I honestly expected a #PF, not a #GP, if it was going to crash.

north holly
#

That address is the least canonical address I have seen for a while

kind mantle
#

That be look like an ASCII

north holly
#

Which means you have memory corruption

#

Gl;hf

north holly
#

For the stack trace

kind mantle
#

No it's just walking the stack frames left by the function calls

north holly
#

What about the line numbers??

kind mantle
#

This goes through an external filter that runs addr2line

north holly
#

Oh

#

Ok lol

kind mantle
#

It's very elegant for not having to actually parse the DWARF info while still having a useful backtrace

frank canopy
#

yeah its a sick tool

#

i need to get around to that for mine

#

though half the time my stack traces are off

#

(my stack walker is giving me return addresses so its always like off by an instruction i find)

kind mantle
#

Uhhhhh did I mess up my MMU code again or something?
If an address was going to not be canonical, it would be 0xffff000000001500 right?

#

I think that I made mmu_half_size twice as much as it should have been...

frank canopy
#

whats the actual instruction from a disassembly at that RIP address?

north holly
#

Or smth

frank canopy
#

gp fault can be many things

frank canopy
#

the address has to be sign-extended from the max width of whatever your paging setup is

#

but depending on instruction idk if R10 being not a canonical address matters

kind mantle
#

R10 is not involved.

frank canopy
#

could be a packed int of stuff

kind mantle
#

I checked the asm

north holly
#

Show

frank canopy
#

yeah exactly

kind mantle
#

This is the faulting insn

north holly
#

That shit is not canonical

kind mantle
#

As you can see, that is not a canonical addr

#

so off to fixing my mmu code I go

north holly
#

I missed that in your register dump

frank canopy
#

yep

north holly
#

Because 8 kinda looks like 0 in that font

frank canopy
#

i just cant read lol

north holly
#

Lul

north holly
#

Display name

frank canopy
north holly
#

lol

#

Anyway I go slep

#

The word I am thinking of means something like "good"

#

But it's a bit hard to translate

frank canopy
#

mhm

#

oh lol every once in a while i remember that someone managed to snipe issue #6502 for giving zig a 6502 compiler backend

north holly
#

Lol

north holly
frank canopy
#

ye

frank canopy
kind mantle
#

Is uacpi_kernel_io_map the one that expects to use x86 I/O ports (e.g. inb/outb)?

frank canopy
#

yep

#

most kernels implement it by just treating the out as a *u16 instead of a **void and passing the base directly through

kind mantle
#

And that's what I just did too

#

Unfortunately I still have some broken timekeeping so I don't know how long this actually took to run.

#

And now I am going the fuck to sleep

vale isle
fiery turtle
jaunty fox
#

pulkomandy is a big wheel over there

fiery turtle
#

nice

#

apparently they ported firefox

#

damn

slim panther
#

managram when

north holly
fiery turtle
#

just use kvm and make a msl

#

apparently something very convincing

kindred beacon
fiery turtle
#

fwiw i have a trivial bug fix pr that hasnt been looked at for a month meme

wind fiber
#

Also I’ll be doing some ironclad work soonish (I know, shocking) but it’s a good project and my assistance has been requested (well, more like asked info wanted to do that but whatever)

north holly
#

Year of the managarm desktop before Linux desktop??

wind fiber
#

Potentially. It depends. Xorg might not need to happen if systemd works and that solves my KDE issues

#

GNOME is a different beast, but I might’ve just discovered a funny I can do to debug that

jaunty fox
#

we all know what happened and for a time it looked like he had gone, then for a while longer like intel had quietly held onto him

north holly
leaden fox
kind mantle
#

@fiery turtle

[00001.342] INFO  successfully loaded 1 AML blob, 573 ops in 15ms (avg 36780/s)

I suck at this game KEKW

#

On an AMD Ryzen 5 3600

#

Oh wait that's not with -M q35 hang on

#

[00000.054] INFO successfully loaded 1 AML blob, 1705 ops in 1ms (avg 1018518/s)

#

Still not good lol

fiery turtle
#

Close to obos

frank canopy
#

not terrible either at least

kind mantle
#

Does anyone else have an ISO so I can compare on the same host CPU?

fiery turtle
#

Or send your ISO here

kind mantle
#

qemu-system-x86_64 -M q35,smm=off -accel kvm -drive format=raw,file=path/to/image.hdd -debugcon stdio -display none

#

I wonder if there's a way to profile this stuff.

gentle peak
#

pinned

fiery turtle
#

Yeah pinned messages has a nice profiling tool by monkuous

gentle peak
#

5800X

slim panther
#

if i made a microkernel, should i make uacpi run in kernel or in user mode

kind mantle
gentle peak
kind mantle
#

But proxima still does like 5M on my machine

slim panther
#

any pointers as to how to expose rsdp to user mode?

fiery turtle
#

Sometimes the answer is in the question KEKW

slim panther
#

i don't really want to have a syscall dedicated to do that

gentle peak
#

I just give user mode something similar to mb2 boot info + some handles and let it figure out the rest

#

as in it's state that's passed to init

mortal yoke
fiery turtle
#

See monkuous uacpi userspace linux port

mortal yoke
#

or something like that

slim panther
#

fair

gentle peak
#

So f.ex init on startup would get a handle to a memory object that lets you map any physical memory, and the info structure init gets also contains the physical address of RSDP

slim panther
#

ahhh

#

i'm stupid

#

i have bootinfo

#

i just need to pass it to init

fiery turtle
#

Didnt know you were making a microkernel too

#

Everyone is making one these days

kind mantle
#

@gentle peak where header file

gentle peak
#

Wdym

slim panther
#

i'm rewriting parts of it because i don't want to be that one gif electrode made

kind mantle
#

You only have the src for the profiler

slim panther
#

i also want to experiment with distributed systems potentially

gentle peak
#

The gist represents 3 files

kind mantle
#

I see

calm latch
#

What is I map all memory as normal? thonk

gentle peak
#

wdym

calm latch
#

I map uacpi_kernel_map as UC

#

(And all memory that's not malloced)

gentle peak
#

that destroys perf on amd

calm latch
#

Like on x86 MTRR should handle that anyway (?)

gentle peak
#

linux-uacpi went from 1.2M to 10M when i stopped mapping everything as UC

#

if you map everything as WB, MTRR will take care of things

#

if you map everything as UC, it'll override MTRR

calm latch
#

But I also have RISC-V memes

#

But I think it should have a similar mechanism

gentle peak
#

yeah for that your best bet is checking whether the memory is allocatable

#

ehh

#

not really

#

risc-v has PMA which is supposed to take care of that

#

in reality that's not how things work

#

for example, iirc on some chipsets you add a specific offset to the physical address to indicate cache mode

calm latch
slim panther
#

okay so with uACPI being in user mode, what's the best way to handle timers on x86_64 and aarch64?

gentle peak
#

have a table parser in kernel mode

slim panther
#

since i can't use the HPET table anymore

#

oh?

gentle peak
#

table parsing in kernel mode is basically required for timers on any modern acpi-based platform

vast kestrel
#

Wdym timers? Don't you just have sleep syscall?

slim panther
#

?

vast kestrel
#

Oh you mean the source for the kernel lol

gentle peak
#

luckily, table parsing is incredibly easy and the full thing can be done in <200 lines

torpid root
vast kestrel
#

Rdtsc + acpi timer tomatpray

slim panther
#

i mean sure, i just wanted to avoid code duplication

#

:(

torpid root
#

why do you have uacpi in userspace

#

for points?

gentle peak
#

microkernel

rustic compass
#

uACPI in kernel with only table stuff in barebone mode (or use lto until barebone mode is ready) and full uacpi in userspace

slim panther
#

then i need to restructure my submodules lol

gentle peak
#

i don't really see the point of using uacpi if you only need table parsing

slim panther
#

i mean i don't

gentle peak
#

even in the future barebones mode

slim panther
#

i just need the headers, right?

#

for the table structs

gentle peak
#

ah ig it can be helpful for that

#

i just reference the acpi spec

slim panther
#

i mean yes, that's what i did before

calm latch
#

I just assume PIT exists bruh

#

only breaks on monkuous' PC

vast kestrel
#

Tbf you don't even need that much stuff

#

Like, it's super static table

calm latch
gentle peak
vast kestrel
#

How do you calibrate em?

calm latch
#

Since RISC-V doesn't have global timers

calm latch
#

someone here had a PC without PIT

gentle peak
#

my kernel can use hpet, KVM timer, and TSC

calm latch
#

I plan on redoing the timer subsystem, and supporting everything

#

LAPIC, (deadline) TSC, PIT, HPET and ACPI

#

And also make kernel preemtable by timers

fiery turtle
#

just published the 1.0.1 release

strong heath
#

neat

north hull
#

@fiery turtle ```[INFO:UACPI] successfully loaded 1 AML blob, 1720 ops in 0ms (avg 1737654/s)

fiery turtle
#

Nice

#

Os link and short description as well

north hull
kind mantle
#

Can you add this one to the leaderboard too? (even though it sucks lol)

fiery turtle
#

Sure

#

Cpu and short description

kind mantle
#

Ryzen 5 3600

fiery turtle
north hull
#

Ig for description the best I can think of is Hybrid Unix-like kernel

#

lmao

#

aint nothing special about it

fiery turtle
#

No hurry im just queuing the changes for now

kind mantle
#

A monolithic lightweight UNIX clone

fiery turtle
#

You can edit the message later

fiery turtle
#

Lmfao

kind mantle
fiery turtle
#

There was one of these gifs that said monolithic Unix like kernel with limine or something like that

slim panther
#

@severe swift

left orbit
#

with limine and mlibc*

slim panther
#

^

north hull
#

💀

torpid root
fiery turtle
#

Lol

severe swift
left orbit
#

yessir

kind mantle
kind mantle
#

@fiery turtle Mutexes have fast path now, speed is now at 1.0M ops/s
[00000.054] INFO successfully loaded 1 AML blob, 1705 ops in 1ms (avg 1018518/s)

vagrant hull
#

@severe swift osdev slander 2 when

severe swift
#

I was gonna make another one at some point soon tho because I think we have enough meme material for one again

fiery turtle
fiery turtle
#

damn

#

haiku maintainers are fast