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

1 messages · Page 19 of 1

fiery turtle
#

Yeah

#

But I think the expensive cases are past the benchmark

#

Because all aml buffers have a corresponding size field etc

#

It’s mostly to do with e.g. generate_absolute_path(), or HID strings or similar

gentle peak
#

forgot to respond to this, it probably is because no code is ever truly optimal but i can't see how. maybe there's a better non-simd memcpy and memset than rep movsb and rep stosb? most other things are pretty much as fast as i can get them while also still being thread safe and having all the features i want

#

the one thing that comes to mind is PCI access (currently i scan all ECAM ranges for every UACPI access) but i don't think that gets called by uacpi during the benchmark

median crest
#

managarm phd memcpy meme

fiery turtle
#

Yeah I think its actually faster than rep

#

Although its in c++ lol

#

It does heavy unrolling which I guess really helps for small memcopies

gentle peak
fiery turtle
#

Which would give back some sort of a handle

gentle peak
#

that'd be nice yeah

fiery turtle
#

Same as all other current api

#

Perhaps I shall add that

gentle peak
#

is aml structured in a way that'd make that worthwhile? or would it amount to open+access+close for every pci op?

fiery turtle
#

Its only used for opregions so I can optimize this to open once actually

gentle peak
#

oh yeah then i think that'd be worth adding

fiery turtle
#

Yeah definitely

#

I wanted that for uapi anyway

#

Will add tomorrow I guess, I have a draft PR open for opregion rework

#

Anyways very based work today, thx iretq and monkuous LETSFUCKINGGOOOOOO

#

Im gonna go sleep now

#

Gn

gentle peak
#

gn

left orbit
#

gn

gentle peak
# fiery turtle But I think the expensive cases are past the benchmark

