#OBOS (not vibecoded)
1 messages · Page 26 of 1
and what does this command do?
Clones the obos repository
now what?
Look at instructions in readme
alr
Microsoft Windows [Version 10.0.19045.5131]
(c) Microsoft Corporation. All rights reserved.
C:\Users\Xavier>cmake -GNinja -DCMAKE_BUILD_TYPE=Debug --toolchain=src/build/x86_64/toolchain.cmake -B build/x86_64 .chmod +x dependencies/hyper/hyper_install-linux-x86_64cmake --build build/x86_64scripts/generate_initrd-x86_64.shcmake --build build/x86_64
CMake Warning:
Ignoring extra path from command line:
"build/x86_64scripts/generate_initrd-x86_64.shcmake"
CMake Error: Unknown argument --build
CMake Error: Run 'cmake --help' for all supported options.
C:\Users\Xavier>
the 2 step doesnt work
Copy one command at a time
In the directory you ran git clone in
but it wont make it defualt system right?
No
ah alr
Btw if any build errors happen, it is probably because you are missing a prerequisite tool
My script to launch qemu doesn't enable it
so no/
Like vb
Especially on debug mode
alr
Which is what those commands compile by default
which file do i use
there are 4 files
Yes and what are you tryna do
which do i use to put in the vm
wait imm install again
wen i slect add in virtual box they ask me the file name what is it
out/obos.iso
If that doesn't exist your build failed
Make sure you have all prerequisites
Otherwise it shouldn't fail
brb
i will
w
sudo <package manager> install cmake
or if you are on a sane distro just type cmake and it'll ask you if you want to install it
He's on windows
Basically
Search cmake
Find installer on website
Use installer
also just corious what distro you use
arach vs debian
Boo
i heard debian had a bug which uninstalled your graphics driver'
Anyway gtg
randomly
alr
fedora
Yellow guys
bro gave tech support at hajj
No hajj is during dhul hijjah
I was at umrah a day prior
Wait for file upload
@real pecan
This is legacy stuff
Acpi tables are built by qemu and not seabios
Just start a chain of that until I get back to obos work
Huh
How does one
reading fail
make a multisyscall bytecode in obos 
Why not 
I though it would be kinda funny, basically a syscall that you give a bytecode that can do more syscalls and move arguments/return values around
then you could write a hello world using one real syscall that combines print + exit (but with no additional context switch overhead)
or for a less cursed alternative just without the bytecode part like you though at some point 
Just use AML
aml syscall
Would be amazing if it weren't for the direct system access
you could do security checks in the uacpi kernel api fns
to make sure that userspace supplied aml can't do reads/writes to anywhere in mmio/io/pci
just allow it
Who cares about security
only nerds
Don't think my pc should be doing that
Huh
It worked when I clicked a key
oh god
idk if it's because I haven't typed at this pace for a long time or that I somehow became faster at typing on my vacation
but my typing feels a lot faster
also I think osdev does make me go insane
I swear I felt a lot different before I left for vacation
probably just osdev and school driving me nuts
time to get back on obos grind
@white mulch I need you to test a seabios image
pls
make sure ur stuff works with it since it does the mmconfig
on suspend
it doesn't, the writes to the pci bars don't work
actually yeah nvm lol, I were accidentally using the wrong run target that didn't use the bios
so it worked
?
yes
kthx
@real pecan my cousin decided to test obos on a laptop of his
and we'll see how uacpi works there
although currently it is refusing to go into obos
I told him to change the boot priority of the usb
in case it was a bug with his bios' boot selector
yup
did u enjoy it
very
nice
oh also the new version will have successfully loaded & executed 1 AML blob in 2ms (49 opcodes, avg 19483 ops/s) etc
how was the sand 
(sorry)
[ LOG ] Arch_KernelMainBootstrap: Done early boot.
[ LOG ] Currently at 8892 KiB of committed memory (1332 KiB pageable), 0 KiB paged out, 8756 KiB non-paged, and 0 KiB uncommitted. 16228 KiB of physical memory in use. Page faulted 933 times (0 hard, 933 soft).```
im not sure if thats the final look
quite nice
i hate winter so some sand could be nice right now
@flint idol is there any way u could test the new pr before i merge it
i mean on real hw and qemu etc
yes
how much?
thanks
what about uacpi_object api
that hasnt changed
big W
if i stop being lazy af 1.0 could be a few weeks away
more debugging to do i guess
do it
now u should be able to enable events right away
it shouldnt race with init
things that are still racey: opregion install/uninstall, event handler install/uninstall
but only if done at runtime
the interpreter and namespace stuff should be fully thread safe now
nice
legacy didn't work
ah
uefi mode hung in obos
legacy didn't boot in the first place, just went onto booting into linux
cursed laptop
real
very good RetarBIOS implementation
nice T420
I can ignore node_depth, right?
ye
kthx
uacpi_namespace_for_each_child is the full one, u can use uacpi_namespace_for_each_child_simple, which is more like the old api
k
but the former can filter by type etc which is convenient
also eval has a billion shorthands now
since I'm only testing to see if it will work rn, I'll just use the one more like the old api
ye
@real pecan
actually
more so
shareable.c:(.text+0x236): undefined reference to uacpi_atomic_inc32' /home/oberrow/x86_64-elf-tools/bin/../lib/gcc/x86_64-elf/13.2.0/../../../../x86_64-elf/bin/ld: ../uACPI/libuacpi.a(shareable.c.obj): in function uacpi_shareable_unref':
shareable.c:(.text+0x2e0): undefined reference to uacpi_atomic_dec32' /home/oberrow/x86_64-elf-tools/bin/../lib/gcc/x86_64-elf/13.2.0/../../../../x86_64-elf/bin/ld: ../uACPI/libuacpi.a(shareable.c.obj): in function uacpi_shareable_refcount':
shareable.c:(.text+0x3de): undefined reference to `uacpi_atomic_load32'\
those ones
the others I know are my fault
probably not
if not then it should be there
#define uacpi_atomic_inc32(ptr) __atomic_add_fetch(ptr, 1, __ATOMIC_ACQ_REL)
does ur atomic.h header have that?
ah nvm
it's because u override arch helpers
and arch helpers include atomic
and other files expected to get atomic through it
ill fix those but now u can just add that include
or well i guess its just the shareable.c file
thats wrong ofc, so good thing we found this problem
yup
what do I name it?
uacpi_atomic.h
?
in your arch helpers just add #include <uacpi/platform/atomic.h>
kk
u actually use uacpi's atomics here
so would be a good idea to include it anyway
I have no time for anything rn, but I can update my OS to test it
would be cool if u have time, but keep in mind its just a pr right now and not merged
@real pecan It works
real hw too?
well thats nice anyway
I'll see if it hangs when I use uacpi master
that wouldnt mean much
because it now uses mutex api and event api and stuff and maybe u handle some of that wrong
do u have deadlock detection in your mutexes?
think so
then it's probably your skill issue that it hangs
only way it would hang in uacpi is mutex deadlock if some logic is wrong somewhere
Eventually
so that it panics and dumps the waiters
it could be like
T0: T1:
acquire_a() acquire_b()
acquire_b() acquire_a()
anyway more printffing is needed
yeah im looking at event code rn and dont see anything wrong instantly
indeed
lol
Yup
didnt u already have this bug before where events would hang or something?
btw, what my kernel's idea of "event" is different than uacpi's idea, iirc, so I made some half-assed implementation
that I never tested
events are only used for global firmware lock
well and aml Event objects
that code hasnt changed in a while
did u figure it out?
helping my cousin run an obos vm
ah
do you do this
no
im talking about infy
does UACPI acquire mutexes while having acquired mutexes
Yes, but without the abba
In limited cases
Certainly not where it currently hangs in obos
Does ACPI code acquire mutexes recursively and sometimes in reverse order?
Does Windows handle that case by deadlocking?
This is not related to aml, and yes aml mutexes are recursive and yes they work in nt
And yes abba aml acquires would hang in nt
But thats not what happens here
ok, cool
Well sane aml doesnt do that generally
Ah
So where does it hang exactly
Still don't know
Why did it work before
Only idea I had was because of my gpe bug
On x86_64
But I fixed that
Maybe thats why it also dies on your cousins laptop
Nah it died earlier than uacpi init
So like this worked before because u had events disabled?
Still trying to figure out why it worked before
Wtf
It did work before
But checking out that commit
Only reveals the opposite
Bruh wtf
I swear it worked before
Inb4 obos never even booted once and it was all a dream
Btw, a seabios maintainer asked if they could add it to the beginning of pci_resume, to which I replied "yes," after asking qwinci to test it
God damn it discord
Why didn't discord reply to the god damn message
Meant to reply to this
They asked you to add it and then resend the patch
Yea the bug was fixed
hihi
@spark phoenix this thing is obos
anyway now that you're here
a star would be appreciated
how on mobile
broooooooooooo
I need to fix the hanging bug
but I don't wannaaaaaaaa
ah well
how sad
guess I have to
It isn't
Since it persists with uacpi master
u dont have a notify handler installed for this device
it doesnt really mean anything
Oki
wdym
Remember the gpe bug I fixed a couple weeks back
oh yeah
I was scared that it manifested itself again
Which was why I added the logs in bootstrap irq handler
@flint idol did u figure out the bug?
f
just don't go
I would never
how much school u got
obos is love
i have a full time job and more time than you
obos is life
Well some time is school
Some time is being tired after school
Some time is ignoring this bug
Most time is ignoring this bug
likewise lol
whenever i encounter a bug i can't figure out i rewrite the system that's around it and that usually fixes it
its effectiveness is debatable
For you, infy, I will debug this bug
inshallah 🙏
this is a 5th obos rewrite
kde user spotted
After update
Yes.
do it
So I hang after events are registered
Seemingly
It's not with gpe handling
What
It works on bios
And on uefi
@real pecan the bug has decided to disappear
obos is stable once again
Although my time keeping is broke
Whatever happened to this bug, idk
Maybe you accidentally broke something in uacpi and unknowingly fixed it
Well bugs don't just fix themselves, do they
hard reset the pc
The bug must have fixed itself then
This is the commit where you added the ops/s
wrong commit because i can see outdated formatting
probably a race condition in your code that is sometimes triggered idk
didnt u say even old uacpi was broken
And update my uacpi
yeah idk
curse
Maybe I need to do an exorcism on obos
well if it works it works
is this bug reproducable or gone completely?
3800 ops is only 2x diff from qemu
pretty small aml
as a comparison, mint's latest pc mb is 16k ops
probably
I turned that off and it's 9k ops a second
Which still sucks
But I can also blame that on my.. questionable timekeeping method for uacpi
Or in general
It's a 500hz tick count converted to ms
So not very precise
3800 ops in 200ms
On real hw
Which is a big number when converted to ops/s
Although that's probably a broken number
3800 * 5
yea...
uacpi_u64 ops = g_uacpi_rt_ctx.opcodes_executed;
uacpi_u64 ops_per_sec = ops * UACPI_NANOSECONDS_PER_SEC;
if (uacpi_likely(end_ts > begin_ts))
ops_per_sec /= end_ts - begin_ts;
its literally this
static uacpi_u64 elapsed_ms(uacpi_u64 begin_ns, uacpi_u64 end_ns)
{
return (end_ns - begin_ns) / (1000ull * 1000ull);
}
maybe end ends up being less than begin in your case
Bru
and so it wraps around
I hate how obos uses so much memory, and I have no idea where
Like how is 17M physical memory in use
Where is it being used???
Symbol table is one thing
Drivers are another
Albeit not that significant
In terms of memory usage
Maybe it's pagecache
Along with uacpi
Since that uses many memory
I did that and I reduced allocations by a lot
if you are allocating a new region for every uacpi_kernel_map, then that might be part of the issue
I rebooted and it was a saner number
what else can be done?
consolidate any physical regions in the same page into one virtual allocation
Todo add an option to the kernel's early bump allocator to configure the size of the region
I'm just taking the largest region from the memory map, before I initialize my PMM
I'm gonna try to tag allocations now
so I'll start with the new api
void* (*TagAllocate)(struct allocator_info *This, size_t nBytes, allocator_tag tag, obos_status* status);```
typedef enum allocator_tag
{
ALLOCATOR_TAG_MISC,
ALLOCATOR_TAG_ACPI,
ALLOCATOR_TAG_VFS,
ALLOCATOR_TAG_SYMBOL,
ALLOCATOR_TAG_DRIVER_INTERFACE,
ALLOCATOR_TAG_HANDLE,
ALLOCATOR_TAG_HANDLE_TABLE = ALLOCATOR_TAG_HANDLE,
ALLOCATOR_TAG_SCHEDULER,
ALLOCATOR_TAG_IRQ, // include dpcs, timers, irq objects
ALLOCATOR_TAG_ARCH,
ALLOCATOR_TAG_DRIVER,
ALLOCATOR_TAG_SYNC_PRIMITIVE,
} allocator_tag;```
there are my allocator tags
stuff like strings go into misc
the rest is self explanatory
U can compute this at runtime
true
By walking over every allocated range
mhm
for reference:
that's my channel list on cherno server
the other channels are 💩
hotgarbage on top
the people who can take a god damn joke are in hotgarbage
and the rest are in the other channels
fun fact: that channel is the most active
oberrow@AcerAIO:~/Downloads/obos-uacpi-test$ grep -n '>ZeroAllocate' `find src/ -name '*.c'` | wc -l
68```
Oh god
68 more allocations I need to tag
acpica does it so no
uhhh
lol
that's a near two month old message
for some reason that was the message that was open on my pc
and you already responded
#1141057599584878645 message
I did link a message around that point
here
#1302525344095408171 message
maybe you clicked on it
and discord did discord stuffs
yeah probably
for future reference, tagging allocations is boring
timer* Core_TimerObjectAllocate(obos_status* status)
{
if (!OBOS_NonPagedPoolAllocator)
return OBOS_KernelAllocator->ZeroAllocate(OBOS_KernelAllocator, 1, sizeof(process), status);
return OBOS_NonPagedPoolAllocator->ZeroAllocate(OBOS_NonPagedPoolAllocator, 1, sizeof(process), status);
}```
wtf
as we can see, a struct timer is quite obviously the same thing as a struct process
did u expect it to be fun
well no
lol
part of why obos is so stable
i hope process is larger than timer
it is
I think
lol
a FAT dent
oberrow@AcerAIO:~/Downloads/obos-uacpi-test$ grep -n '>ZeroAllocate' `find src/ -name '*.c' ! -path "*mbr.c" ! -path "*disk_swap.c" ! -path "*gpt.c" ! -path "*slowfat/io.c"` | wc -l 0
finally
no more allocations to tag
nice
Tag memory usage:
UNKNOWN: 0 B
PAGE: 247 KiB
WS_NODE: 14 KiB
PAGEINFO: 64 B
PG_RANGE: 13 KiB
WS_ENTRY: 44 KiB
PCREGION: 608 B
CONTEXT: 592 B
CMDPARAM: 224 B
PROC: 480 B
THR_NODE: 288 B
x86_64: 240 B
CPULOCAL: 3 KiB
THREAD: 1 KiB
IRQ_NODE: 224 B
IRQ: 272 B
INITSWP: 14 KiB
CLINEBMP: 16 B
SYNC: 1 KiB
ACPI: 113 KiB
SYMNAME: 41 KiB
SYMBOL: 98 KiB
DRV_ID: 3 KiB
DVINITRD: 33 KiB
DRV_HDR: 2 KiB
UART_STR: 16 B
TMP: 80 B
FD: 48 B
FATFNODE: 64 B
FATBPB: 704 B
FATCACHE: 432 B
FATDENT: 1 KiB
DPC: 560 B
SIGHDR: 3 KiB
VFS: 6 KiB```
vmm context
I immediately see 80b leaked here
In TMP
[ LOG ] Processing tagged memory allocations...
Tag memory usage:
UNKNOWN: 1 KiB
PAGE: 247 KiB
WS_NODE: 14 KiB
PAGEINFO: 64 B
PG_RANGE: 13 KiB
WS_ENTRY: 44 KiB
PCREGION: 576 B
CONTEXT: 240 B
CMDPARAM: 224 B
PROC: 416 B
THR_NODE: 288 B
x86_64: 240 B
CPULOCAL: 3 KiB
THREAD: 1 KiB
IRQ_NODE: 224 B
IRQ: 272 B
INITSWP: 14 KiB
CLINEBMP: 16 B
SYNC: 1 KiB
ACPI: 113 KiB
SYMNAME: 41 KiB
SYMBOL: 98 KiB
DRV_ID: 3 KiB
DVINITRD: 33 KiB
DRV_HDR: 2 KiB
UART_STR: 16 B
TMP: 80 B
FD: 48 B
FATFNODE: 64 B
FATBPB: 512 B
FATCACHE: 432 B
FATDENT: 1 KiB
DPC: 48 B
SIGHDR: 3 KiB
VFS: 6 KiB
[ LOG ] Mm_Allocator: 691 KiB in-use
[ LOG ] OBOS_KernelAllocator: 1020 KiB in-use
[ LOG ] OBOS_NonPagedPoolAllocator: 16 KiB in-use
[ LOG ] Vfs_Allocator: 16 KiB in-use```
this is not making snese
all those tagged allocations combined are less than the amount used by the allocators
that were processed
and if I missed tagging some, it would be in UNKNOWN
well since this actually goes through each allocated block and accumulated the sizes that way
I'm going to assume those other numbers are buggy
when obos can run managarm inside qemu/kvm
tomorrow
/*
* include/slab.h
*
* Copyright (c) 2024 Omar Berrow
*/
#pragma once
#include <stdint.h>
#include <stddef.h>
// To be defined by user.
// Read-Write No-Execute
extern void *slb_map(size_t size);
extern void slb_unmap(void* base, size_t size);
typedef struct slab_allocator slab_allocator_t;
int slb_init(slab_allocator_t* state);
void* slb_alloc(slab_allocator_t* state, size_t size);
void* slb_calloc(slab_allocator_t* state, size_t objs, size_t szObjs);
void* slb_realloc(slab_allocator_t* state, void* blk, size_t newsize);
void slb_free(slab_allocator_t* state, void* blk);
void slb_getsize(slab_allocator_t* state, void* blk, size_t* sz);```
im absolutely terrible at algorithms
this has changed heavily
so far
now the actual allocation api is the same because idk how I would change it
can you overload the new operator to take an extra argument
in C, no
like for what oberrow is doing
in C++, no
doubt
oh wait nvm
nice
#ifndef CACHE_SIZE_DEFAULT
# define CACHE_SIZE_DEFAULT 4096
#endif
#ifndef slb_popcount
# error Define slb_popcount. With GCC C extentions, this looks like __builtin_popcountll.
#endif
#ifndef slb_bsf
# error Define slb_bsf. With GCC C extensions, this looks like __builtin_clzll.
#endif
#ifndef slb_bsr
# error Define slb_bsr. With GCC C extensions, this looks like __builtin_ctzll.
#endif
#ifndef SLB_ALIGN
# error Define SLB_ALIGN
# define SLB_ALIGN(struct_, align_to)
#endif
// To be defined by user.
// Read-Write No-Execute
extern void *slb_map(size_t size);
extern void slb_unmap(void* base, size_t size);
typedef struct slab_allocator *slab_allocator_t;
// Returns sizeof(struct slab_allocator)
size_t slb_allocator_size();
// NOTE: This is not thread-safe!
// Thread-safety must be added on top of these APIs.
// Returns zero on success, one on failure.
// maxSlabSize: The maximum slab size; must be a power of two greater than 32, and less than cacheSize. Hard limit is 0x40000.
// cacheSize: The cache size; must be a power of two greater than maxSlabSize. If zero, CACHE_SIZE_DEFAULT is assumed. Hard limit is 0x40000
int slb_init(slab_allocator_t state, size_t maxSlabSize, size_t cacheSize);
void* slb_alloc(slab_allocator_t state, size_t size);
void* slb_calloc(slab_allocator_t state, size_t objs, size_t szObjs);
void* slb_realloc(slab_allocator_t state, void* blk, size_t newsize);
void slb_free(slab_allocator_t state, void* blk);
void slb_getsize(slab_allocator_t state, void* blk, size_t* sz);```
now the header is that
doesnt that conflict with placement new syntax
idk how that works
ah ok nice that u can overload that
bro read the slab paper
no
that is not a slab 😭
it's something
SLOBOS
I think SLOB is the slab implementation Linux uses for embedded
Yup
which I'm hoping will be faster than whatever shit I have rn
call it slop
How is it going
Obos progress died for a couple days
Today I need to finish some school work
And prove my friend wrong
He thinks I can't write a Morse code translator in one day
its literally a lookup table to ascii char?
From English to Morse, so other way around
But yeah
I dare you to work on obos more I bet you couldn't do it 
I will after making that stupidly simple thing
i bet u cant make the next year the year of obos desktop
he challenged me specifically to get it to work on an arduino
void print_morse(const char* morse)
{
for (int i = 0; morse[i]; i++)
{
digitalWrite(PULSE_PIN, HIGH);
delay(pls);
digitalWrite(PULSE_PIN, LOW);
switch(morse[i])
{
case '.':
delay(dit);
break;
case '-':
delay(dah);
break;
case '/':
delay(spc);
break;
default: break;
}
}
}
void serialEvent()
{
int recv = Serial.read();
if (recv == -1)
return;
if (recv >= 127)
return;
const char* ent = table[recv];
Serial.write(ent);
Serial.write(" ");
print_morse(ent);
}```
which was easy-ish
I also decided to mess around with power states so I could get an equivalent of x86's hlt instruction
table is just an ascii -> morse lookup table
const char* table[128] = {
0,0,0,0,0,0,0,0, // 0-7
0,0,0,0,0,0,0,0, // 8-15
0,0,0,0,0,0,0,0, // 16-23
0,0,0,0,0,0,0,0, // 24-31
"/", 0,0,0,0,0,0,0, // 32-39
0,0,0,0,0,0,0,0, // 40-47
"-----",".----","..---","...--","....-",".....","-....","--...", // 48-55
"---..","----.",0,0,0,0,0,0, // 56-63
0,".-","-...","-.-.","-..",".","..-.","--.", // 64-71
"....","..",".---","-.-",".-..","--","-.","---", // 72-79
".--.","--.-",".-.","...","-","..-","...-",".--", // 80-87
"-..-","-.--","--..",0,0,0,0,0, // 88-95
0,".-","-...","-.-.","-..",".","..-.","--.", // 96-103
"....","..",".---","-.-",".-..","--","-.","---", // 104-111
".--.","--.-",".-.","...","-","..-","...-",".--", // 112-119
"-..-","-.--","--..",0,0,0,0 // 120-127
};```
now this is the actual table, beautiful, isn't it
ok I was working on a new allocator last time I was here
so now I'll work on that more
ok I fixed some bugs with it
now for the real test case, uacpi
(I couldn't be bothered to write a proper test case)
((but this is probably good enough))
why are u rewriting it again
speed
this one is slow as balls
as in the old one
that is in use for obos
it's like O(n) to allocate, with n being the amount of allocated regions in the allocator
i thought it was a normal slab allocator
yes
I made it with the goal of it not crashing
which is going well
but as for its speed...
this allocator crashes after a bit of uacpi
struct slobos* slobos = (void*)((uintptr_t)blk & ~(state->cacheSize-1));```
I have this line
to get a struct slobos from an allocation
now, if state->cacheSize were the page size, it should work
but it isn't
and since the slobos isn't guaranteed to be aligned to that margin, that line breaks
and idk how to fix it
why are they called slobos
Because I didn't want to read the slab paper, and wanted to make a slab allocator from what I thought was a slab allocator
slopos
Then abbix comes in and says not a slab allocator
yes
Wasn't that me
idk I did too
Slobos is my idea anyway
Very much in line with the impl 
You suggested the name
Abbix said it wasn't a slab allocator
Maybe I should call it slup
No.
slop os
slob on my oberrow
boo
after having fixed the bug with freeing
I think it passes uacpi test
the allocator
there was one error, but that was because I didn't load any ssdts
loading ssdts fixed that
now to port this to obos
now unfortunately, this allocator will probably never support tagging
as the only metadata it has on an allocation is that it exists in a struct slobos somewhere
but because of that it (probably) uses a lot less memory than it actually needs
https://github.com/OBOS-dev/slobos/
I pushed that allocator
to github
I ported the allocator to obos and wrote the neccessary glue code
now I just gotta use it somewhere
aaand it page faults almost immediately
I am able to get it to run a bit further
until it page faults again

but I am 75% sure the page faults are a result of how I configured the allocator in this case
and not an allocator bug
ok now it got to uacpi init
where it hangs randomly
id blame uacpi tbh
As a romanian I suggest you change that repo's name, its too close to the word sloboz
Which means...
a not so good way of saying "c*m"
bruh
oh fun fact: basically all work I've done on obos for the past two weeks has been done using nano
why would you do that to yourself
because I couldn't bother configuring clangd for the two other copies of obos I have
you use cmake right?
yes
then clangd is easy
and I also couldn't bother setting up my ide
what ide?
ah
the KDE editor thing
I know what it is, I've used KDE before
it has LSP support, but with how I have it, it's pretty dodgy
why not use vscode or similar
you can get all the jetbrains ones using an open source license or a student license. They can be a bit buggy with clangformat though
emacs :^)
there is always good old vim (or neovim)
remove the 'good' part /j
nano 💀
needed a text editor for "slight changes"
I wrote that allocator using nano
53 files changed, 356 insertions(+), 180 deletions(-)```
they don't offer them for open source projects anymore (or well they do but only for bigger projects)
qwinci is alive????
isnae!!
when have I not been alive lol
tomorrow /j
🤨
oberrow what do you have planned
do not the qwinci
my debian install seems to be completely fucked
so I am reinstalling it
be back in a bit
Uh oh
deb boot strap decided to die on me
In the middle of install
Luckily debian still booted
just reinstalled debian
Oh yeah, that starts next year
do not the qwinci
kk I'm back
time to get back to pci interface
how fun, amiright
fuck it
I am refactoring the kernel entry
and init
refactoring how?
well for one
all timekeeping shit is in entry.c for some stupid reason
I moved that out of there
I said many moons ago that with the PCI interface redesign, I also make the ahci support multiple controllers
which has now been put off as a TODO
(aka never will do)
ok time to get back to doing this 
ok ahci driver ported
to new pci interface
except it's not fully done
so nothing will uhh
actually work
does it support suspend now
in the ahci driver
you see, everything is stubbed
in the new pci thing
oh wait it isn;t
*isn't
most stuff is
not all
I can update a resource in the pci config space
but I can't actually
identify any pci devices
and populate the trees n'stuff
4-5 months ago, I said I would be in userspace by the end of the month

Lol
as in, bash or mlibc port
Well if you actually keep working
if even astral has came back to life
Astral is about to have full self hosting once gcc links
Chrome next
Not bad
typedef struct pci_bus {
uint8_t busNumber;
pci_device* devices;
size_t nDevices;
struct uacpi_namespace_node* acpiNode;
} pci_bus;```
when I'm initializing this, I am wondering whether I should probe the bus twice, once to see the device count, and then initialize the actual devices, or to just realloc(devices) for each new device
forgor why
probably because I won't be adding to the list after the bus is initialized
Id do a linked list unless performance critical
so insert and deletion isn't really important
why do you need this
abstraction
this is bus iteration time
I previously had no sane pci interface
just some irq stuff
and I'm not probing drivers either
why do you need to keep a list of devices
rn
so I can probe drivers later
Restoring state and bars after resume from suspend for one
do probing when iterating the bus?
boooring
same thing here
also this
just do reiteration
I needed to keep all pci devices' config in memory, otherwise I wouldn't be able to use them after resume
Why would the config be dead lol
Config is alive but bars are zeroed
So u can still enumerate them
gcc links, its just that libgcc configure (or build, I forgot) is fucked atm because of the test -x "" thing
what about binutils
works, I compiled it once iirc
NaN
bruhhhhhhhh
I have to relearn everything I figured out
about bars
and detecting their existance
actually
no
ignore that
So I wanna do osdev
But I have to do homework
Now the question is what do I do
The correct answer is homework
But instead I will be flipping a coin
Tails is homework
Heads
Aw shucks
Guess I gotta do osdev now.
if (!module)
{
OBOS_Warning("Could not load driver %s. Status: %d\n", module->name, OBOS_STATUS_NOT_FOUND);
if (namelen != len)
namelen++;
iter += namelen;
continue;
}```
oops
well more like everything PCI
but anyway
fixed
I have BAR info now
in the pci resource list thingy
[ DEBUG ] Arch_KernelMainBootstrap: Initializing PCI bus 0
[ DEBUG ] 00:01:00: Initialized 32-bit, prefetchable BAR (BAR 0). BAR ranges from 0x00000000fd000000-0x00000000fdfffff0
[ DEBUG ] 00:01:00: Initialized 32-bit BAR (BAR 2). BAR ranges from 0x00000000febd4000-0x00000000febd4ff0
[ DEBUG ] 00:02:00: Initialized 32-bit BAR (BAR 0). BAR ranges from 0x00000000feb80000-0x00000000feb9fff0
[ DEBUG ] 00:02:00: Initialized 32-bit BAR (BAR 1). BAR ranges from 0x00000000feba0000-0x00000000febbfff0
[ DEBUG ] 00:02:00: Initialized I/O BAR (BAR 2). BAR ranges from 0x000000000000c040-0x000000000000c050
[ DEBUG ] 00:02:00: Initialized 32-bit BAR (BAR 3). BAR ranges from 0x00000000febd0000-0x00000000febd3ff0
[ DEBUG ] 00:1f:02: Initialized I/O BAR (BAR 4). BAR ranges from 0x000000000000c060-0x000000000000c070
[ DEBUG ] 00:1f:02: Initialized 32-bit BAR (BAR 5). BAR ranges from 0x00000000febd5000-0x00000000febd5ff0
[ DEBUG ] 00:1f:03: Initialized I/O BAR (BAR 4). BAR ranges from 0x0000000000000700-0x0000000000000730```
Nice
static void initialize_capability_resources(pci_device* dev)
{
}```
now all that's left is this
which simply formulates a list of PCI capabilities
and puts them in the pci resource list
of the device
then I need to implement the more advanced pci initialize thing
Drv_PCIInitialize()
which initializes other buses
then I need to implement Drv_PCIUpdateResource
which simply reads the actual value of a resource in the config space, and updates the resource to that value
then I want to add PCIe support
then I will be changing my "pnp" thing to support the new PCI interface
done this
and I also added some more logs
becuz why not
for one device:
[ DEBUG ] PCI: 00:1f:02: Device HID: 01:06:01, Vendor ID: 0x2922, Device ID: 0x8086
[ DEBUG ] PCI: 00:1f:02: Initialized I/O BAR (BAR 4). BAR ranges from 0x000000000000c060-0x000000000000c070
[ DEBUG ] PCI: 00:1f:02: Initialized 32-bit BAR (BAR 5). BAR ranges from 0x00000000febd5000-0x00000000febd5ff0
[ DEBUG ] PCI: 00:1f:02: Found and registered MSI Capability.
[ DEBUG ] PCI: 00:1f:02: Found and registered SATA Data/Index Configuration Capability.```
imma change the capability log message
[ DEBUG ] PCI: 00:1f:02: Device HID: 01:06:01, Vendor ID: 0x2922, Device ID: 0x8086
[ DEBUG ] PCI: 00:1f:02: Initialized I/O BAR (BAR 4). BAR ranges from 0x000000000000c060-0x000000000000c070
[ DEBUG ] PCI: 00:1f:02: Initialized 32-bit BAR (BAR 5). BAR ranges from 0x00000000febd5000-0x00000000febd5ff0
[ DEBUG ] PCI: 00:1f:02: Found MSI Capability.
[ DEBUG ] PCI: 00:1f:02: Found SATA Data/Index Configuration Capability.
[ DEBUG ] PCI: 00:1f:02: Device has IRQ capabilities.```
Frick
It hangs on real hw
it hangs somewhere in the BAR initalization code
it could be a bug with how I handle 64-bit bars
since it says it initialized a 64-bit bar
then it simply hangs
BAR0 of the device at 00:02:00 was a 64-bit bar
therefore it should be skipping BAR1 since there isn't one
then it goes on to BAR2
I'm gonna add some printf
Which indeed happens
bruhhhh
why does it hang
unless I accidentally mess something up causing the framebuffer to stop working properly
check serial vro
ah yes
Are you overwriting the fb bar to check size?
