There is no need to pass the current mode as an argument as ACPI has
access to that info either way.
Only route INTx objects when using ACPI, they won't be used otherwise
The old SpinLockAsMutex was pretty confusing first of all. It also was
causing the issue thats been around for maybe a year now which is the
only consistently happening kernel panic. I've been pretty confused
about this and finally figured out what was causing this.
The main issue was that we were accidentally enabling interrupts when
blocking a thread that passed SpinLockAsMutex from normally interrupt
enabled context. This led to receiving IPI for thread unblock while
we were actively blocking the thread. I'm very suprized this had't
caused any more serious issues than occasional kernel panics :^)
This moves locking to the inodes themselves which allows reducing lock
times significantly. Main inodes (ext2 and tmpfs) still do contain a
single big mutex that gets locked during operations but now we have the
architecture to optimize these.
Apparently I'm not supposted to calculate device/function from the
offset, but parse them from the acpi namespace :)
This allows PCI PIN interrupt routing actually work
There is a very hacky no-inline hack that I am not proud of but it drops
the stack usage of few functions A LOT.
Previously Virtual Box could not boot with our 8 page stack, but these
changes allow it to boot on 5!
Kernel can just use raw threads, pretty muchs the only thing that
process provides is syscalls which kernel threads of course don't
need.
Also this makes init process have pid 1 :D
All block functions now take an optional mutex parameter that is
atomically unlocked instead of having the user unlock it before hand.
This prevents a ton of race conditions everywhere in the code!
This implementation is on top of inodes instead of fds as linux does it.
If I start finding ports/software that relies on epoll allowing
duplicate inodes, I will do what linux does.
I'm probably missing multiple epoll_notify's which may cause hangs but
the system seems to work fine :dd:
Now _REG, _STA, _INI are called in the order my laptop expects them to
be called. This was kinda weird because what uACPI was doing did not
work.
\_SB_.PCI0.LPC0.EC0_.BAT0._STA required \_SB_.PCI0.LPC0.EC0_._REG to be
called
\_SB_.PCI0.LPC0.EC0_._REG required \_SB_.PCI0._STA to be called
Now I call all the _REG methods of a device after calling _STA/_INI and
after performing the whole _STA/_INI sequence i call rest of missing
_REG functions
Bananymous