i tested it just in case and wow that made a much larger difference than i thought it would.

  • unsized frees, kfree gives empty pages back to pmm, page size is 4k: 4 582 951/s
  • unsized frees, kfree gives empty pages back to pmm, page size is 16k (this is what's currently on github): 4 781 911/s
  • unsized frees, kfree keeps empty pages, page size is 4k: 4 830 247/s
  • unsized frees, kfree keeps empty pages, page size is 16k: 5 090 935/s
  • sized frees, kfree gives empty pages back to pmm, page size is 4k: 4 996 014/s
  • sized frees, kfree gives empty pages back to pmm, page size is 16k (this is what's going to be on github): 5 163 677/s
  • sized frees, kfree keeps empty pages, page size is 4k: 5 112 014/s
  • sized frees, kfree keeps empty pages, page size is 16k: 5 379 635/s
#

alright i pushed the change and updated the benchmark message

torpid root
#

I just remembered that my pmm memsets memory too

#

could've gotten a few more points

median crest
#

Rewrite whole kernel for 1000 more points on a fake spreadsheet

#

Do it

torpid root
#

yes sir

rustic compass
#

Also take qemu and underlying hardware characteristics into account to perfectly optimize for your stack

torpid root
#

hmmm could anyone test this? I don't think much has improved though

qemu-system-x86_64 -serial stdio -m 512M -cpu max,migratable=off,+hypervisor,+invtsc,+tsc-deadline -M q35 -accel kvm -cdrom image-x86_64.iso
gentle peak
#

1359972/s

torpid root
#

I get 1.5mil

#

same as before

left orbit
#

i love how this has turned into a competition and it totally dragged everyone away from actually working on their kernels

torpid root
#

technically we are still working on kernels and trying to make them faster

left orbit
#

i don't count hyperoptimizing your mem* and uacpi kernel api as actual work tho tf

fiery turtle
#

so its a useful optimization

left orbit
#

yeah yeah but it usually doesn't make a big difference

#

or, well, shouldn't

fiery turtle
#

who knows

left orbit
#

but yeah any work is useful work of course!

fiery turtle
#

no one did a generalized benchmark before meme

left orbit
#

maybe we could do actual profiling when we replace acpica in linux

#

i know linux can do pgo

#

so there must be a good way to profile it

fiery turtle
#

yeah

#

btw did you finish that branch work?

left orbit
#

better way than sampling rip outside of qemu lol

fiery turtle
#

true

left orbit
#

yeah as far as implementing kernel api and initializing it goes

#

i did a submodule + link from drivers/acpi/uacpi/source to ../../../uacpi/source

fiery turtle
left orbit
#

yooo

#

i shall make a pr

fiery turtle
#

lol

#

pls do

left orbit
#

oh god i have to fork it now too lmaoo

#

how long did this take to fork? meme

fiery turtle
#

1 sec

left orbit
#

oh wtf

fiery turtle
#

yeah it's a lazy copy i guess

left orbit
#

its a gigantic repo

#

probably yeah makes sense

#
hacker@raptor:~/sources/linux$ git fetch uacpi master
error: cannot run ssh: No such file or directory
fatal: unable to fork```
#

what the fuck

#

HOW DO I NOT HAVE SSH

fiery turtle
#

lmao

fiery turtle
#

should the upper one be removed?

left orbit
#

nope

#

the upper one contains uacpi_libc.h

#

and types i think

fiery turtle
#

ah

left orbit
#

and the lower one is the actual uacpi submodule

#

its a bit uhh

#

i didnt know how to properly organize it

#

but this keeps most of the actual uacpi stuff under drivers/acpi/uacpi

#

except for the submodule

gentle peak
left orbit
#

i think submodule at the top level makes sense

#

i dont think so lol

left orbit
#

actually hold on ill see if there isnt a better place for this

fiery turtle
#

but idk the right way

gentle peak
#

looking at /include, it seems it might be, because headers for all drivers are there

left orbit
#

so symlink uacpi/include/uacpi -> include/uacpi?

#

i guess

#

and put the two uacpi headers there maybe meme

fiery turtle
#

makes sense

#

acpica includes are there

#

i think?

left orbit
#

acpi/*.h

#

yeah

fiery turtle
#

ye

left orbit
#

do i just put uacpi_{types,libc}.h in include/?

median crest
fiery turtle
#

I guess

median crest
#

Once I swtich over I can probably break 4 mil on qwincis computer

fiery turtle
#

i wonder if linux semaphores are just crap

gentle peak
#

i used linux's normal mutex type and i believe my result was similar to iretq's

#

so i doubt it's due to the semaphores

fiery turtle
#

ah

#

then yeah

left orbit
#

ok building again

gentle peak
left orbit
#

@fiery turtle pushed, should be better now

fiery turtle
#

big

left orbit
#

next step is probaly putting it behind a config option

#

also, do you want to replace acpica completely or make it an option to choose between these two?

fiery turtle
#

aight merged

left orbit
#

lfg

fiery turtle
median crest
#

2025 will be the year of the uacpi desktop

left orbit
#

doesn it?

fiery turtle
#

so only full replace is realistic

left orbit
#

i thought drivers/acpi was a wrapper around acpica

fiery turtle
#

its acpi-specific drivers that all work on top of direct calls to acpica api

left orbit
#

oh ew

fiery turtle
#

yeah

#

e.g. ec.c or battery.c or button.c etc

left orbit
#

yeah i guess replacing it then is the only sensible option

fiery turtle
#

think so

gentle peak
#

huh, when i compile proxima with -march=native -mtune=native i get a KVM emulation failure

#

that's unexpected

left orbit
#

classic kvm error

gentle peak
#

yeah

fiery turtle
#

hmm

gentle peak
#

and if i didn't i would've expected #UD instead of an emulation failure

fiery turtle
#

depends

#

there are probably edge cases that cause a kvm error

#

like setting some msr bits that dont exist

#

idk

gentle peak
#

rip points to bextr %eax,0x10(%r12,%rbx,1),%edx

flat badge
#

this can be caused by e.g. instructions that KVM cannot emulate doing MMIO

gentle peak
#

oh

#

let me check what that's pointing to

fiery turtle
#

O3 doing funny stuff?

gentle peak
#

it's using bextr on io apic registers

#

that'd explain it

calm latch
fiery turtle
#

do u have special compile flags that cause that?

fiery turtle
gentle peak
#

don't think so, my flags are just -march=native -mtune=native -O3 -DNDEBUG -std=gnu11 -flto=thin -fno-common -Wall -Wextra -ffreestanding -fno-pie -fno-stack-check -fno-stack-protector -mcmodel=kernel -mgeneral-regs-only -mno-red-zone

fiery turtle
#

yeah thats probably why linux always does O2

#

O3 is not tested nor supported

calm latch
flat badge
#

you should access MMIO through inline assembly helpers

#

to avoid this

gentle peak
#

yeah i'll probably do that

fiery turtle
#

in your kernel?

flat badge
#

yeah

#

that's what linux + managarm do as well

fiery turtle
#

oh i completely missed that it was proxima dying lol

#

i thought it was linux

fiery turtle
#

there isnt assembly there

#

or well on x86 it does actually

#

my bad

#
#define build_mmio_read(name, size, type, reg, barrier) \
static inline type name(const volatile void __iomem *addr) \
{ type ret; asm volatile("mov" size " %1,%0":reg (ret) \
:"m" (*(volatile type __force *)addr) barrier); return ret; }

#define build_mmio_write(name, size, type, reg, barrier) \
static inline void name(type val, volatile void __iomem *addr) \
{ asm volatile("mov" size " %0,%1": :reg (val), \
"m" (*(volatile type __force *)addr) barrier); }

build_mmio_read(readb, "b", unsigned char, "=q", :"memory")
build_mmio_read(readw, "w", unsigned short, "=r", :"memory")
build_mmio_read(readl, "l", unsigned int, "=r", :"memory")

build_mmio_read(__readb, "b", unsigned char, "=q", )
build_mmio_read(__readw, "w", unsigned short, "=r", )
build_mmio_read(__readl, "l", unsigned int, "=r", )

build_mmio_write(writeb, "b", unsigned char, "q", :"memory")
build_mmio_write(writew, "w", unsigned short, "r", :"memory")
build_mmio_write(writel, "l", unsigned int, "r", :"memory")

build_mmio_write(__writeb, "b", unsigned char, "q", )
build_mmio_write(__writew, "w", unsigned short, "r", )
build_mmio_write(__writel, "l", unsigned int, "r", )
#

idk what the switch was for i cant find it

gentle peak
#

this should probably be made into a kernel api then

left orbit
#

it used to be

flat badge
#

or it should use inline asm within uacpi

left orbit
#

uacpi would have to provide inline assembly for all platforms

#

and i think thats what infy doesn't want to do

fiery turtle
#

^

#

but also i think this should be fine?

flat badge
median crest
#

Only 2 real platforms exist anyways anything else is mental illness

flat badge
#

*3 meme

median crest
#

Which platforms I mean is left as an exercise to the reader

gentle peak
fiery turtle
flat badge
#

fwiw i don't think volatile guarantees that the compiler doesn't use insane access modes that the memory controller doesn't support

flat badge
#

for MMIO

#

volatile is fine if you know it's backed by RAM

fiery turtle
left orbit
#

no riscv?

gentle peak
#

uacpi itself is completely platform independent, no?

fiery turtle
#

riscv yeah

slim panther
#

based

fiery turtle
#

so im definitely not adding arch specific stuff tehre

#

its not aware of what arch its executing on

flat badge
#

then i'd suggest to turn this into a kernel API

fiery turtle
#

perhaps yeah

#

that works on a virtual address

gentle peak
#

maybe you can make it a weakly linked kernel api and provide a default impl that does volatile?

fiery turtle
#

uacpi_kernel_system_memory_read

gentle peak
#

then again it's not a particularly hard kernel api to implement

fiery turtle
#

most osses will just do this volatile switch

#

so probably fine to have a default

#

idk

left orbit
#

@fiery turtle whats next for uacpi-linux?

gentle peak
#

anyway proxima now only uses volatile pointers for framebuffer and uacpi so that's nice

fiery turtle
#

first probably bus.c and more important drivers

#

i guess im doing the thing that korona suggested now

#

every read and write, be it io, pci, or mem is done on a previously mapped handle instead of directly

#

in case of virtual memory ofc the handle is expected to be the actual virtual address tho

#

for non-aml io

#

like tables etc

gentle peak
#

makes sense

fiery turtle
#

whether im adding defaults for memory r/w im not sure yet

#

probably yes

gentle peak
#

oh wow the -march=native -mtune=native actually had a noticeable impact on speed, i didn't expect that (5.1M/s -> 5.3M/s)

fiery turtle
#

because it works everywhere atm

left orbit
#

ok i guess i'll take a look at drivers/acpi/*.c then

fiery turtle
#

damn you're actually doing it?

#

nice

left orbit
#

converting driver code sounds like pain

#

i mean i'm not sure what i'll do but i'll take a look at the very least

fiery turtle
#

its mostly convert acpi_x to uacpi_x

#

some are literally like that, some are harder probably

left orbit
#

converting the types everywhere is gonna be fun

#

but yeah i see what you mean

#

its mostly just tedious work

fiery turtle
#

yup

#

but careful so its annoying

#

also they have patterns where they create an object on the stack then shove it into a method as an argument

#

thats just not something u can do safely

flat badge
#

Can't you make a acpica compat lib on top of uacpi?

fiery turtle
#

you can of course, technically

#

it would be very slow and insane

#

like implementing dx12 in terms of vulkan

#

every struct would have to be converted, a lot of hidden allocations, etc

#

i dont think an abomination like that would be upstreamable ever

#

thats why e.g. NT draws the line of abstraction higher

#

so it expects acpi.sys to export more higher level helpers, that don't have shit like eval_aml()

gentle peak
#

oh wow that quality is terrible wtf

#

whatever

fiery turtle
#

can I have your blob

left orbit
#

lmao

gentle peak
#

what's the command for that again

fiery turtle
#

acpidump > dump.txt

fiery turtle
calm latch
#

try pmos risc

fiery turtle
#

so far this looks bogus af lol

#

like a handler was uninstalled midway

#
switch (event->handler_type) {
case GPE_HANDLER_TYPE_AML_HANDLER: {
    uacpi_object *method_obj;

    method_obj = uacpi_namespace_node_get_object_typed(
        event->aml_handler, UACPI_OBJECT_METHOD_BIT
    );
    if (uacpi_unlikely(method_obj == UACPI_NULL)) {
        uacpi_error("GPE(%02X) AML handler gone\n", event->idx);
        break;
#

like i cant even imagine how to trigger this error

gentle peak
gentle peak
fiery turtle
#

very interesting

#

can u try pmos real quick as well?

gentle peak
#

what's the repo for that so i can compile it

fiery turtle
#

there's an iso

#

@calm latch can u link it real quick

fiery turtle
#

no i mean the iso lol

calm latch
#

#1236769772805554206 message

fiery turtle
#

i wonder whose bug it is LULW

gentle peak
fiery turtle
#

inb4 some uacpi skill issue again

fiery turtle
calm latch
#

Does it turn off if you press power button?

#

After 3 seconds

gentle peak
#

let me try

#

yes

fiery turtle
gentle peak
#

what the fuck

fiery turtle
#

this is why u dont make a recursive aml interpreter

#

this is all encoded as part of 1 opcode

gentle peak
#

i wonder if the issue is fixed if i add a power button handler

fiery turtle
#

probably, I still dont understand the AML handler gone thing

#

any way u can enable tracing as well?

gentle peak
#

yeah 2s

#

thats just uacpi_context_set_log_level before doing anything with uacpi right

fiery turtle
#

anywhere yeah

gentle peak
#

here should be fine

fiery turtle
#

sure

fiery turtle
gentle peak
#

right I'm gonna have to delay every print because this just scrolls past all useful info before it can be recorded

calm latch
gentle peak
#

and yeah idk what happened to the quality, it's fine locally on my phone so something happened during upload to discord

fiery turtle
# gentle peak it does

hmm so the GPE handler for _L02 does fire once, but then it just somehow gets corrupted

#

wait

#

fuck

#
--- a/source/event.c
+++ b/source/event.c
@@ -445,7 +445,6 @@ static void async_run_gpe_handler(uacpi_handle opaque)
                 uacpi_status_to_string(ret)
             );
         }
-        uacpi_object_unref(method_obj);

Can u do this real quick

fiery turtle
#

least insane AML

fiery turtle
#

u can try plugging/unplugging the charger and might see something

#

same goes for lid stuff

gentle peak
#

alright uploading the trace log on youtube now

fiery turtle
#

did u apply the patch?

gentle peak
fiery turtle
#

ah well

gentle peak
fiery turtle
#

the lid u can still open and close

#

i refactored something in a retarded way so it was a UAF at best

fiery turtle
gentle peak
#

the patch seems to have fixed it

#

each of those later ignoring firmware ... prints is one press of the power button

fiery turtle
#

what about the lid

gentle peak
#
uacpi: warn: ignoring firmware Notify(\_SB_.LID_, 0x80) request, no listeners
uacpi: warn: ignoring firmware Notify(\_SB_.VALZ, 0x8F) request, no listeners
uacpi: warn: ignoring firmware Notify(\_SB_.LID_, 0x80) request, no listeners
fiery turtle
#

oh damn

#

even lid works

#

0x80 is status change so its correct

#

if u hook up notifications to the lid device u can now detect when the lid is closed or opened

gentle peak
#

awesome

fiery turtle
#

but literally all events are disabled on init

#

i wonder if your firmware toggles it

#

lmao

gentle peak
#

wouldn't be surprised

#

it was made by firmware devs after all

fiery turtle
#

with that 100 conditions while i wouldnt be surprised

#

but its a cosmetic problem so whatever

#

in a real os you would ofc have a power button handler installed

#

(which is fixed event 2)

#

maybe they just havent tested with that event disabled lmao

#

so the firmware ignores the enable bit

gentle peak
#

maybe

#

but then why does the 2nd disable get respected

fiery turtle
#

maybe its not, usually there's a timeout between how often power button presses can be generated

#

as to not confuse the host os

#

if u wait a bit it might get fired again

#

but im glad you tested on your laptop, very few actually use this notification mechanism so it was barely tested

#

its an old one right?

gentle peak
fiery turtle
#

guess its my former guess then

gentle peak
fiery turtle
#

or maybe need to wait longer :^)

fiery turtle
#
        Device (VALZ)
        {
            Name (_HID, EisaId ("TOS6208"))  // _HID: Hardware ID
            Name (_DDN, "VALZeneral")  // _DDN: DOS Device Name
#

I wonder what this VALZ thing is that keeps getting notified

#

ACPI-COMPLIANT VALUE ADDED LOGICAL AND GENERAL PURPOSE DEVICE

#

proprietary chipset specific crap

calm latch
#

ACPI compliant == horribly proprietary and probably not compliant

fiery turtle
#

its so proprietary there isnt even a _CRS

#

so u have no idea what ports its using

gentle peak
#

huh, i just noticed, linux complains about the aml during init

ACPI Error: AE_NOT_FOUND, While resolving a named reference package element - \_SB_.PCI0.EHC1.HUB0.RMH0.PRT6 (20240827/dspkginit-438)

#

is this an acpica skill issue?

fiery turtle
#

lets see

#

TLDR: yes

#

it does nt incompatible things

gentle peak
fiery turtle
#

yeah pretty shitty firmware

#

does it power on correctly after uacpi shutdown?

gentle peak
#

yeah

fiery turtle
#

nice

fiery turtle
#

ill cherry pick the bug fixes & windows clang support i guess

#

since that opregion extension stuff is gonna take a while

fiery turtle
#

waiting for large tests to finish then ill merge

#

next on the list:

  • uacpi_kernel_pci_device_open
  • make pci r/w use the handle
  • optional uacpi_kernel_memory_{read/write}
  • new address space support
gentle peak
fiery turtle
#

Oh damn, really cool, thanks for improving the collection

#

how did you come up with these ids?

gentle peak
#

i think they were somewhere in the hw-probe output?

fiery turtle
#

ah

#

i think last people to submit these just did random numbers lol

gentle peak
#

yeah they're the value of HWid

fiery turtle
#

ah

fiery turtle
fiery turtle
north holly
fiery turtle
#

there's a huge difference

#

their purpose was performing io on a physical address

#

the new ones will be for MMIO abstraction

#

and they will have a default implementation

#

(and obviously work on virtual addresses instead)

north holly
fiery turtle
#

barely anything changed lol

north holly
#

reminder, this is obos

#

ok it boots on qmeu, I couldn't be bothered to test anything else atm

fiery turtle
#

@north holly thoughts on this aml

While ((GP50 || (GP51 || (GP52 || (GP53 || (GP54 || (
    GP55 || (GP56 || (GP57 || (GP60 || (GP61 || (GP62 || (GP63 || 
    (GP66 || (GP67 || (GP70 || (GP71 || (GP93 || (GP94 || (
    GPAP || (GPBP || (GPCP || (GPDP || (GPEP || (GPFP || (GPGP || 
    (GPHP || (FCDP || (FTVP || (FQSP || (GP96 || (GP97 || (
    GPD0 || (GPD1 || (GPD2 || (GPD3 || (GPD4 || (BPFE || (TPBP || 
    (ECDS || (B1ST || B2ST)))))))))))))))))))))))))))))))))))))))))
slim panther
#

fent

fiery turtle
#

if you make a recursive aml interpreter the call stack would be

parse_logical_or
parse_logical_or
parse_logical_or
..
parse_logical_or
parse_if
#

pretty confident this would exhaust any kernel stack

fiery turtle
north holly
#

exception thrown: ur aml is dogshit (so is your interpreter) and it caused your interpreter to stack overflow

north holly
fiery turtle
#

This is the person behind the rust ACPI crate

north holly
#

ah

fiery turtle
#

whats interesting is monkuous' hw also tells you the physical location of every xHCI port

north holly
#

yeah because that's obviously needed for power mangement

fiery turtle
#

lol

#

its nice for drawing diagrams in userspace etc

#

that extra integration

left orbit
fiery turtle
#

monkuous' laptop

left orbit
#

someone should lose their job for that

pine yew
#

if NT's interpreter was less resilient the firmware devs wouldn't be able to get away with that dogshit though

fiery turtle
#

true

pine yew
#

rewriting the rust crate is on my todo list after feb-ish

fiery turtle
#

big

dusky glade
#

i wanna die from this aml

#

thanks

fiery turtle
#
❯ grep -rni '= Timer' -l
Convertible/ASUSTek Computer/Q325/Q325UAR/7E4A9E65FDE9
Convertible/ASUSTek Computer/ZenBook/ZenBook UX563FD_UX563FD/4965BD15F4B6
Convertible/Dell/Latitude/Latitude 7400 2-in-1/5DA0C196CB26
Convertible/Hewlett-Packard/ENVY/ENVY x360 2-in-1 Laptop 15-ew0xxx/211A1085E85B
Convertible/Hewlett-Packard/ENVY/ENVY x360 Convertible 15-dr1xxx/6FE4CE9270F1
Convertible/Lenovo/Yoga/Yoga C640-13IML 81UE/91A793680B40
Notebook/ASUSTek Computer/ASUS/ASUS TUF Gaming F15 FX506HC_FX566HC/2418D4F13406
Notebook/ASUSTek Computer/VivoBook_ASUSLaptop/VivoBook_ASUSLaptop K6500ZE_K6500ZE/674A4C791E8B
Notebook/ASUSTek Computer/ZenBook/Zenbook UX5401ZAS_UX5401ZAS/297345551BD5
Notebook/Avell High Performance/A70/A70 MOB/16859F37F144
Notebook/Dell/Latitude/Latitude 5511/A37FB9368F2A
Notebook/Dell/Precision/Precision 3571/AD37470CEC0D
Notebook/Dell/Precision/Precision 7550/FE48AAC0D405
Notebook/Gigabyte Technology/AORUS/AORUS 15G KB/A7DC3F8318A8
Notebook/Hewlett-Packard/EliteBook/EliteBook 840 G7 Notebook PC/05F5CA53EEBB
Notebook/Hewlett-Packard/EliteBook/EliteBook 850 G8 Notebook PC/5BEFC8C16D82
Notebook/Hewlett-Packard/ENVY/ENVY Laptop 13-aq0xxx/A34009921DC1
Notebook/Hewlett-Packard/ZHAN/ZHAN 99 Mobile Workstation G1/CB1EEAC36F91
Notebook/HUAWEI/CREF-XX/CREF-XX/651E7E8E95D2
Notebook/Lenovo/IdeaPad/IdeaPad L340-15IRH Gaming 81LK/5B5E032BF08D
Notebook/Lenovo/Legion/Legion 7 16IAX7 82TD/23401686E604
Notebook/Lenovo/Legion/Legion Y540-15IRH-PG0 81SY/6658FB40979F
Notebook/Lenovo/Legion/Legion Y7000 81FW/814C5DAC1BEE
Notebook/Lenovo/ThinkPad/ThinkPad E15 Gen 2 20TD0005MH/188EB681251A
Notebook/Lenovo/ThinkPad/ThinkPad L15 Gen 2 20X4S27200/CCA34DA7A4E9
Notebook/Lenovo/ThinkPad/ThinkPad P1 Gen 4i 20Y4S0KS00/4012A98BFAA3
Notebook/Lenovo/ThinkPad/ThinkPad P15s Gen 2i 20W6001VUS/C49AF6F23385
Notebook/Lenovo/ThinkPad/ThinkPad T14s Gen 1 20T1S2WF00/35B0F227248A
Notebook/Lenovo/ThinkPad/ThinkPad T490s 20NX000DRT/14F305E2ED3B
Notebook/Lenovo/ThinkPad/ThinkPad X1 Carbon Gen 8 20UAS89500/282408B7FDEC
Notebook/Lenovo/ThinkPad/ThinkPad X1 Carbon Gen 9 20XW007YPB/C06A0E31B5D6
Notebook/Lenovo/Yoga/Yoga Slim 7 ProX 14IAH7 82TK/BD603C52BF3B
Notebook/Notebook/NLx0/NLx0MU/17E69D6CB4D0
Notebook/PC Specialist/NS50/NS50MU/30E58AFD506A
Notebook/Teclast/F15Plus/F15Plus 2/5D2F5E56BCAB
Notebook/Timi/RedmiBook/RedmiBook Pro 15S/3509D1F696E7
Tablet/Microsoft/Surface/Surface Pro 3/074C5C2E091B

Stats about AML u didnt care about

#

about 10% of blobs use TimerOp

#
Notebook/Dell/Precision/Precision 3571/AD37470CEC0D:103573:    Debug = Timer
Notebook/Dell/Precision/Precision 3571/AD37470CEC0D:103623:    Debug = Timer
Notebook/Dell/Precision/Precision 3571/AD37470CEC0D:139046:    Debug = Timer
Notebook/Dell/Precision/Precision 3571/AD37470CEC0D:139749:    Debug = Timer

Some literally spam it to stdout

rustic compass
#

@fiery turtle uacpi-rs builds now on uacpi master branch, you just gotta ignore the billion warnings meme

fiery turtle
#

lemme guess, the stupid uninitialized struct thing?

vale isle
#

wow linux w/uacpi is actually in the works now???

fiery turtle
#

it boots but there's still thousands of acpica api calls that must be changed

vale isle
#

omg

#

is there a repository

#

i can't believe this happened overnight

slim panther
#

wait what

#

linux uses acpica?

vale isle
#

i will have roughly 5 days of free time in the semester break

#

i would love to try uacpi linux on my hardware

#

and maybe fix a few bugs

hollow elm
slim panther
#

idk something in house

vale isle
fiery turtle
#

its not that big of a deal

#

all drivers are still calling into acpica

#

they work alongside

north holly
#

I wonder if uacpi linux will fix the bug where my friend's laptop starts smoking meme

vale isle
#

oh but that simply means the work was done way before this with uacpi's kernel api being similar to acpica i think

vale isle
fiery turtle
#

well if u give me the dump and errors i can tell u

vale isle
#

my dump is on the repo already

#

the errors are gibberish to me

fiery turtle
#

oh it is?

#

what are the errors

vale isle
#

i do not remember the errors at all

fiery turtle
#

ah sad

vale isle
#

will check when I'm on my laptop sometime in the next 3 montjs

#

if i don't forget

fiery turtle
#

btw linux scores 3rd on the performance leaderboard

#

behind managarm

#

or 4th

vale isle
#

wow that's interesting

#

what affects the performance btw?

#

other than hardware

#

locking and stuff?

#

and allocation

fiery turtle
#

yeah, locks, mem* functions, allocator performance

vale isle
#

ah

#

i would except linux to do better lol

fiery turtle
#

i think best we got out of it is 3.4M ops/s, whereas e.g. proxima gets 5.2M at peak

slim panther
#

turns out a complex project is not as fast as a really simple one

left orbit
#

thats what i was talking about yesterday 😅

#

it is still pretty fast though

vale isle
#

i have always wanted to host a build server

#

remind me in a year

#

to set up something

#

and benchmark homebrew oses

#

on every commit maybe

#

or every release if they do releases

fiery turtle
#

lol

#

sure thatd be cool

gentle peak
#

I got proxima to 5.398M by making my heap leak memory (ish, since new allocations can still use the "leaked" memory, it's just not returned by the pmm)

#

unfortunately I could not get it to 5.4M

left orbit
#

margin of error meme

#

5.4M it is

fiery turtle
#

lol

#

leaking memory is still kinda unfair tho lol

gentle peak
#

what I mean by "leaking memory" is pretty much the same thing most heaps do

#

most heaps never shrink and return memory to the os (pmm in this case), only ever expanding

#

that's what I mean here

fiery turtle
#

ah

gentle peak
#

but returning memory to the pmm is a property I'd really like to have, which is why I'm not removing the shrinking and why I'm not counting that result or submitting it for the leaderboard

fiery turtle
#

fair

rustic compass
flat badge
#

meme frigg outperforms linux, confirmed meme

fiery turtle
#

yeah frigg + phd memcpy do a solid job

median crest
#

Year of managarm desktop soon

kindred beacon
#

yes

left orbit
#

damn @fiery turtle i get a weird crash in uacpi and i'm not sure why, you think you could help me figure it out? i'm pretty out of date but i don't think that matters, i crash on interpreter.c:66 which is c DYNAMIC_ARRAY_WITH_INLINE_STORAGE_IMPL( op_context_array, struct op_context, static )

and the cr2 is 0x905cf which is even more confusing lol

fiery turtle
#

allocator corruption probably

left orbit
#

my uacpi_kernel_alloc returns addresses with hhdm applied

#

and it's a bump allocator

fiery turtle
#

alignment bug?

left orbit
#

size = align_up(size, alignof(max_align_t));

fiery turtle
#

OR

#

you applying some uacpi option only to some source files

left orbit
#

nah i apply it to the entire project

#

ill log my return values

#

from the kernel apis

fiery turtle
#

nyaux had a weird crash in dynamic array release was related to that

left orbit
#
kernel_c_args = [
  '-DUACPI_FORMATTED_LOGGING=1',
  # ...
#

unfortunately that ain't it

fiery turtle
#

logging is probably not related to that

left orbit
#

i hope my prints will reveal something

#

yeah i know

#

i'm just saying that i apply it project-wide

fiery turtle
#

ye

#

also if u have the entire backtrace that would be useful

#

and inspect the array state with gdb as well

left orbit
#

i don't do backtraces unfortunately, sorry

#

i'' hack that together if prints don't reveal anything

fiery turtle
#

just connect gdb lol

fiery turtle
left orbit
#

well prints don't really tell me much so i'll attach gdb

fiery turtle
#

is your bump allocator storage just a char array?

left orbit
#

nope

#

i allocate memory from my pmm

fiery turtle
#

ah

left orbit
#

ill try a static array

fiery turtle
#

one crash we had was because zig was adding extra alignment checks to c code lol

#

via some clang flags or whatever

left orbit
#

well i am using C so that shouldn't affect me meme

#

but i do compile using clang

fiery turtle
#

nah its not that, that was dying on a ud2

left orbit
#

ah i see

#

yeah zig likes to do that

#

also i think it might have been the allocator lol

#

using a static char array it gets much further it seems

#

slow as balls because i print in every kernel api

fiery turtle
#

how do u fuck up a bump allocator 💀

left orbit
#

?????????

#

IDK

fiery turtle
#

lmao

left orbit
#

maybe my memory manager is fucked up?

fiery turtle
#

oberrow had this problem as well in rewrite 22

left orbit
#

wouldn't be surprised

#

i never tested it properly

#

also uacpi is freeing lots of 0x0's

#

that normal?

fiery turtle
#

maybe you're returning some sort of reserved memory

#

yeah

#

its a no-op

left orbit
#

time to update

#

so i can get the cool thing

fiery turtle
#

wait uh

#

where are the numbers

left orbit
#

yeah im on an old commit

fiery turtle
#

damn, this is like really old

left orbit
#

yeahhh

#

20554599e65b3a98d1d77fa2a88b9af49815da5b

fiery turtle
left orbit
#

¯_(ツ)_/¯

fiery turtle
#

just fixed itself?

left orbit
#

im running with the shitty bump™️

#

and that works

#

so i'll investigate

#

but first uacpi update

fiery turtle
#

hmm

#

so like u did nothing and now it works?

left orbit
#

no no i replaced my "proper" bump with one that uses a static array

#

it's probably something funky going on with my memory mnaager

#

or maybe my bump just has some stupid bug lol

fiery turtle
#

ahh

#

show it meme

fiery turtle
#

yeah its definitely a pmm bug

#

logic lgtm

#

unless your align_up is bugged idk

left orbit
#

nah it's not

#

pmm bug but i will investigate in a little bit

#

currently fixing up kernel api

fiery turtle
#

i dont even know what changed since that commit

left orbit
#

no raw_io/mem_read/write

#

thats for sure

fiery turtle
#

btw u even have realloc, u actually use that api in the kernel?

left orbit
#

also ticks->ns ☠️

fiery turtle
#

💀

fiery turtle
#

linux has like 50 i think

#

in the entire kernel

#

compare to idk how many normal kmalloc calls

#

or no, 135 files vs 2684

left orbit
#
FACS 0x0000000007FE0000 00000040
successfully loaded 1 AML blob, 1705 ops in 6ms (avg 277825/s)
unable to install SCI interrupt handler: unimplemented```
#

wow that's shit

fiery turtle
#

hmm lol

#

well if thats with tcg

left orbit
#

nope kvm lmaoo

fiery turtle
#

💀

left orbit
#

half of the kernel api stubbed out

#

and it's still 270k

fiery turtle
#

literally how ☠️

left orbit
#

😃

fiery turtle
#

is your hhdm mapped cached?

left orbit
#

no optimizations

#

and uh i dont think so

fiery turtle
#

so uncached?

left orbit
#

but getting rid of assert(bump_offset + size <= PAGE_SIZE_L2); in alloc gets it up to 580k lol

gentle peak
#

is that built in debug mode or release mode

left orbit
#

im pretty sure debug

fiery turtle
#

ohh

#

well now do O2

left orbit
#

-O0 -g

#

yeaaa lmao

#

let me try

fiery turtle
#

inb4 6 mil

left orbit
#

triple faults

fiery turtle
#

lmao

left orbit
#
hacker@raptor:~/sources/osdev$ objdump -d build/kernel | grep -B 10 ffffffff8001c6cc
ffffffff8001c6c1 <_write_cr0>:
ffffffff8001c6c1:       0f 22 c7                mov    %rdi,%cr0
ffffffff8001c6c4:       c3                      ret

ffffffff8001c6c5 <_write_cr3>:
ffffffff8001c6c5:       0f 22 df                mov    %rdi,%cr3
ffffffff8001c6c8:       c3                      ret

ffffffff8001c6c9 <_write_cr4>:
ffffffff8001c6c9:       0f 22 e7                mov    %rdi,%cr4
ffffffff8001c6cc:       c3                      ret```
#

the crash rip points at the ret in _write_cr4

#

it's a pf with e=0000

#

how does writing to cr4 generate a page fault

fiery turtle
#

what did u do 💀

gentle peak
#

then the cr4 write probably changed the expected page table format

hollow elm
#

inb4 NX kernel .text

fiery turtle
left orbit
#

CR2=ffffffff8001c6cc

#

so the rip

fiery turtle
#

oh u either changed the PT format or NXed yourself

left orbit
#

but if i comment out the _write_cr4 at the end of init_cpu_features

#

it works?

fiery turtle
#

do u have uninitialized variables?

left orbit
#

nope

#

not that i know of

fiery turtle
#

and do u read it before updating

left orbit
#

this _write_cr4 is faulting

#

and it doesn't set any of these bits above, i checked

#

OH WOW IT'S TRYING TO WRITE 0

fiery turtle
#

hmm

left orbit
#

ok, so i print cr4 after reading it initially, after writing it the first time and before writing it the 2nd time

#

i get 0x20, 0x220 and 0x0??

#

that is some mad stack corruption i am smelling

fiery turtle
#

cpuid corrupting the stack?

left orbit
#

yueah

#

it actualy is

#
printf("before cpuid cr4: %llx\n", cr4);
_cpuid(0x7, 0, &cpuid);
printf("after cpuid cr4: %llx\n", cr4);
#
before cpuid cr4: 220
after cpuid cr4: 0```
#

that is crazy

fiery turtle
#

wait you arent preserving any regs there, are they all scratch?

left orbit
#

what the fuck am i looking at??????

#

WHAT IS THIS CFG

fiery turtle
#

lol

left orbit
#

i have a feeling debugoptimized with lto is not gonna be fun to debug

fiery turtle
#
2. Clobbering of %ebx: The cpuid instruction modifies the %eax, %ebx, %ecx, and %edx registers. If this code is expected to adhere to System V AMD64 ABI calling conventions, keep in mind that %rbx is a callee-saved register. If %rbx is used in the caller, it should be preserved. You might need to save and restore %rbx around the cpuid instruction.

Idk chat gpt said this

#

lmao

#

is this true?

left orbit
#

Functions preserve the registers rbx, rsp, rbp, r12, r13, r14, and r15; while rax, rdi, rsi, rdx, rcx, r8, r9, r10, r11 are scratch registers.

#

hmmm

#

i might be dumb

fiery turtle
#

looks like u should preserve it

left orbit
#

guess whose cr4 isn't getting corrupted anymore

#

(thank you)

fiery turtle
#

np lol

left orbit
#

successfully loaded 1 AML blob, 1705 ops in 0ms (avg 2418107/s)

#

yep as expected

fiery turtle
#

nice

left orbit
#

with half of the kernel api stubbed out

#

still worse than linux

#

crazy

fiery turtle
#

somehow 3 times slower than proxima with everything implemented

left orbit
#

probably due to "shitty" mem* functions

fiery turtle
#

oh yeah

fiery turtle
gentle peak
#

just tested, proxima with uacpi's builtin mem* funcs is 3.4M/s

left orbit
#

HOOOOOOOOOW

#

WHAT

#

successfully loaded 1 AML blob, 1705 ops in 0ms (avg 2884452/s)

#

with inline asm memcpy/memset

hollow elm
#

just need a fast cpu :^)

left orbit
#

successfully loaded 1 AML blob, 1705 ops in 0ms (avg 3045507/s)

#

random improvement because rerun

#

this largely assumes my time keeping is good™️

fiery turtle
fiery turtle
#

(I did)

gentle peak
#

(it is)

fiery turtle
gentle peak
fiery turtle
left orbit
#

ok when i initialize uacpi after i switch to and from a test thread that sleeps for 1s i get consistent 3.02M

gentle peak
#

mostly because calloc doesn't use uacpi builtins

fiery turtle
#

Maybe bump allocator is worse because cold cache

gentle peak
#

wtf?

fiery turtle
#

Uacpi has PhD memset

gentle peak
#

calling a function that uses rep stosb is apparently slower than calling uacpi builtin memset

#

probably due to LTO and clang turning it into PhD memset

fiery turtle
#

Lmao

gentle peak
#

because calling rep stosb can't be LTO'd since that's implemented in asm

fiery turtle
#

Makes sense

left orbit
#

i should implement it in assembly too

#

wait wdym it can't be LTOd

#

really?

fiery turtle
#

Whats needed to support LTO in a kernel

gentle peak
#

nothing

#

well, patience when compiling

#

and not having UB

#

but other than that nothing

fiery turtle
#

Hmm

median crest
#

I should try astral with it

left orbit
#

it's great

gentle peak
left orbit
#

uncovered the first bug in my kernel 👍

hollow elm
gentle peak
#

and that IR is turned into machine code by the linker which has global knowledge

gentle peak
#

assembly can't be turned into IR because that's already effectively machine code

left orbit
#

i thought it was some linker magic™️

fiery turtle
#

Wait so if I have standalone asm files I cant lto anything?

left orbit
#

well, it is, but not as magic as i thought meme

left orbit
hollow elm
gentle peak
#

that kinda thing

fiery turtle
#

Ah

#

Thats fine then

hollow elm
#

just like you can lto a program that calls a shared library function

gentle peak
#

oh btw

#

when building in debug mode (-O0 no LTO) proxima gets 1M/s

fiery turtle
#

Lmao

#

Still somehow 3x from iretq

left orbit
fiery turtle
#

Bump allocator fault

#

Every allocation is cold memory

gentle peak
#

the github source seems outdated but from what i'm seeing there the main slowdown might be that you implement things like pio and mmio in standalone asm files instead of with inline asm

median crest
#

That memory needs some empathy

left orbit
#
void*
alloc(size_t size)
{
   size = align_up(size, alignof(max_align_t));

   void* ptr = (void*)(bump_buffer + bump_offset);

   bump_offset += size;

   memset(ptr, 0, size);

   return ptr;
}```
left orbit
#

how can that be at fault :(

vast kestrel
#

I am pretty sure inline asm can be inlined

gentle peak
vast kestrel
#

Then don't :^)

#

Also something something small and unaligned buffers being slow with the string instructions on older machines

gentle peak
#

and if i make the allocator unconditionally zero memory it goes from 5.1M/s to 4.5M/s

#

if i do both it goes from 5.1M/s to 3.1M/s

#

so stuff like that is pretty significant

median crest
#

Bruh enabling lto in astral gives a missing popcount refence

#

Ill look into that in a bit

fiery turtle
#

I guess uacpi has a pattern of freeing and reallocating quickly

#

Which makes memory reuse fast

gentle peak
#

i wonder how fast it'd get if i made mutexes noops

#

6.4M/s

fiery turtle
#

Bruh

left orbit
#
.global memcpy
.type memcpy,"function"
memcpy:
   cld
   push %rdi
   mov %rdx, %rcx
   rep movsb
   pop %rax
   ret
.size memcpy, .-memcpy

.global memset
.type memset,"function"
memset:
   cld
   push %rdi
   mov %rdx, %rcx
   mov %sil, %al
   rep stosb
   pop %rax
   ret
.size memset, .-memset

anything wrong with these?

gentle peak
#

cld is unnecessary since sysv abi requires it upon function call

left orbit
#

fair

gentle peak
#

and the pushing can be replaced with copying to a scratch register that movsb/stosb don't touch

#

which removes an extra memory access

left orbit
#

perfect

#

but still, the semantics?

mortal yoke
#

you can just mov rdi to rax at the start

gentle peak
#

these are mine for reference ```
memcpy:
mov %rdi, %rax
mov %rdx, %rcx
rep movsb
ret

memset:
mov %rdi, %r8
mov %rsi, %rax
mov %rdx, %rcx
rep stosb
mov %r8, %rax
ret```

left orbit
#

i am getting weird uacpi errors

fiery turtle
#

You seem to know your optimizations chad

gentle peak
left orbit
#
FACS 0x0000000007FE0000 00000040
unable to lookup named object 'W1�N' within (or above) scope '\_SB_.PCI0': invalid AML name string
aborting table load due to previous error: invalid AML name string
    #0 in \()
failed to load 'DSDT' (OEM ID 'BOCHS ' OEM Table ID 'BXPC    '): invalid AML name string
loaded 1 AML blob in 7ms (1 error)```
#

like wha

hollow elm
#

W1�N yum

left orbit
#

bringing the old C versions of those functions makes it work again

#

ill try one at a time

fiery turtle
gentle peak
#

honestly idk

#

probably doesn't matter since the usages are via __builtin_X and the actual functions only get called if it wouldn't have been inlined anyway

#

i could try and see if it'd be better with inline asm

left orbit
#

lol it works now? wtf

fiery turtle
#

I wonder how the perf would change if every memcpy call is inlined to that asm

left orbit
#

OH FUCK ME I KNOW WHY

#

I WAS USING ; FOR COMMENTS

#

IN A GNU AS SOURCE FILE

#

😭

gentle peak
#

right now i also have memcmp implemented in ASM (though not using rep cmpsb ofc) and i wonder whether a C implementation of it would perform better

fiery turtle
left orbit
#

; is a semicolon

#

like in a C source file

#

// is a comment

fiery turtle
#

Oh

left orbit
#

so i had a bunch of random code "commented out" with semicolons

fiery turtle
#

Lol

median crest
#

lto does not like my pmm

#

wait I think it might be due to flanterm defining a memset too

#

idfk

gentle peak
north holly
#

Exactly The Same™️

gentle peak
# median crest

your memset prototype is incorrect. i don't think it matters in this case since the call convention doesn't change but value is supposed to be int not ulong

median crest
#

ah

#

how would you memset a region over 2gb tho

gentle peak
#

the size is still 64 bit

#

since it's size_t

#

value is supposed to be truncated to the lowest CHAR_BIT bits by the actual memset anyway

fiery turtle
median crest
#

Wait I had a brainfart nvm

#

Lmao

#

My guess from it dying that early is something relating to the memset and the page struct not being zero

dusky glade
#

💀

north holly
#

I don't believe I have ever fucked up a bump allocator

fiery turtle
#

U did I think

#

Id have to search for it

hollow elm
north holly
#

#1141057599584878645 message

#

found it

hollow elm
median crest
north holly
#

lol

fiery turtle
#

No I remembered u fucking it up lol

torpid root
dusky glade
kind mantle
#

what?

calm latch
median crest
#

what

fiery turtle
#
+#ifdef UACPI_NATIVE_CALLOC
 /*
  * Allocate a block of memory of 'count' * 'size' bytes.
  * The returned memory block is expected to be zero-filled.
  */
 void *uacpi_kernel_calloc(uacpi_size count, uacpi_size size);
+#endif

Fuck it

#

Less potential host bugs to worry about

#

i'll just have a default implementation in terms of alloc+memset

rustic compass
#

how about uacpi_kernel_calloc_zeroed? lets be honest, there will be at least one person who forgets to memset to zero otherwise (probably still at least 1 person even if its in the function name)

#

also is const uacpi_char *uacpi_status_to_string(uacpi_status); backed by a predefined list of names for all status variants?

#

found the big switch statement

#

not needing to cast c strings into rust strings makes it so much easier

left orbit
#

calloc by definition zeroes the memory

left orbit
#

also the comment says "The returned memory block is expected to be zero-filled."

#

if you don't read the comments it's your fault

#

:)

