Probably also more work than just respecting the window 
#uACPI - a portable and easy-to-integrate ACPI implementation
flat badge
vast kestrel
Probably lol
loud ice
Probably also more work than just respecting the window <:meme:57544509458966121...
windowing needs async, though
flat badge
Not really, you can just block (in case of send)
Or busy poll your nic or whatever (in case of recv)
flat badge
you are allowed to do that
Well, sure, it will still work but it's also not hard to write it in a way that doesn't cause a ton of retransmission during normal operation
loud ice
hmm maybe
flat badge
A not entirely stupid minimal send would: block until window size > 0 -> send packet -> wait for ack
A minimal receive would receive packets up to an internal buffer size, then announce window = 0 and ack
That way you still don't need to deal with multiple in flight packets but you also won't randomly cause retransmission despite no packet loss
torpid ferry
that's still better than TFTP though
and probably even simpler
TFTP works Fine™️ on lans with very low packet loss, so it's probably fine for quite a lot of things
mortal yoke
TFTP works Fine™️ on lans with very low packet loss, so it's probably fine for q...
even on lans its slow af tho
loud ice
that's still better than TFTP though
nah its equivalent to base TFTP
except you have room to expand to better impls
fiery turtle
Gonna drop 30 commits when I merge this PR soon, which will mark the 1.0 release
not a single api break which is nice
north holly
fiery turtle
<:letsgo:1282155513156468747>
im likely not gonna change much here besides adding a few new AML tests, so if you're free to test right now (or some time soon) that would be nice
i've changed quite a lot of interpreter logic
north holly
I can test now, but whether I should is a different question (I'm at school)
north holly
nah I'm on my laptop
fiery turtle
ah lol
nah just test when you're back home with all of your pcs
im not in a rush anyway
these are the most dangerous potentially
but new special field handling might break something too
fiery turtle
fiery turtle
nice
fiery turtle
x2
fiery turtle
how tf did u test it in school
north holly
on a personal laptop
fiery turtle
what is it supposed to do?
north holly
what, waking from suspend?
fiery turtle
after
north holly
print it woke from suspend and return to bash
fiery turtle
in qemu?
north holly
yes
fiery turtle
try revertng and seeing if its an obos regression instead 
because qemu doesnt have a _WAK and i didnt change any other logic
north holly
lucky you infy
north holly
wonder where it works
fiery turtle
u mean hangs
fiery turtle
obos suspend regression #99999
north holly
except I haven't changed any acpi code 
fiery turtle
maybe your on_wake hook for some driver hangs
fiery turtle
fiery turtle
wtf
north holly
it was never calling into OBOS_Suspend
I was trying to fix a bug with receiving from the uart driver
so I made the powerctl command use getchar instead of my workaround
so I could test it
@fiery turtle yeah suspend worked
fiery turtle
letsgo
fiery turtle
at school? 💀
north holly
at school? 💀
infy we have a problem
it hangs
with new uacpi
I tested on the exact same commit of obos with old uacpi, it didn't hang
fiery turtle
we're gonna need some triple fault debugging
north holly
I tested on the exact same commit of obos with old uacpi, it didn't hang
**before suspend
fiery turtle
huh
north holly
it hangs before suspend
fiery turtle
so does it hang before or after
north holly
it hangs during kernel init, so before suspend
fiery turtle
that should be easy to printf at least
fiery turtle
yeah
fiery turtle
☠️
north holly
or it didn't hang in the first place and I misread my logs
it never hung
that's a compiler error 
gentle peak
that doesn't handle timeouts properly
north holly
Obos has never handled timeouts properly lol
median crest
Timeouts on locks are CRINGE
Do not respect them out of spite for the firmware devs
fiery turtle
yeah they are
median crest
Infiltrate microsoft and change the acpi driver to not handle them
fiery turtle
either 0 or infinite are the only respectable ones
median crest
Send a patch to linux to not handle them
Resist the oppression firmware devs do against os devs
north holly
Send a patch to netbsd
dense steppe
timeouts suck. they are annoying to implement and they should ideally never be hit.
but it is better to timeout than to deadlock forever.
btw... is it guaranteed that AML will release mutexes in the same thread that acquires them? because my mutexes make the following assumption:
* - The same task that holds a lock must unlock it.
yes
they're force released by uacpi upon method exit if aml forgets to do it
frank canopy
hm i should probably make sure i handle 0 timeout properly at some point
dense steppe
for me, a timeout of zero is just "optimistically try to acquire the mutex. if it fails, don't try again."
it's like the easiest part of a mutex implementation
frank canopy
it is I just don't remember if I bothered lmao
dense steppe
it is literally just:
/**
* Attempt fast mutex lock. Returns true on success, otherwise writes the value
* found in @mutex->owner_and_lock into *@expected.
*/
static inline bool
mutex_lock_fastpath (struct mutex *mutex, struct task *self, unsigned long *expected)
{
*expected = 0;
unsigned long desired = (unsigned long) self;
return atomic_cmpxchg_acqrel_acq (&mutex->owner_and_lock, expected, desired);
}
// ... later in the same file
/**
* Lock @mutex. Common part.
*/
static errno_t
mutex_lock_common (struct mutex *mutex, usecs_t timeout_us, bool interruptible)
{
struct task *self = get_current_task ();
unsigned int task_state = interruptible ? TASK_INTERRUPTIBLE : TASK_UNINTERRUPTIBLE;
unsigned long expected;
if (mutex_lock_fastpath (mutex, self, &expected))
return ESUCCESS;
if (!timeout_us)
return EAGAIN;
// ... invoke mutex slowpath
}
and my mutexes are overcomplicated
frank canopy
it is literally just:
```c
/**
* Attempt fast mutex lock. Returns true on succe...
yeah i know, i just again dont remember if i literally ever bothered when i was putting together my wait code
fiery turtle
Unrelated, but Im trying to make serenityos devs listen https://github.com/SerenityOS/serenity/pull/25653#issuecomment-2597828496
Doubt anyone is gonna care tho
mortal yoke
also cringe recursive parser
fiery turtle
also cringe recursive parser <:meme:575445094589661215>
I would expect no less from serenity
winter orbit
Unrelated, but Im trying to make serenityos devs listen https://github.com/Seren...
lol
torpid ferry
Unrelated, but Im trying to make serenityos devs listen https://github.com/Seren...
they will say to PR the code or shut up
fiery turtle
they will say to PR the code or shut up <:KEKW:913708372329644042>
Lmfao
winter orbit
i know of an easy to use ACPI implementation they can adopt
fiery turtle
They're fully nih I think
winter orbit
They're fully nih I think
bold to claim you're nih when you're copying *NIX/posix
mortal yoke
well at least its more nih than using existing code
fiery turtle
Lol
winter orbit
well at least its more nih than using existing code
i suppose
I've seen far more unique projects here though
mortal yoke
yeah there def are
left orbit
yeah well, serenity is just a bunch of people who have no idea how to osdev trying to osdev
winter orbit
most people are people who don't know how to osdev trying to osdev,
what matters is how much you're willing to learn from your mistakes 
everyone starts somewhere
But I don't have a lot of respect for serenity at this point
fiery turtle
But I don't have a lot of respect for serenity at this point
Thats the thing, they aren't trying to learn I guess, because every driver is like this acpi thing, only works on qemu, makes bogus assumptions, half unimplmemnted and barely tested
winter orbit
Yeah they've got some issues
mortal yoke
Thats the thing, they aren't trying to learn I guess, because every driver is li...
sounds like some of the drivers in my kernel 
I should go and fix them, particularly xhci because I tried fixing it at some point but then I just ended up making it worse
though to be fair I don't even have that many for actual real hardware, rtl8139/8169 (which works as long as the phy is properly handled by the fw), gicv3, spmi (incomplete and not properly hooked to anything), hda, xhci (like I said its kinda broken), usb hid (might be slightly broken idk) and usb rndis
mortal yoke
yeah
my xhci driver also mostly worked before I tried fixing it, the reason why I started to mess with it was an old mouse from like 2002 (3y older than me lol) generating a transaction error when getting the first 8 bytes of the device desc after first sending set addr with the bit set that prevents it from reaching the device (I tried with different packet sizes too like 8 and 64 but neither helped)
jaunty fox
bold to claim you're nih when you're copying *NIX/posix
what's odd is they don't seem to extend it in any significant way either
it's good to do posix since it's the open standard for operating systems but that doesn't mean that all innovations should be rejected
fiery turtle
what's odd is they don't seem to extend it in any significant way either
they support bsd stuff like W^X and unveil etc 
jaunty fox
they support bsd stuff like W^X and unveil etc <:LULW:543420553021882371>
none of the great stuff like capsicum, kqueue, jails though
strong heath
w^x is pretty good
left orbit
they do jails iirc
fiery turtle
also they disallow syscalls from everywhere but libc
jaunty fox
w^x is pretty good
it's trifling
strong heath
it's trifling
for sure
jaunty fox
they do jails iirc
you are apparently right so i accept i went too far in my condemnation
left orbit
idk how good or faithful their jail implementation is though
they also have a "syscall region" thing, which apparently comes from mach (but i might be wrong)
meaning any syscall made from outside that memory range won't work
jaunty fox
it's an openbsdism
deft canopy
they will say to PR the code or shut up <:KEKW:913708372329644042>
Did u know that actually all end users need to contribute code when they want a feature? Even when they arent a programmer, too!!!!
left orbit
that is fair though lol
i wouldn't want random people coming in and harassing me to add feature x or y
if u want it then do it urself
if it want it too then i might invest some time into it
deft canopy
i wouldn't want random people coming in and harassing me to add feature x or y
If a project is important enough, then this simply isnt acceptable
left orbit
boo hoo
deft canopy
In serentity's case it isnt that big, so meh
strong heath
its fair to say "hey would you be interested on implementing this yourself?", saying "either implement this or fuck off" is very heavy handed
left orbit
working together
jaunty fox
i wouldn't want random people coming in and harassing me to add feature x or y
with serenity i think it rubs people the wrong way because of their various claims like "Modern kernel"
deft canopy
its fair to say "hey would you be interested on implementing this yourself?", sa...
This would also be acceptable !!!
left orbit
with serenity i think it rubs people the wrong way because of their various clai...
yeah probably
im not a big fan of the hostility
jaunty fox
moreover there is a bit of a denial of the complexities of engineering big systems that's inherent to the logic of this response
left orbit
especially since its supposed to be semi professional
but like i dont blame them either
jaunty fox
for example, would serenityos say that someone should submit a PR to turn it into a microkernel?
strong heath
This would also be acceptable !!!
that is my personal approach, say when I would be able to do it, and offer fixing it yourself if I feel like the issuer could do it, as an option
jaunty fox
the same goes for a lot of other changes, there's no point pretending there's just blocks of code and you throw them into a PR and that's a change made
deft canopy
that is my personal approach, say when I would be able to do it, and offer fixin...
Ya, as long as people arent telling nonprogrammers to fuck off when they ask for smth as integral as accessibility features
jaunty fox
Ya, as long as people arent telling nonprogrammers to fuck off when they ask for...
god, that one's a bit worrying
though i accept that free software in general is a place where social responsibility is very lacking and that's visible in how little there is in the way of accessibility
in particular ever since Sun went away and since the advent of wayland, accessibility in the whole GNOME stack has gradually withered away to now being effectively unusable
loud ice
idk how good or faithful their jail implementation is though
probably bad
deft canopy
in particular ever since Sun went away and since the advent of wayland, accessib...
Recently there's been a big opportunity for me and my siblings to influence a company and its actions, so maybe eventually I'll be able to make the next sun, in terms of enforcing accessibility
I hope one day I'm big
So many ways I'd like to improve computing
fiery turtle
One last thing I decided to do before 1.0 is GAS caching, more specifically so that
- the entire GAS is mapped before its used as opposed to per-access-mapping
- for FADT registers, everything is pre-mapped at init time
uacpi_status uacpi_map_gas(const struct acpi_gas *gas, struct mapped_gas *out_mapped)
{
uacpi_status ret;
uacpi_u8 access_bit_width;
uacpi_size total_width;
ret = gas_validate(gas, &access_bit_width, &total_width);
if (ret != UACPI_STATUS_OK)
return ret;
out_mapped->access_bit_width = access_bit_width;
out_mapped->total_bit_width = total_width;
out_mapped->bit_offset = gas->register_bit_offset;
if (gas->address_space_id == UACPI_ADDRESS_SPACE_SYSTEM_MEMORY) {
out_mapped->mapping = uacpi_kernel_map(gas->address, total_width / 8);
if (uacpi_unlikely(out_mapped->mapping == UACPI_NULL))
return UACPI_STATUS_MAPPING_FAILED;
out_mapped->read = uacpi_system_memory_read;
out_mapped->write = uacpi_system_memory_write;
out_mapped->unmap = uacpi_kernel_unmap;
} else { // IO, validated by gas_validate above
ret = uacpi_kernel_io_map(gas->address, total_width / 8, &out_mapped->mapping);
if (uacpi_unlikely_error(ret))
return ret;
out_mapped->read = uacpi_kernel_io_read;
out_mapped->write = uacpi_kernel_io_write;
out_mapped->unmap = uacpi_kernel_io_unmap;
}
return UACPI_STATUS_OK;
}
I might make this public API as well tbh
/*
* Map a GAS for faster access in the future. The handle returned via
* 'out_mapped' must be freed & unmapped using uacpi_unmap_gas() when
* no longer needed.
*/
uacpi_status uacpi_map_gas(const struct acpi_gas *gas, uacpi_mapped_gas **out_mapped);
void uacpi_unmap_gas(uacpi_mapped_gas *);
/*
* Same as uacpi_gas_{read,write} but operates on a pre-mapped handle for faster
* access and/or ability to use in critical sections/irq contexts.
*/
uacpi_status uacpi_gas_read_mapped(const uacpi_mapped_gas *gas, uacpi_u64 *value);
uacpi_status uacpi_gas_write_mapped(const uacpi_mapped_gas *gas, uacpi_u64 value);
Something like this
loud ice
what is a GAS?
fiery turtle
what is a GAS?
fiery turtle
thanks to this, qualcomm engineers were able to put the reset register in EmbeddedControl address space 💀
fiery turtle
its just a memory region
its one register
loud ice
oh its one region in an address space
loud ice
thanks to this, qualcomm engineers were able to put the reset register in Embed...
i mean, that does make sense
resetting requires talking to the EC
loud ice
no smm on arm
fiery turtle
yeah
loud ice
it could also be part of 8042 emulation on x86
fiery turtle
EL3
loud ice
since at least on cros_ec it's routed to the EC as well
vast kestrel
no smm on arm
EL3 is actually stronger than SMM :^)
vast kestrel
Smm also has page tables
loud ice
page tables for the target system that is
vast kestrel
But with el3 you have per core timers and I think even interrupt redirection
You do?
vast kestrel
Nono I meant you do as in, i didn't know el3 had those
vast kestrel
Doesn't only el2 have those?
fiery turtle
bruh the 1.0 PR is getting huge
at 33 commits right now
but those are all very imporant changes id like to have before release
dense steppe
you could make it a 0.99 PR for people to test, and when that gives a satisfactory result, you do the actual 1.0 PR.
fiery turtle
you could make it a 0.99 PR for people to test, and when that gives a satisfacto...
ill have people test before merging ofc
vale isle
i love release candidates
fiery turtle
mandatory astral test
torpid root
bruh the 1.0 PR is getting huge
is the kernel api going to change?
kindred beacon
testing would be funni too
fiery turtle
indeed
median crest
mandatory astral test
how old is your commit for it to only be at 300k 😭
fiery turtle
very
commit e0f1fd3e031d6749472776c9a4b306aa3b8edb12 (origin/rewrite, origin/HEAD, rewrite)
Author: Matheus <[email protected]>
Date: Mon Oct 28 16:24:43 2024 -0300
tsc: fix it being broken when max base leaf < 0x15
dang
jaunty fox
```
commit e0f1fd3e031d6749472776c9a4b306aa3b8edb12 (origin/rewrite, origin/HEAD...
matheusuky
matheu suky
sukie bapswent confirmed???
vagrant hull
i won't stop yapping until everyone here accesses pci ecam via eax/ax/al only
fiery turtle
i won't stop yapping until everyone here accesses pci ecam via eax/ax/al only
Least insane amd requirement
rustic compass
what thats a requirement? even tho ecam is mmio?
fiery turtle
Yup
north holly
Least insane amd requirement
that's it
rustic compass
how do they even think they can enforce it when the cpu core only sees a memory write
north holly
char cpu_vendor[13] = {0};
memset(cpu_vendor, 0, 13);
__cpuid__(0, 0, nullptr, (uint32_t*)&cpu_vendor[0],(uint32_t*)&cpu_vendor[8], (uint32_t*)&cpu_vendor[4]);
if (memcmp(cpu_vendor, "AuthenticAMD", 12))
{
OBOS_Log("Fuck you AMD, OBOS is just gonna sit here and triple fault\n");
return;
}```
gentle peak
how do they even think they can enforce it when the cpu core only sees a memory ...
at least on modern CPUs it's not enforced
rustic compass
```c
char cpu_vendor[13] = {0};
memset(cpu_vendor, 0, 13);
__cpuid__(0, 0, nullp...
nah just map ecam as wb and flush the cache line after each write
gentle peak
but it's a good idea to follow the rule anyway
mortal yoke
why is it a thing anyway
gentle peak
who knows
mortal yoke
like what is the technical reasoning for it
rustic compass
but it's a good idea to follow the rule anyway
from the perspective of the cpu core its a memory read/write, the core itself cant know what is behind it, so it doesnt make sense
mortal yoke
though to be fair if its only like one old cpu then not like it really matters
north holly
what if just to tease them I use edx
gentle peak
yeah the rule doesn't make sense to me either but it exists and persists to this day so
not like it has a big impact
I highly doubt the codegen impact of requiring eax instead of any register is significant compared to the MMIO access itself
mortal yoke
or just don't care about it, its going to work just fine on the majority of cpus I am sure
gentle peak
valid
I implemented it anyways because it's not difficult at all
but at least on zen 3 it works perfectly fine if not using eax
rustic compass
just report to the user that his cpu is faulty
flat badge
I bet the technical reasoning is stupid
Maybe some SMM emulation expects it to behave that way
gentle peak
maybe
fiery turtle
TLDR always use legacy pci io and you're golden 
fiery turtle
whats a pcie
frank canopy
speaking of amd requirements I'm still mad that high level page tables can't have the global bit set on amd (its ignored on intel)
slow drift
speaking of amd requirements I'm still mad that high level page tables can't hav...
why does it matter
frank canopy
why does it matter
recursive page tables can't be global mappings
slow drift
can't you set the global bit only for the last pml?
i.e. PTE if you're only using 4KiB pages
rustic compass
can't you set the global bit only for the last pml?
recursive page table<
that wouldnt work
frank canopy
can't you set the global bit only for the last pml?
it's recursive so the high level tables are also low level depending on how you get to them
slow drift
oh I thought you just have a recursive function to get the last PML
but the page tables themselves are recursive
calm latch
solution to all paging problems: don't use recursive page tables
slow drift
why would someone use them?
they seem to complicate stuff rather than simplifying it
I like how this thread becomes home to a lot of discussions related to anything but uACPI
frank canopy
lmao yeah
it costs one top level page entry and you get access to any page structure for a virtual address without having to do traversal
slow drift
so.. the benefit is you don't traverse the page tables?
frank canopy
not manually anyway yeah
I can get any of the page tables for a virtual address with just some bit math
slow drift
and I can get any page table for a virtual address with just some function calls and some bit shifts
what's the deal
frank canopy
it isn't really a big deal either way
does save having to manually map all the page tables but that's not a huge deal
slow drift
it's more of a hack than anything, which seems harder to implement than a "normal" VMM
or maybe not but still, it's a hack and imo it should not be relied on
I guess this is subjective
frank canopy
shrug it's technically a hack but it fails out of the standard so it can be relied on. either way it's subjective
slow drift
speaking of amd requirements I'm still mad that high level page tables can't hav...
but when you have issues like this maybe one would just do normal page tables instead lol
frank canopy
but when you have issues like this maybe one would just do normal page tables in...
idk its kinda whatever
gentle peak
so.. the benefit is you don't traverse the page tables?
the benefit is that you get to access any of the paging structures currently in use without having to map all physical memory
mostly useful on 32 bit platforms where an hhdm is infeasible
frank canopy
yeah
i think windows still uses it and linux might but for them its probably a holdover more than anything
slim panther
we need to convince upstream to switch to uacpi
vast kestrel
Linux doesn't have recursive page tables
But they are neat, I used them to embed the buddy allocators metadata directly in the page table entries of the direct map
And if you want to iterate the page table for whatever reason it's also very convenient since you don't have to do a tree like iterations but it's just a for loop
hollow elm
though to be fair if its only like one old cpu then not like it really matters
they're still carrying the requirement around in various manuals for modern cpus
i found it in some document for zen3/4 iirc
it's probably just ^C^V at this point without much thinking though?
calm latch
the benefit is that you get to access any of the paging structures currently in ...
I use temporary mappings in my kernel
No issues with recursive mappings, and no issues with 32 bit platforms
gentle peak
there are slight issues with performance though
those can be mostly mitigated ig
but still not as good as recursive or hhdm
calm latch
But those also potentially cause a lot of page walks
blissful creek
how are there 32k messages in here
kindred beacon
I have a new motto proposal btw
uACPI, the shitty kernel microbenchmark for garbage homebrew kernels
fiery turtle
Lol
north holly
damn uACPI thread is going to go past obos' message count soon
I need to lock in and get shit done
kindred beacon
can't compete with nyaux anyways
north holly
fr
slim panther
tf
torpid root
too many one word messages
hasty plinth
the early days of the nyaux thread were different
sterile egret
lmao
fiery turtle
Fun fact u didnt care about:
❯ grep -rh "SCI Interrupt :" | sort --unique
[02Eh 0046 2] SCI Interrupt : 0009
the SCI IRQ is always 9 (on literally all 500 blobs that I have)
(well okay its set to 0 on hw-reduced blobs)
torpid root
that's actually interesting
fiery turtle
Finally got around to fixing the ACPICA bug i was talking about: https://github.com/acpica/acpica/pull/998
fiery turtle
Almost done with these sorts of tests for opregion types
One last (the hardest) left for GenericSerialBus
and on the test runner side
rustic compass
How many features/feature completeness could a os achieve with only table and aml support without ec and non mmio/pci gas support?
fiery turtle
non mmio/pci gas is very very rare, like i've only seen it on arm
as for no EC, u can basically do most things as well, some of the more advanced aml stuff might not work, like reading battery stats for example
frank canopy
so with no ec you lose out on advanced laptop things then?
hollow elm
advanced laptop things like the power button :^)
fiery turtle
so with no ec you lose out on advanced laptop things then?
yeah
hollow elm
or well, on modern amd laptops the power button doesnt even use the ec
fiery turtle
for AMD u literally need an AMD GPIO driver as well lol
fiery turtle
so with no ec you lose out on advanced laptop things then?
well and a lot of aml blobs unconditionally assume ec is supported if u report modern windows
but if u play around with uacpi's OSI settings u can report old windows
hollow elm
just report that you're hp-ux or something
fiery turtle
yeah only servers check for HP-UX lmfao
hollow elm
i think my old laptop checks for it as well
fiery turtle
damn
hollow elm
idk if it does anything with that information other than treating it the same as some version of windows tho
frank canopy
neat
deft canopy
yeah only servers check for HP-UX lmfao
One day I'll dump the AML from my Itanium machines, I bet that'll be fun to look around in
fiery turtle
definitely
deft canopy
Just gonna ask rene and some others for the AML dumps, idk why i never thought to ask them
fiery turtle
is rene the guy from t2
deft canopy
Ya
deft canopy
I would be surprised if someone in their server didnt have some old stuff, i can def ask around
fiery turtle
much appreciated
sterile egret
if they have very old x86 laptops or pcs too
I actually figured out what should be the first Compaq laptop with ACPI, but I haven't bought one yet.
fiery turtle
Compaq is known for the amount of quirks it has in the kernel so should be insane
frank canopy
btw @fiery turtle https://damn99.com/en/2021-03-13-com0com/ signed com0com
fiery turtle
btw <@353593948523986945> https://damn99.com/en/2021-03-13-com0com/ signed com0c...
Thanks!
frank canopy
np
frank canopy
i won't stop yapping until everyone here accesses pci ecam via eax/ax/al only
is there a source for this? cant find anything about it to reference
gentle peak
amd bios and kernel developer guide
frank canopy
thanks
gentle peak
from the family 15h one
hollow elm
is there a source for this? cant find anything about it to reference
"Preliminary Processor Programming Reference (PPR) for AMD Family 19h Model 11h, Revision B1 Processors Volume 1 of 6" section 2.1.7.1 is the latest document that still mentions it
for zen 3/3+/4
calm latch
where did you find it?
hollow elm
okay "Processor Programming Reference (PPR) Vol 1 for AMD Family 1Ah Model 02h C1 - 57238 Rev 0.24 - Sep 29, 2024" also contains that
in section 2.1.8.1
strong heath
why does uacpi have the io_read/io_write be multiplexed calls
isnt it a dirtier approach all around than having separate functions for separate sizes? you have to pass bigger integers than necessary, do switches for the byte size values, handle bad cases...
why is it not io_read8, io_read16, and io_read32
north holly
isnt it a dirtier approach all around than having separate functions for separat...
Well, uacpi handles bad cases probably
strong heath
its left for the kernel to do it
north holly
What do you even mean by bad cases?
fiery turtle
because a lot of kernels already have their own similar functions that do the switch, u can just redirect the call to those
strong heath
any value that isnt valid, like, anything above 4 for x86 platforms
fiery turtle
also, less apis to implement == better
north holly
any value that isnt valid, like, anything above 4 for x86 platforms
Just return invalid value?
Invalid argument
Not like that's impossible to do
strong heath
yeah but why do you have to do that at all is the point here
north holly
Meh I think it's fine
fiery turtle
ACPICA gives u raw bit size that u must round up to next byte boundary
so theres that
loud ice
lmfao what
fiery turtle
yea..
loud ice
but yeah i agree that uacpi should have split 8/16/32
strong heath
because a lot of kernels already have their own similar functions that do the sw...
this is a really weird justification when it comes with these drawbacks, and I must say ive seen no kernel implement their port IO like this, because honestly, its moronic
north holly
ACPICA gives u raw bit size that u must round up to next byte boundary
Most sane ACPICA kernel api
loud ice
this is a really weird justification when it comes with these drawbacks, and I m...
yeah and it pesimizes codegen for no good reason
strong heath
also, less apis to implement == better
I can see this as an argument, but you are paying a lot for it
strong heath
if you want to do it inside uacpi that is your deal
dont pass that debt to the kernel
fiery turtle
uacpi doesnt know the size its going to read or write ahead of time
so its the same exact code
just different place
fiery turtle
or AML fields
loud ice
static safety is still better though
fiery turtle
it doesnt affect performance
north holly
this is a really weird justification when it comes with these drawbacks, and I m...
OBOS_EXPORT obos_status DrvS_WriteIOSpaceBar(pci_bar* bar, uint16_t offset, uint32_t val, uint8_t byte_width);
OBOS_EXPORT obos_status DrvS_ReadIOSpaceBar(pci_bar* bar, uint16_t offset, uint32_t *val, uint8_t byte_width);```
yeah
strong heath
if uacpi has to do the switch, that is their issue, why do you have to dirty the kernel API so you dont have to do it
its such a weird approach
vagrant hull
also i am not gonna say anything but i don't think that "ACPICA does it like that" should be much of a justification for doing things similarily :^)
fiery turtle
nah i was giving an example of how u can make this api even worse lol
vagrant hull
yeah i'm just saying
strong heath
ACPICA makes you kill all your children so uACPI claiming only your firstborn is great design
fiery turtle
but yeah i agree overall that its cleaner
loud ice
```c
OBOS_EXPORT obos_status DrvS_WriteIOSpaceBar(pci_bar* bar, uint16_t offset,...
wtf why cringe
north holly
Felt like it
loud ice
shkwve straight up does not have io bars at all lol, and its fine
north holly
shkwve straight up does not have io bars at all lol, and its fine
R8169
Needs IO space bars
loud ice
sorry i dont have any nics at the moment
north holly
Just some ethernet controller
loud ice
the closest i have to a NIC is usb
hey i have usb and u dont so im right and ur wrong, checkmate!
vagrant hull
as a matter of fact if it were up to me i'd get rid of the io_map/io_unmap APIs entirely and just have the io read/write 8/16/32 and that's it, for x86, since that's basically the only platform that needs it, and to hell with following the ACPI spec to the T
loud ice
though i should probably fix it
loud ice
as a matter of fact if it were up to me i'd get rid of the io_map/io_unmap APIs ...
its nonsensical on not x86 anyway
vagrant hull
yeah
loud ice
thats straight up not how it works
fiery turtle
as a matter of fact if it were up to me i'd get rid of the io_map/io_unmap APIs ...
microkernels and stuff tho
loud ice
microkernels and stuff tho
iopl them and be done with it
mortal yoke
Needs IO space bars
it doesn't, it also has memory bar
north holly
it doesn't, it also has memory bar
True true
fiery turtle
anyway ill make a vote about splitting them i think
loud ice
managarm has it in kernelmode
fiery turtle
which microkernel has uacpi in userspace?
pmos
north holly
which microkernel has uacpi in userspace?
pmOS
fiery turtle
thats what he does atm lol
loud ice
or lazily attempt obtaining permissions for it
loud ice
as a matter of fact if it were up to me i'd get rid of the io_map/io_unmap APIs ...
IF you have port io emulation THEN it's tied to the pci controller and not the entire chip anyway
fiery turtle
#polls message
vagrant hull
idk it just seems a bit overcomplicated but i maybe just haven't thought it through
loud ice
i mean honestly, apart from the microkernel thing i'd be okay with uacpi straight up inlining its own asm for it
vagrant hull
^
fiery turtle
idk it just seems a bit overcomplicated but i maybe just haven't thought it thro...
e.g. reactos has one api for mapping phys memory and io ports
so it would have to leak a handle
or have internal cache
north holly
i mean honestly, apart from the microkernel thing i'd be okay with uacpi straigh...
I think that goes against the uacpi philosophy™️
loud ice
or just not use the api for mapping io ports
loud ice
it would have to `map() read() unmap()`
or just read/write without bothering with mapping
fiery turtle
well in reactos u have to map
loud ice
or map all ports at startup and who cares that its broken
loud ice
well in reactos u have to map
dont see ```
IF ((OS = REACTOS) and (IO address not mapped))
THEN (* ReactOS says you have to map sorry *)
#GP(0);
FI;
lol
anyway korona had some very good arguments for why we should keep the map api
i was gonna remove it entirely
loud ice
anyway korona had some very good arguments for why we should keep the map api
oh really?
fiery turtle
it was a bit more than that
north holly
Microkernels aren't even real anyway
fiery turtle
like why have map for memory and pci, but not io, which is technically also on every other arch
why make it special just because its not needed on x86
north holly
Also is uacpi 1.0.0 soon
fiery turtle
i think its a good argument
loud ice
like why have map for memory and pci, but not io, which is technically also on e...
io is only on x86 tho
fiery turtle
io exists on anything that has pci
fiery turtle
aml can still use it tho
fiery turtle
Device (PCI0)
{
OperationRegion(..., SystemIO, ...)
}
AML could probably do anything
loud ice
```
Device (PCI0)
{
OperationRegion(..., SystemIO, ...)
}
```
return error(fuck you shitty vendor)
fiery turtle
lol
fiery turtle
like linux does have io support for aml compiled in for arm
explicitly
so im assuming thats for a reason
north holly
Wassit do
strong heath
another question, for the virtual memory map functions of uacpi, what caching do you guys prefer
uncachable?
fiery turtle
nope
strong heath
general purpose write back?
fiery turtle
that will kill your perf
strong heath
idk im asking
north holly
I use hhdm
fiery turtle
on x86 u use hhdm
north holly
Soooooooooo
strong heath
ah yes the hhdm caching
loud ice
very specific
loud ice
another question, for the virtual memory map functions of uacpi, what caching do...
the one set up by firmware in MTRRs
fiery turtle
well ok u use MTRR which are set correctly
north holly
Yes very
loud ice
no e820 outside of x86
loud ice
the efi memory map does not have any entry that tells you "use caching mode X"
strong heath
I just got told to not do UC
loud ice
and put a fence and cache flush before and after it (riscv)
fiery turtle
no, dont do what pitust tells u jesus lol
fiery turtle
normal memory is mapped as normal memory
loud ice
honestly. just map it nGnRnE and be done with it
fiery turtle
that will kill your perf tho
loud ice
how much actual perf do you lose by that?
loud ice
that will kill your perf tho
aml takes very little time
fiery turtle
aml takes very little time
well if u poll battery every X ms that will accumulate
loud ice
well if u poll battery every X ms that will accumulate
where X=probably like a second?
fiery turtle
no idea tbh
loud ice
and a poll is maybe a couple writes
and anyway arm ngnrne does not apply to ram, only devices
calm latch
Needs IO space bars
how does it work on stuff like risc-v?
north holly
Probably just a memory bar
loud ice
how does it work on stuff like risc-v?
the pci controller has a memory mapped window for it
gentle peak
pio on non x86 is just MMIO with an offset
loud ice
so on x86 you have mtrrs
fiery turtle
honestly. just map it nGnRnE and be done with it
it does map normal ram as PAGE_KERNEL_RO tho, everything else gets ngnrne, if linux can do it u can too
loud ice
it does map normal ram as PAGE_KERNEL_RO tho, everything else gets ngnrne, if li...
linux is boring and too good for me
im mapping it ngnrne and you cant stop me
also linux is like a pretty good os
calm latch
another question, for the virtual memory map functions of uacpi, what caching do...
I use UC..?
fiery turtle
im mapping it ngnrne and you cant stop me
damn
calm latch
Idk it works as normal
calm latch
I map framebuffer as UC
loud ice
lmfao
fiery turtle
honestly i suspect its RO to stop attacks
i mean aml is trusted code lol
calm latch
Because my phys map function just maps everything as UC
loud ice
I map framebuffer as UC <:KEKW:913708372329644042>
meanwhile me with SCTLR.C=0:
calm latch
Because my phys map function just maps everything as UC
I need to change that, but I have other things to do
loud ice
i mean aml is trusted code lol
true
fiery turtle
Also is uacpi 1.0.0 soon
this week
calm latch
on x86 u use hhdm
pmOS doesn't use hhdm 
calm latch
hhdm is for the weak
loud ice
yeah and those with performance concerns too i guess
calm latch
the difference is in a couple of page walks
fiery turtle
linux is boring and too good for me
wait, nGnRnE applies only if it wasnt able to find a mapping in the EFI map
loud ice
yeah its average linux code
fiery turtle
th rest is mapped literally as normal ram
this logic is correct tho i think
device addresses wont be on the efi map
the rest will
calm latch
"But what about hot(un)plug memory "
fiery turtle
hotpluggable memory regions do appear in the memory map
calm latch
fiery turtle
device addresses could appear in the efi memmap though
yeah those would have appropriate attributes set tho
gentle peak
"But what about hot(un)plug memory "
there's a memory type for the regions of the physical address space where hotplug memory can appear
fiery turtle
which would default prot to ngnrne
gentle peak
fair enough
calm latch
anyway, I think I'll be adding another memory manager to pmOS eventually
To do stuff like PCI bar allocation
strong heath
maybe uacpi should pass to the map function a preference for the caching
strong heath
well maybe you should have one then
loud ice
just map it nc and call it a day smh
you are overthinking it
hmm
i wonder
could you induce SMM bugs by messing with MTRRs
fiery turtle
you definitely can
calm latch
could you induce SMM bugs by messing with MTRRs
how do they even manifest
loud ice
which brings us to the next two questions
fiery turtle
your pc hanging
fiery turtle
framework should have opensource firmware iirc?
fiery turtle
bruh
fiery turtle
another open source dream shattered
loud ice
another open source dream shattered
the framework chromebook has open firmware lmfao
fiery turtle
steamdeck can do coreboot they cant lmfao
loud ice
its chromeos
mortal yoke
the board that I have has a mostly open firmware impl available based on coreboot + edk2
jaunty fox
the framework chromebook has open firmware lmfao
kinda based
loud ice
so its the standard chromeos coreboot/depthcharge setup
loud ice
and steamdeck too
by default?
jaunty fox
wait
fiery turtle
yeah, all aml tables it has are COREBOOT stuff
jaunty fox
do you mean openfirmware or open-source firmware
loud ice
oh damn
loud ice
do you mean openfirmware or open-source firmware
open source firmware
sorry not OF
obviously
OF on x86 would be stupid
jaunty fox
OF on x86 would be stupid
they used it in one laptop per child
north holly
OF on x86 would be stupid
Only fans on x86
loud ice
a custom ec impl too
not cros_ec?
jaunty fox
https://wiki.laptop.org/go/Forth_Lesson_9 here they discuss how to use forth to interact with the openfirmware device tree
mortal yoke
the board that I have has a mostly open firmware impl available based on coreboo...
https://docs.dasharo.com/variants/msi_z690/releases I should try this but I generally don't like flashing bios because then I have to redo all the fan settings and disable undervolt protection or I get very bad perf (I accidentally left that enabled after an update and were wondering why qemu takes multiple seconds to boot)
fiery turtle
not cros_ec?
drivers/platform/olpc/olpc-ec.c
loud ice
damn
fiery turtle
anyway vote pls: #polls message
If this is accepted id like to do it before 1.0
strong heath
what the hell does it mean for uacpi_kernel_get_thread_id to return a void *
what does the void * represent
is it a pointer to an opaque structure? is it an integer cast to a pointer?
gentle peak
opaque value that's unique for each running thread
strong heath
thank you representative of the OOMF guild
gentle peak
afaik it's only used for recursive mutexes
fiery turtle
what the hell does it mean for `uacpi_kernel_get_thread_id` to return a `void *`
void* is a default, this is an overridable value that you can set to anything
platform/arch_helpers.h
strong heath
I love binding loosey goosey typesystems with vibes based meanings into Ada/SPARK, which has the strongest type system ever made
how can you tell
loud ice
(you probably cant)
loud ice
I love binding loosey goosey typesystems with vibes based meanings into Ada/SPAR...
you don't like vibe based meanings? why?
i love a good bit of vibe-driven development
calm latch
isn't this basically all of C?
fiery turtle
damn this vote is closer than i thought
fiery turtle
waiting for nyaux to vote
fiery turtle
no
loud ice
wait this is not even about map its just the width?
fiery turtle
im definitely not removing map
loud ice
cringe
fiery turtle
u mean
loud ice
the only case where map makes any sense is the pmOS setup, and they run uacpi with iopl(3) ANYWAY
fiery turtle
its 2 loc to stub out io_map
loud ice
(it also makes sense for ARM?)
no it doesn't make sense on arm, that's the thing
IO ports are a property of the PCI controller, not of the entire SOC
calm latch
does uacpi not use io on it?
fiery turtle
right but why does inb etc work on linux
on arm
without specifying any sort of base or controller address
calm latch
I need to port pmOS to arm
loud ice
i think it reads from base 0 though
which is. weird.
or maybe not idk
anyway linux sucks, systemio makes no sense on !x86 and it doesnt make sense anyway
also this is something you can add back if and when we find firmware that needs it
which i think is unlikely
calm latch
the only case where map makes *any* sense is the pmOS setup, and they run uacpi ...
one of the reasons why I just use iopl is because it's also kinda unclear what to do with threads
fiery turtle
basically my thoughts
- potentially arm memes, although no one knows what aml on arm does
- microkernels
- abstractions for mapping both address spaces with one helper (like reactos)
- aligns nicely with AML since i can pre-map all opregions
- aligns nicely with pci and memory apis since they do map stuff
- trivial to stub out if it's a no-op in your kernel
loud ice
ok fair
fiery turtle
basically the only argument against is "lol it doenst need mapping are u stupid"
and well, my less apis to implement == better idea
but i think in this case its justified
frank canopy
right but why does `inb` etc work on linux
if that exists as an arm instruction i got no idea. if it doesnt exist i bet its catching whatever the arm equiv to invalid opcode exception is and checking if its inb
fiery turtle
nah, its a function: https://elixir.bootlin.com/linux/v6.12.6/source/arch/arm/include/asm/io.h#L241
it reads from here:
/* PCI fixed i/o mapping */
#define PCI_IO_VIRT_BASE 0xfee00000
#define PCI_IOBASE ((void __iomem *)PCI_IO_VIRT_BASE)
wrong directory
you want arm64
not arm
loud ice
uh. no
fiery turtle
#define PCI_IO_START (VMEMMAP_END + SZ_8M)
#define PCI_IO_END (PCI_IO_START + PCI_IO_SIZE)
ahhh ok
fiery turtle
yep
#if !defined(inb) && !defined(_inb)
#define _inb _inb
static inline u8 _inb(unsigned long addr)
{
u8 val;
__io_pbr();
val = __raw_readb(PCI_IOBASE + addr);
__io_par(val);
return val;
}
#endif
what do they even map there
fiery turtle
int pci_remap_iospace(const struct resource *res, phys_addr_t phys_addr)
{
unsigned long vaddr = (unsigned long)PCI_IOBASE + res->start;
if (!(res->flags & IORESOURCE_IO))
return -EINVAL;
if (res->end > IO_SPACE_LIMIT)
return -EINVAL;
return vmap_page_range(vaddr, vaddr + resource_size(res), phys_addr,
__pgprot(get_mem_type(pci_ioremap_mem_type)->prot_pte));
}
EXPORT_SYMBOL(pci_remap_iospace);
you're right
they just emulate x86
basically all PCI IO is mapped to one place
calm latch
they just emulate x86
what
fiery turtle
they pretend its a separate address space and remap it to a fixed location
so u use inb for x86 and other arches
fiery turtle
hmm ok
what's nice is there's basically one usage of these helpers in the entire code base
like 1 extra for io write
fiery turtle
@slim panther should we update uapi as well?
slim panther
yes
flat badge
Iirc I also mentioned it before
fiery turtle
we knew that already
i wonder how linux manages collisions in that global pio region
loud ice
honestly this feels so much like a linux-specific hack
fiery turtle
if you have one controller where 0x1000 IO maps to 0xDEADBEEF and another where 0x1000 IO maps to 0xBEEFDEAD so there's no collision technically
but in that global region offset 0x1000 would collide
loud ice
also, i'd advise against adding this to uAPI
fiery turtle
this?
fiery turtle
we aren't adding that
fiery turtle
we will have bar_map and bar_read/write, and normal port io for legacy devices, aml etc
loud ice
we will have bar_map and bar_read/write, and normal port io for legacy devices, ...
define "normal port io" tho
loud ice
that does not work for uDRM
loud ice
the vga device bar names the registers iirc
fiery turtle
the bochs gpu certainly doesnt have that in the bar
loud ice
wtf?
okay then
allow udrm asking for io ports not covered by a BAR
but still against the pci device
loud ice
how would that api map into uacpi
it wouldn't
fiery turtle
like it doesnt know what pci device to associate it with
mortal yoke
why would it have to take in a pci device anyway?
fiery turtle
lets put it this way, whats the downside of a raw legacy io uapi interface?
flat badge
I think what linux does it more or less the same as on x86: it will give each device a different range if i/o ports even if they are on different controllers
loud ice
lets put it this way, whats the downside of a raw legacy io uapi interface?
that it breaks if you have more than one pci controller
flat badge
So there no collision
fiery turtle
I think what linux does it more or less the same as on x86: it will give each de...
ohh
loud ice
I think what linux does it more or less the same as on x86: it will give each de...
ah, they mess with BAR assignments?
that sounds so annoying to implement
fiery turtle
that would make sense i guess
fiery turtle
that it breaks if you have more than one pci controller
its legacy io so its x86 specific
flat badge
yes, sure, automatic BAR assignment is not a thing on most platforms
That's an x86 special
flat badge
Yes, true.
loud ice
but yeah this sounds very annoying to correctly implement
flat badge
Well, uefi has to implement this correctly for x86 already
loud ice
its legacy io so its x86 specific
if you make it only an api on x86, then cool
flat badge
If they support multiple segments at all at least (iirc ovmf doesn't)
loud ice
Well, uefi has to implement this correctly for x86 already
you only have one pci controller on x86 though
afaik
flat badge
No, servers have multiple ones
flat badge
at least larger servers
loud ice
interesting
fiery turtle
chromebook has pci segments lol
flat badge
They have one segment per socket
loud ice
chromebook has pci segments lol
oh lmao
like my one?
neat as a testing platform (if the charging port worked at least)
fiery turtle
it was either your chromebook or qualcomm's windows laptop
hollow elm
the rpi5 technically (as per linux) has 3 segments
loud ice
ah okay it was sdxe
hollow elm
the rpi5 technically (as per linux) has 3 segments <:meme:575445094589661215>
because linux just assigns a new segment number to each dtb pci controller node
loud ice
ngl i love how the open source firmware is the clean and well written one
and then the closed firmware is just lolnope
loud ice
because linux just assigns a new segment number to each dtb pci controller node
aaaah
yeah that makes sense
loud ice
they have different pci windows
hollow elm
yeah, and segments are not really a thing outside of acpi/os internals so
fiery turtle
who guaratees that tho
u can have both pci roots have a bus range of 0-3 or something
hollow elm
all 3 controllers have a 00:00.0 device that's a root port (and its configuration space is actually just the controller's mmio registers )
fiery turtle
bruh yeah
hollow elm
like the driver does if dev == 00:00.0: return mmio_base
else: write dev to window register, return pointer to window
fiery turtle
else: write dev to window register, return pointer to window
how do they solve races against this window?
hollow elm
iirc the driver provides the read/write functions and not just the map function? and in those it takes a lock on the controller
hollow elm
else: write dev to window register, return pointer to window
also notice how thats incompatible with MCFG
fiery turtle
iirc the driver provides the read/write functions and not just the map function?...
ah
fiery turtle
also notice how thats incompatible with MCFG <:meme:575445094589661215>
ecam is a luxury on shitty embedded devices ig
flat badge
Does the acpi firmware for raspi just not expose pcie?
hollow elm
Does the acpi firmware for raspi just not expose pcie?
on the pi4 (which has the same controller) it exposes xhci as an acpi device directly, i assume on the pi5 it does the same for the rp1
flat badge
iirc its a hacky handrolled aml blob?
Doesn't this apply to all aml blobs?
fiery turtle
true
hollow elm
for the user-accessible pci connector on the pi5 they have a hack to expose the single function thats at 01:00.0 via MCFG
by pointing MCFG at the 4k window in the controller's mmio, and using os-specific hacks (one for windows and one for linux) to make sure the os only scans for 1 function at the root
flat badge
:^)
fiery turtle
most stable arm acpi implementation
dusky glade
oh no
api changes
i dont want to replace my 32 lines of code with 8 lines of code
😡
vagrant hull
(0000000000) successfully loaded 1 AML blob, 1702 ops in 17ms (avg 100117/s)
strong heath
fast
fiery turtle
`(0000000000) successfully loaded 1 AML blob, 1702 ops in 17ms (avg 100117/s)`
ironclad?
fiery turtle
mutexes etc returning NULL
north holly
You returned nullptr
north holly
Test uacpi on serenityos
vagrant hull
well that i don't know, it's still faster than some other OSes here
fiery turtle
is this tcg
fiery turtle
well true reactos got like 30k lol
vagrant hull
too generic
vagrant hull
streaks says his alloc cannot give null
north holly
I would say size=0
left orbit
maybe try setting log level to debug
fiery turtle
create_{event,mutex,whatever}
north holly
I would say size=0
But infy tests for that
strong heath
size=0 is handled
strong heath
and it cannot return null because it runs OOM handlers internally
vagrant hull
ok how do i make it debug verbose then
fiery turtle
show kernel api code
vagrant hull
wdym
strong heath
if you are brave enough to try to debug Ada code lol
left orbit
show the implementation of the uacpi kernel api
vagrant hull
it's long
left orbit
thats not big at all
left orbit
trace will show you the opcodes being executed
strong heath
does uACPI do always aligned mmaps
left orbit
which should tell you what uacpi is trying to do
fiery turtle
does uACPI do always aligned mmaps
never
left orbit
never aligned or never misaligned
kind mantle
`(0000000000) successfully loaded 1 AML blob, 1702 ops in 17ms (avg 100117/s)`
Every time I see someone post one of these I think: "Soon, BadgerOS, too, will run the benchmark"
strong heath
would uacpi take a failed mmap as out of memory itself
even when no out of memory status is returned
fiery turtle
never aligned or never misaligned
almost always misaligned
left orbit
ah
so it's the kernel's job to align the address, map the required page(s) and return an address that can be used to access them
makes sense
fiery turtle
yeah, just round_down(), map, and add diff
vagrant hull
so like
once you do initialize/load_namespace (we fixed the issue btw, it was that it needed events to be created as non-null for some reason)
fiery turtle
For some reason?
left orbit
lmao]
fiery turtle
Is it unclear why
left orbit
mint what are u smoking
loud ice
how else would you signal an out of memory condition to uacpi
outside of returning null
also how does a null event work lol
vagrant hull
i say for some reason because it doesn't seem to use events?
or are events mandatory?
strong heath
well idk it seems to work for the time being
vagrant hull
it works with events being a literal no-op
fiery turtle
Because its not contended in qemu
loud ice
why do you not use a mutex?
vagrant hull
can you use a mutex?
fiery turtle
You cant
loud ice
why?
fiery turtle
The way firmware tells you its relased is via an interrupt
loud ice
okay sorry i dont understand the issue
like it would be ideal if you only used one concurrency primitive as much as possible/feasible
fiery turtle
When uacpi tries to acquire it, it may be used by firmware
fiery turtle
like it would be ideal if you only used one concurrency primitive as much as pos...
Event is a thing in aml
U cant not have it
fiery turtle
When uacpi tries to acquire it, it may be used by firmware
If it is, you block on an event until its released
The way u know its released is via an irq
loud ice
yeah so if you see that it is contended, you acquire a helper mutex