fiery turtle
#

like calloc is the classic C/posix api for zeroed allocation

#

so calloc_zeroed is kinda redundant lol

#

in hindsight i should've just called it alloc_zeroed of course

#

but i thought calloc was apparent enough

frank canopy
#

i only knew the zeroed part from the comment but im also coming from zig without much of a direct C background

#

but the comment was there so it was fine

fiery turtle
#

yeah my fault for assuming everyone knows C or has that background

frank canopy
#

imo that - in osdev especially - if people cant read the comments/docs thats their problem. maybe im just tired of fielding questions in other places from people who wont bother to read the intel x86 manual though

fiery turtle
#

fair i guess

fiery turtle
#

might just do this honestly

#

no api break for existing users as a bonus i guess

frank canopy
#

i think my calloc shim actually does something that im not 100% sure is required that a direct alloc(count * size) + memset wouldnt which is alignment

fiery turtle
#

does it do some special alignment tricks?

#

definitely not required by uacpi

frank canopy
#

calloc in theory requires fundamental alignment rather than arbitrary alignment

#

and im not sure if normal alloc does

fiery turtle
#

i think malloc is just guaranteed to return whatever the maximum alignment needed for fundamental types

#

which is enough for most cases

frank canopy
#

yeah i think same for calloc but i didnt see it in the malloc bit lol

left orbit
slim panther
#

macro

left orbit
#

fair

fiery turtle
#

yeah just ifdef

#
#ifndef UACPI_NATIVE_ALLOC_ZEROED
void *uacpi_kernel_alloc_zeroed(uacpi_size size)
{
    void *ptr;

    ptr = uacpi_kernel_alloc(size);
    if (uacpi_unlikely(ptr == UACPI_NULL))
        return ptr;

    uacpi_memzero(ptr, size);
    return ptr;
}
#endif
left orbit
#

could you maybe also add a uacpi_realloc kernel api that's optional? some allocators could make use of the fact some allocations can be resized without actually resizing but idk if it's worth the hassle

frank canopy
#

yep that might be nice if its ever used

left orbit
#

the only place it could really be used is dynamic_array but yeah

fiery turtle
#

Yeah it could be utilized by the dynamic array for sure

#

Wonder how many kernels have a realloc

frank canopy
#

i do

fiery turtle
#

(Here)

fiery turtle
median crest
left orbit
#

i will have one

fiery turtle
median crest
#

yeah but it just returns alloc(size * n)

fiery turtle
#

Whats the diff?

frank canopy
# fiery turtle Nice

well technically zig does - zig's std provides a general-purpose allocator that just needs a backing page allocator and which has a resize function, and then the zig std provides a general realloc based on resize (resize returns true if it could resize in place)

median crest
#

wait is that def not what I'm thinking

fiery turtle
#

Like calloc already allocates zeroed memory

#

Its just funny api because count and size

fiery turtle
#

Is it well suited for kernel use?

left orbit
#

it's basically what i implemented today

#

kinda slow

median crest
#

well add realloc because it would play very well with my allocator meme

fiery turtle
#

I guess scores might change if I add a realloc

left orbit
#

me give good idea

#

yay

median crest
#

I mean slab free and alloc is o(1)

fiery turtle
#

Dynamic array resize is what might be tanking some

median crest
#

at least on the small slabs in astral

left orbit
#

promixma about to snap 7M

frank canopy
# fiery turtle Is it well suited for kernel use?

its not the absolute most high-perf thing out there but its still very good. even lets you swap out the mutex type it uses for thread safety which i do for my kernel one. im not sure all the details of what exact scheme it does other than being bucket-based. also in releasesafe and debug it can automatically detect double frees and some leaks

fiery turtle
#

Lmao

#

Inb4 monkuous does some 4 line of code optimization for realloc that pumps out 10M/s

median crest
#

switching my mutex to a spinlock acquire like doubles performance so once I get a real lock I will be cooking

fiery turtle
#

Zig is cool ill try it once its more stable

left orbit
deft canopy
fiery turtle
#

Lmao

left orbit
#

im totally not salty

fiery turtle
#

What did they do

left orbit
#

they just do dumb things

#

change things that didn't need changing

deft canopy
frank canopy
# fiery turtle Nice

the zig generalpurposeallocator im using is used instead of malloc on basically every zig program that doesnt link libc or have more specific needs (theres also an arena allocator and object pools in the std that have the same backing allocator setup. even a fixed buffer allocator and a fixed buffer with fallback allocator for overflowing the buffer) - zig just links ntdll or does manual syscall stuff on linux to get pages allocated as needed

left orbit
#

var variables that aren't mutated are a compile time error, and unused variables are also errors which is definitely annoying

fiery turtle
#

Niice

left orbit
#

and you cannot turn that off lol

frank canopy
#

technically zig also has heapallocator for the windows heap api since thats in ntdll but most people just use generalpurposeallocator on top of the page allocator

fiery turtle
#

I also love zigs multiline strings, I haven't seen a language that does it better

frank canopy
#

tbh i like the unmutated var and unused const warnings

deft canopy
frank canopy
#

also comptime rules

left orbit
#

what is cool is you can use std.fmt.comptimePrint + asm :)

#

and you can literally write code that generates inline assembly

frank canopy
#

comptime being what if constexpr was taken to the extreme

fiery turtle
#

Yeah it's crazy

left orbit
#

if you ever do decide try zig out for a kernel project i am more than sure i'd contribute

fiery turtle
#

Also im biased because zig used spaces

frank canopy
left orbit
#

damn that is nice :^)

frank canopy
#

once we get @unrollArgumentTuple ill be really happy, rn ive got to implement it with a bit of a comptime mess

left orbit
#

i only used it for grabbing the cs offset from the iret frame to check if i need to swapgs

fiery turtle
#

Really cool

left orbit
#

never crossed my mind to generate the push/pops

frank canopy
#

and it uses sizeof and comptimePrint to figure out the rsp offset of the bottom of the struct for making the pointer before calling the actual handler

left orbit
#

just mov %rsp, %rdi tho

fiery turtle
#

I might give it a try for a cli app to get a feel for it

north holly
#

damn zig actually seems kinda cool

fiery turtle
#

Ikr

frank canopy
north holly
#

for a while I've thought of it as: oh some other dumb language, ignore

frank canopy
#

i was on the verge of learning c to do osdev when i found zig and decided to give it a go instead lmao

left orbit
#

you did not make a mistake

#

nooby made me learn osdev and zig at the same time

#

and it was so fun :^)

#

i miss old zig

frank canopy
frank canopy
left orbit
#

%gs/%fs will always be zero

fiery turtle
#

Zig freestanding: literal allocator
C++ freestanding: here's your stdint and fuck off, oh btw u have to implement initializer_list as well

frank canopy
#

yeah im planning to rework this and remove those lol

left orbit
#

sounds good

left orbit
frank canopy
#

yeah

left orbit
#

given you provide the necessary os things

north holly
left orbit
#

but if you provide a page allocator it's enough for like 60% of the std

left orbit
frank canopy
#

the ability to override the os bindings is a bit in flux rn sadly but not entirely

north holly
#

I love C

#

(send help)

left orbit
#

zig is C on steroids

frank canopy
#

they removed the ability to override all the io stuff temporarily while trying to figure out a better abstraction than just letting you override the posix functions

fiery turtle
#

I also like that its not forcing borrow checking or other stuff down your throat

frank canopy
#

yeah thats why i cant handle rust lol

north holly
#

rust is brainrot

frank canopy
#

borrow checker sounds cool but i cannot wrap my head around what it wants

fiery turtle
#

Apparently once you figure it out completely its good

#

But you need a PhD in language theory

frank canopy
#

one thing that i do thats kinda fucked up tbh but im still doing it anyway is that zig's std (and compiler_rt aka builtins) are, like everything else in zig, included as source instead of linking, so i literally have a fork of the zig std for my os that overrides stuff lmaoo

left orbit
#

ultra zig rewrite when 🙏

deft canopy
fiery turtle
#

I've heard it doesn't work well for long lived apps, but good for data processing like compilers etc

north holly
#

idk but I think kernels live for a long time

#

just a theory

left orbit
#

i feel like kernel stuff is inherently incompatible with the idea of rust

fiery turtle
#

Yeah perhaps

median crest
left orbit
#

sure you can write safe abstractions over kernel concepts

north holly
#

nyaux is a perfect example of a kernel that doesn't live long

left orbit
#

but it all needs to be unsafe lol

frank canopy
#

rn just to fix a bug that the pr hasnt been merged yet where the cryptographic rng doesnt use overridden getrandom if you tell it to always use getrandom instead of just for seed and then a prng, which bug means i need language threadlocals to work which isnt happening

fiery turtle
#

Its insane

north holly
#

nyauxmaster: ```diff
+1
-1

(10 hours debugging)
frank canopy
#

anyway back to trying to figure out unit tests for an avl tree because i decided to put vmm in my what to do next poll and suddenly i need a self-balancing tree

fiery turtle
#

OMG my brain couldn't handle rbtrees, like it did work in the end but I still barely understand it

north holly
#

I just copied bsd's sys/tree.h

#

ezpz

fiery turtle
#

Especially removing nodes

#

U have to recursively walk up and reconfigure it if there's a double black node

frank canopy
#

i found a c avl tree lib to copy but i also have to port it to zig in the process lol

#

zig has a treap in the std but its not intrusive so not really suited to my kernel work

fiery turtle
#

Yeah

#

Intrusive containers ftw

frank canopy
#

side note, @fieldParentPtr is goated in zig

fiery turtle
#

How hard is it to make a linked list in zig

fiery turtle
frank canopy
fiery turtle
#

Yeah container of is a based idea

frank canopy
#

takes a comptime string field name

fiery turtle
#

Does zig have reflection btw

left orbit
#

yeah

#

@typeInfo

fiery turtle
#

Big

left orbit
#

and @Type to create a type from type infoi