I will check serial
#OBOS (not vibecoded)
real pecan
You know u cant just write into bars randomly right
flint idol
probably
torpid wigeon
without a serial bar
wdym
real pecan
U have to disable memory decode
flint idol
U have to disable memory decode
I do
real pecan
Do u reenable it correctly?
flint idol
I save the previous value of the cmd register
then restore after reading the bar size
uint64_t cmd_register = 0;
DrvS_ReadPCIRegister(dev->location, 0x4, 4, &cmd_register);
volatile uint64_t old_cmd_register = cmd_register;
cmd_register &= ~0b11;
DrvS_WritePCIRegister(dev->location, 0x4, 4, cmd_register);```bro does not have a serial port
flint idol
```c
uint64_t cmd_register = 0;
DrvS_ReadPCIRegister(dev->location, 0x4,...
that's before messing with the bar
torpid wigeon
actually, i could check for you 
flint idol
that's before messing with the bar
after
DrvS_WritePCIRegister(dev->location, 0x4, 4, old_cmd_register);```so I think I reenable it properly
torpid wigeon
let me see if i have a db9 cable
flint idol
but first I need to actually
make a serial log backend
for obos
which I can do quickly
real pecan
I do
You're still writing to the framebuffer when u disable it
So u die because of that probably
real pecan
U sure
flint idol
I am 90% sure I don't
uint64_t cmd_register = 0;
DrvS_ReadPCIRegister(dev->location, 0x4, 4, &cmd_register);
volatile uint64_t old_cmd_register = cmd_register;
cmd_register &= ~0b11;
DrvS_WritePCIRegister(dev->location, 0x4, 4, cmd_register);
// Write all ones to the BAR.
// TODO: Do we need to do anything different for 64-bit bars?
DrvS_WritePCIRegister(dev->location, 0x10+bar*4, 4, ~0L);
// Decode size.
uint32_t sz = 0;
uint64_t tmp2 = 0;
DrvS_ReadPCIRegister(dev->location, 0x10+bar*4, 4, &tmp2);
sz = (uint32_t)tmp2;
sz = (~sz & 0xfffffff0);
// Write back old values.
DrvS_WritePCIRegister(dev->location, 0x10+bar*4, 4, tmp);
DrvS_WritePCIRegister(dev->location, 0x4, 4, old_cmd_register);
resource->bar->size = sz;```
all other cpus are idleAlso the logic for 64 bit bars needs to be careful as in the order in which u do this
flint idol
well I restore the BAR's old value before restoring the cmd register's old value
unless you mean something else
flint idol
indeed
flint idol
I don't even touch the higher-half of the 64-bit bar when getting its size
real pecan
Wtf
flint idol
thus the
// TODO: Do we need to do anything different for 64-bit bars?```Yeah that's not uhh
white mulch
I mean is it even really necessary?
real pecan
Yes
You get a bogus size otherwise do u not
Idk I just did what Linux does
And it worked fine
flint idol
@torpid wigeon take obos iso with serial logs (at least I hope so)
real pecan
Ohh
torpid wigeon
still looking for a serial cable
real pecan
Connect to brain and interpret the bits
flint idol
let me make sure
torpid wigeon
kms
flint idol
it's even printing on serial
flint idol
wut why is it not printing anything on serial
white mulch
You get a bogus size otherwise do u not
I am pretty sure that you don't unless the bar would have a size that doesn't fit in the first reg (as the device just clears the bits that are the offset to its space and that's where the size is calculated from)
flint idol
wut why is it not printing anything on serial
unless
torpid wigeon
show serial code
torpid wigeon
flint idol
so you should be able to get serial logs
real pecan
I am pretty sure that you don't unless the bar would have a size that doesn't fi...
Maybe
flint idol
So when I decided to skip getting the size of 64 bit bars
It worked
The framebuffer didn't die
It hangs later in uacpi
Mysteriously
real pecan
Yeah your 64 bit bar handling is borked probably
flint idol
Maybe overwriting the lower half of the 64 bit bar
Sets the higher half to zero
So I need to restore that too
trying that rn
Nop
flint idol
after having found a pci spec
pci 3.0
I found out that I need to handle 64-bit BARs differently
64-bit (memory) Base Address registers can be handled the same, except that the second
32-bit register is considered an extension of the first; i.e., bits 32-63. Software writes
0FFFFFFFFh to both registers, reads them back, and combines the result into a 64-bit value.
Size calculation is done on the 64-bit value.
That fixes it
@real pecan I heard you saying something about more eval shorthands in new uacpi
is there one to evaluate an integer?
I see uacpi_eval and uacpi_eval_typed
real pecan
look harder
flint idol
oki
real pecan
there's literaly eval_integer and eval_simple_integer
flint idol
just updated uacpi
to the newest commit
I did do that before, but it was for testing purposes only
in doing this, I decided to use the more precise way of measuring time in my kernel
timer_tick CoreS_GetNativeTimerTick();
timer_tick CoreS_GetNativeTimerFrequency();
uacpi_u64 uacpi_kernel_get_nanoseconds_since_boot(void)
{
static uint64_t cached_rate = 0;
// NOTE: If our frequency is greater than 1 GHZ, we get zero for our rate.
if (obos_expect(!cached_rate, false))
{
cached_rate = (1*1000000000)/CoreS_GetNativeTimerFrequency();
if (!cached_rate)
OBOS_Panic(OBOS_PANIC_FATAL_ERROR, "uACPI: Conversion from a native timer tick to NS failed.\nNative timer frequency was greater than 1GHZ, which is unsupported. This is a bug, report it.\n");
}
return CoreS_GetNativeTimerTick() * cached_rate;
}
the difference is that this function returns the hpet's counter directly (on x86-64)
timer_tick CoreS_GetTimerTick()
{
if (!cached_divisor)
cached_divisor = Arch_HPETFrequency/CoreS_TimerFrequency;
return Arch_HPETAddress->mainCounterValue/cached_divisor;
}```vs
OBOS_EXPORT timer_tick CoreS_GetNativeTimerTick()
{
if (obos_expect(!Arch_HPETAddress, false))
return 0;
return Arch_HPETAddress->mainCounterValue;
}
OBOS_EXPORT timer_tick CoreS_GetNativeTimerFrequency()
{
return Arch_HPETFrequency;
}```On real hw uacpi initializes with 26636 ops/s
But still hangs after a bit
I have a feeling I forget to zero a spinlock or smth
Which was not the problem
Although I did forget to do that somewhere
So at least I found a problem
The way I solved it before is by not solving it
It just stopped manifesting itself
After a few days
I found the buf
*bug
And also now suspend triple faults on real hw again
Nvm
Something else triple faults
what happens:
Calling FAT driver entry
Triple fault (unknown source)
OR
Calling FAT driver entry
infinite kernel panic (until the stack overflows)```btw obos on vanilla seabios hangs
when shutting down
after suspend
because of a bug with seabios' resume
my seabios has a patch for that
flint idol
what happens:
```
Calling FAT driver entry
Triple fault (unknown source)
```
OR
...
Ok I fixed this bug by simply removing the fat driver's entry point
Since it was not needed
time to restore PCI stuff after suspend
that nearly works
although there is one teensy problem
I never restore the interrupt pin/number fields
in the PCI space
so I need to do that quickly
the framebuffer does indeed get restored on qemu!
when I restore PCI stuff
@white mulch did you need to do anything extra to get the framebuffer to work after resume from suspend on qemu?
other than restoring the BARs
although I need to fiddle with the qemu window a bit to get the changes to work
white mulch
<@379250891838193667> did you need to do anything extra to get the framebuffer t...
yes the bochs vbe stuff
flint idol
Weird how I didn't need to do that
Was the framebuffer working, but you needed to move the qemu window/resize it
For you to see the changes
white mulch
I don't remember, I can test rq
real pecan
perhabs bochs re-init just forces this update
white mulch
Was the framebuffer working, but you needed to move the qemu window/resize it
yes I think
flint idol
Hmm ok
white mulch
do you also have that or does it fully work without doing anything?
as in without moving/resizing the window
white mulch
then its likely the same thing that I had before I implemented that stuff yeah
flint idol
now my question is, if I print something to the framebuffer again, will I still need to resize the window
which I want to test
flint idol
yup
I used the qemu nmi command to get a kernel panic
and I need to resize the window
flint idol
you should just do the proper restore
code?
white mulch
well you basically need to setup the vbe registers that are detailed in eg. the osdev wiki page or linux and then write to some random vga registers (I don't really know what they are for, I just got it from what linux did) https://github.com/Qwinci/crescent/blob/main/src/dev/gpu/bochs_vbe.cpp#L92
flint idol
frick
you're using gpl
3.0
can you chagne your license to mit so I can copy ur code
/j
white mulch
eh you can still copy it, I don't really care
and its likely not going to be exactly the same anyway
flint idol
tru
to do this I
am just going to make a driver for "bga"
like a kernel module
or maybe I'll call the module 'bochs_vbe'
and it'll just contain some suspend and wake callbacks
as well as whatever else I need to do
(aka nothing)
white mulch
you can implement double buffering using it
white mulch
idk if that would work but at least you can make it use a different region of the "vram" using the vbe offset regs
thick jolt
in doing this, I decided to use the more precise way of measuring time in my ker...
Cached_rate?
thick jolt
immmm not gonna question thisssssss
flint idol
technically obos has its first gpu driver
thick jolt
nah seriously????
flint idol
I mean, if you count bochs vbe as a gpu
totalling 155 loc
it has these features:
- restoring framebuffer info after waking from suspend
- detecting the thing's existance in the first place
flint idol
idk if that would work but at least you can make it use a different region of th...
are back buffers in VRAM in real cases, or are they usually in normal RAM
flint idol
it has these features:
- restoring framebuffer info after waking from suspend
- ...
maybe I should add modesettingf
hmmmmmmmmmmmmmm
thick jolt
it has these features:
- restoring framebuffer info after waking from suspend
- ...
oh i see
flint idol
yeah basically the only reason for its existence is because I wanted the framebuffer to work properly after waking from suspend in qemu
real pecan
maybe I should add modesettingf
its like writing into 3 regs
flint idol
yeah
which is why I said maybe I should add it
if it were any more than a couple regs
I wouldn't have wanted to add it
flint idol
it would be kinda cool if I could implement having multiple TTYs using the xoffset/yoffset feature of the bochs VBE "gpu"
anyway, I need to get back on task
flint idol
yup
real pecan
it would be kinda cool if I could implement having multiple TTYs using the xoffs...
overkill
white mulch
are back buffers in VRAM in real cases, or are they usually in normal RAM
on "proper" gpus that have actual vram they are usually in vram too, it doesn't really make any sense to have them in ram as the gpu is what writes/reads to/from them anyway
flint idol
uh oh
was debugging a triple fault that was caused by a stack overflow
of infinite panics
and this is what I got
now idk how the hell the scheduler scheduled a thread that simply isn't allocated in memory
and when I try to add a symbol file
I crash gdb
well my problem seems to have something to do with exitting threads
because when I make it not free the thread when I exit the thread
it doesn't fault
it was a race condition, it seems
if (!(--currentThread->references) && currentThread->free)
currentThread->free(currentThread);
CoreS_GetCPULocalPtr()->currentThread = nullptr;```
in between the line where it frees the thread, and where it is set to zerobasically an irq could happen in between those two lines
causing chaos
one solution is to raise the irql to masked
or to set the current thread to null before freeing it
I will choose the latter option
because I don't want to keep irqs masked for too long
flint idol
uh oh
the ahci driver stopped working
specifically
it is hanging
on read
or maybe something else is
you never know
I am having trouble with IRQs on my new PCI interface
which is the cause of the ahci driver bug
ok I fixed it
Now there is a problem when I enumerate the other buses
It just doesn't
well isn't that just delightful
I only have on ACPI node for a PCI bus
which is bus zero
even though I have a device on 02:00.0
which is bus two
flint idol
it'd be cool if I could multithread pci bus initialization
but that's useless and boring
flint idol
whenever I look in my signal implementation, I am reminded of why I don't look in my signal implementation
flint idol
I can now enumerate other pci buses
Except for one tiny thing
On bus two
It identifies the exact same device twice
Specifically a wifi controller
But I only have one of those
Therefore that's a bug
What if I just duplicated my wifi card
Wtd
*wtf
Why is there three
One on bus zero
Two on bus two
All the exact same
Of course, grub's lspci command only reports the one that is real
to conclude, obos can now create new devices
flint idol
Fixed the bug
I was trying to access a device above device 32
All I have left now is PCIe
uhhh
TODO:
branch is getting a bit too big
marker
guess I'm doing futexes now
flint idol
trust
flint idol
wut
flint idol
I might've used the terminology "object", although I have no unified object api
lean glen
Then how do your handles work
Do you just have a switch statement
For every type of object
flint idol
what I think I did
was have the object type in the handle itself
handle's value
it's easier if I just send code
lean glen
Yeah no I don't wanna read obos code
flint idol
typedef struct handle_desc
{
union {
struct handle_desc* next; // for the freelist.
struct fd* fd;
struct timer* timer;
struct dirent* dirent;
struct thread* thread;
struct process* process;
struct context* vmm_context;
struct mutex* mutex;
struct semaphore* semaphore;
struct pushlock* pushlock;
struct event* event;
struct driver_id* driver_id;
struct thread_ctx_handle* thread_ctx;
struct waitable_header* waitable;
void* generic; // just in case
} un;
} handle_desc;```Yeah so it is
flint idol
ig
lean glen
That definition is kinda cringe tho but sure
flint idol
I didn't really know much terminology
lean glen
no I mean
The struct
Ideally you have common operations for every object type
That way the system is extensible
flint idol
that is true, not even I enjoyed using it
real pecan
@flint idol did you fix 64-bit bar enumeration?
flint idol
<@841762704766140486> did you fix 64-bit bar enumeration?
Yes
real pecan
what was the bug
flint idol
I was just doing it wrong
real pecan
so what i said initially lol
real pecan
i literally said write both or u get bogus values
flint idol
And restore as well
No u said this
real pecan
You get a bogus size otherwise do u not
.
flint idol
No u said something about order
real pecan
No u said this
I said this before i even knew u ignored the upper half completely
real pecan
lol
flint idol
I will test obos on other hardware soon
real pecan
nice
flint idol
Bit late but that would be nice
I can provide a new obos iso in a few hours
Or you can build
'userspace-work'
short mortar
it would be kinda cool if my kernel isnt cursed ALL the TIME
Have a microkernel, so it's user space half of the time 
flint idol
@real pecan
Tested on some hardware
And you seem to have a bug with ur table parsing
Although it does boot which is nice
real pecan
more like your tables have non printable characters
flint idol
Or that
real pecan
can u send the dump btw
flint idol
btw is this new hardware?
2013
flint idol
Same one with the hyper bug
flint idol
did u not have it before
No I had it
flint idol
Same one with the hyper bug
The framebuffer bug
That caused it to die getting a framebuffer
flint idol
Nope
real pecan
what are u using
flint idol
what are u using
My own dumb text renderer
real pecan
it has kerning?
flint idol
I will port flanterm for TTYs probably
flint idol
it has kerning?
Considering idk what that is, probably not
real pecan
well its clearly not respecting string precision even
so i wodner if those artifacts are also its skill issue
it probably reads past the string end
disable your printf and reboot
flint idol
disable your printf and reboot
That is many work
I would need to go upstairs
Then change the log level
real pecan
anyway its an stb printf bug
flint idol
Then put iso on usb
real pecan
frigg also had this bug
real pecan
strings with %.4s for example arent supposed to read past 4 characters
flint idol
Important thing is that it works
real pecan
anyway this printf sucks
flint idol
Kinda weird, maybe I can look into using another one
real pecan
nanoprintf is what other people use
flint idol
Wait wut
There is 11932kib non pageable
Memory
But 11732 kib committed
The 1052kib pageable
Which does not add up
real pecan
btw did u press the powerbutton or something similar
idk what 0x02 is supposed to mean, its not status change and linux just ignores the event in this case
flint idol
btw did u press the powerbutton or something similar
Nope
real pecan
if u send the dump ill take a look
flint idol
Wait a bit
real pecan
sure
flint idol
Like 15 minutes
vale nymph
nice windows key
flint idol
ur welcome
real pecan
[000h 0000 4] Signature : "BGRT" [Boot Graphics Resource Table]
[004h 0004 4] Table Length : 00000038
[008h 0008 1] Revision : 00
[009h 0009 1] Checksum : 10
[00Ah 0010 6] Oem ID : " ;d "
[010h 0016 8] Oem Table ID : ""
[018h 0024 4] Oem Revision : 01072009
[01Ch 0028 4] Asl Compiler ID : "AMI "
[020h 0032 4] Asl Compiler Revision : 00010013
cursed
real pecan
yeah its just stb printf choking on string precision
flint idol
I'll just switch to nanoprintf then ig
real pecan
but ;d is an interesting OEM ID
flint idol
indeed
flint idol
yeah
real pecan
thats what causes those notifies
ig it wants to tell u something
but linux ignores it as well
flint idol
my computer is trying to tell me something
real pecan
Scope (_SB.PCI0.EHC1)
{
Method (_PRW, 0, NotSerialized) // _PRW: Power Resources for Wake
{
Local0 = UPRW ()
If ((Local0 == 0x03))
{
Notify (PWRB, 0x02) // Device Wake
Return (Package (0x02)
{
0x0D,
0x03
})
}
EHCI specifically
it tells u power button woke up or rsomething lol?
flint idol
RetarBIOS
real pecan
least insane bios
flint idol
it's cool that the only pc I have that actually gives me something for PRW
is the only one without suspend
real pecan
lol
flint idol
S3 suspend
there is my laptop which I will be testing sometime in the next year
just need to fix something
flint idol
mhm
real pecan
If (SS3)
{
Name (_S3, Package (0x04) // _S3_: S3 System State
{
0x05,
Zero,
Zero,
Zero
})
}
interesting way to do it
flint idol
thus the "Firmware does not have the _S3 sleep state"
real pecan
ye
flint idol
uacpi_namespace_node* s3 = nullptr;
uacpi_namespace_node_find(uacpi_namespace_root(), "_S3_", &s3);
if (!s3)
{
OBOS_Error("Firmware does not have the _S3 sleep state\n");
return OBOS_STATUS_UNIMPLEMENTED; // bios does NOT support suspend.
}```and under something called SIOH
lean glen
retarbios never ceases to amaze
what is that
real pecan
what is that
oberrow's pc bios
flint idol
what is 0x02 
real pecan
device wake apparently
lean glen
wait is it literally called retarbios
flint idol
no lol
real pecan
@flint idol u sure u dont call _PRW twice?
weak kestrel
@flint idol mr obosman, I see that you wrote a pci interface as well. do these devices seem too few for default vmware config? I'm concerned that I missed something related to bridges
flint idol
<@841762704766140486> mr obosman, I see that you wrote a pci interface as well. ...
I haven't tested against vmware
but it looks like it's enough considering it's a vm
real pecan
ah ok that explains it
flint idol
d_state new_dstate = OBOS_DeviceGetDStateForWake(dev, state, &status);
if (obos_is_error(status))
return status;
uacpi_object* buf = {};
uacpi_eval(dev, "_PRW", nullptr, &buf);```and OBOS_DeviceGetDStateForWake gets PRW
real pecan
smh no uacpi_eval_simple_package
flint idol
wrote that code before that
real pecan
yeye
flint idol
I'll change it since it's technically safer
real pecan
how do u make sure u get a pakcage here
real pecan
lol
the typed helpers at least print out a very verbose error message about type mismatch
flint idol
d_state new_dstate = OBOS_DeviceGetDStateForWake(dev, state, &status);
if (obos_is_error(status))
return status;
uacpi_object* buf = {};
if (uacpi_unlikely_error(uacpi_eval_simple_package(dev, "_PRW", &buf)))
return OBOS_STATUS_INTERNAL_ERROR;```that's better
flint idol
```c
d_state new_dstate = OBOS_DeviceGetDStateForWake(dev, state, &status);
...
which is called here
then that also goes on to evaluate _PSW
real pecan
ah
real pecan
should be fine
flint idol
I should implement proper power resource handling soon
main problem for me related to those is that they can be shared, but obos doesn't give a rat's ass
just switched to nanoprintf
real pecan
let me know if that fixes table printing
flint idol
I'll test that rn
Wakes up num number of threads waiting on the address addr.
is the "address" an actual memory address, or is it just some id
representing a futex
wait it makes sense now
does it wait until something calls WAKE on that address
and when it gets modified
or only the former
ornate ginkgo
<@841762704766140486> mr obosman, I see that you wrote a pci interface as well. ...
You can check the logs if you want to be sure
All that info is in there
ornate ginkgo
😔
flint idol
I should probably make my futex syscall the exact same as linux'
for compatibility
turns out rtfm'ing answers my questions
This operation tests that the value at the futex word pointed to by the address uaddr still contains the expected value val, and if so, then sleeps waiting for a FUTEX_WAKE operation
on the futex word. The load of the value of the futex word is an atomic memory access (i.e., using atomic machine instructions of the respective architecture). This load, the com‐
parison with the expected value, and starting to sleep are performed atomically and totally ordered with respect to other futex operations on the same futex word. If the thread
starts to sleep, it is considered a waiter on this futex word. If the futex value does not match val, then the call fails immediately with the error EAGAIN.
for now I will implement FUTEX_WAKE and FUTEX_WAIT
until something needs more futex stuff
would linux get mad at me if I did this:
obos_status Sys_Futex(uint32_t *uaddr, int futex_op, uint32_t val, uint32_t val2, uint32_t* uaddr2, uint32_t val3);
decided to change the api a bit
split it to two syscalls
obos_status Sys_FutexWait(uint32_t *uaddr, uint32_t val, uint32_t val2);
obos_status Sys_FutexWake(uint32_t *uaddr, uint32_t val);
obos_status Sys_FutexWait(uint32_t *futex, uint32_t cmp_with, uint64_t timeout);
obos_status Sys_FutexWake(uint32_t *futex, uint32_t nWaiters);
u have syscall overloading?
flint idol
no
I was showing the final syscall
s
well this all makes sense, but I only know how to put half of it into practice
I have the waiting stuff, and comparing the values is obviously not hard, but idk how I should a futex with a struct waitable_hdr, which is the thing responsible for waiting
ugh
I still don't have VirtualLock or VirtualUnlock functions
// TODO: F****** implement virtual page locking
// Mm_VirtualMemoryLock(CoreS_GetCPULocalPtr()->currentThread->proc->ctx, futex, sizeof(*futex));```so uhh how to associate a futex with an approrpiate struct waitable_header
at first I was thinking have a hashmap of futex->waitable headers
but surely there is a better way
I could return some sort of handle representing that waitable header
and tell the user to deal with it
but then the user becomes me
managarm peoples, how does mlibc handle futexes
nvm
maybe I use this as an excuse to use monitor and mwait in my kernel
nvm
what keyronex does is just have a table
for futexes
@devout niche for this function, you say if the futex is created, it wires the page (which I think means locking it in the working set?), which I don't see ever happen
lean glen
<@391791686881247234> for [this](https://github.com/Keyronex/Keyronex/blob/6c732...
wires the page = pages it in
kmem_alloc allocates it
devout niche
<@391791686881247234> for [this](https://github.com/Keyronex/Keyronex/blob/6c732...
Used to but I changed strategy
Now I use { vm object, offset} as key
devout niche
Which is problematic as no vm object exists in the private mapping case (I manage cow after fork on a per page basis, not at object level, so fork will break it)
short mortar
Which is problematic as no vm object exists in the private mapping case (I manag...
Can't it be solved by adding an object for private mapping?
devout niche
Can't it be solved by adding an object for private mapping?
Maybe, the object would need to be carefully managed
short mortar
I have the same problem and I'm planning to just make everything a memory object, which should both simplify my vmm and also make the page tables disposable
devout niche
It has to stick around and can't be coalesced with others
flint idol
next up are vfs syscalls
I got all of these:
OBOS_EXPORT obos_status Vfs_FdOpen(fd* const desc, const char* path, uint32_t oflags);
OBOS_EXPORT obos_status Vfs_FdOpenDirent(fd* const desc, dirent* ent, uint32_t oflags);
OBOS_EXPORT obos_status Vfs_FdOpenVnode(fd* const desc, void* vn, uint32_t oflags);
OBOS_EXPORT obos_status Vfs_FdWrite(fd* desc, const void* buf, size_t nBytes, size_t* nWritten);
OBOS_EXPORT obos_status Vfs_FdRead(fd* desc, void* buf, size_t nBytes, size_t* nRead);
OBOS_EXPORT obos_status Vfs_FdAWrite(fd* desc, const void* buf, size_t nBytes, event* evnt);
OBOS_EXPORT obos_status Vfs_FdARead(fd* desc, void* buf, size_t nBytes, event* evnt);
OBOS_EXPORT obos_status Vfs_FdSeek(fd* desc, off_t off, whence_t whence);
OBOS_EXPORT uoff_t Vfs_FdTellOff(const fd* desc);
OBOS_EXPORT size_t Vfs_FdGetBlkSz(const fd* desc);
OBOS_EXPORT obos_status Vfs_FdEOF(const fd* desc);
OBOS_EXPORT struct vnode* Vfs_FdGetVnode(fd* desc);
OBOS_EXPORT obos_status Vfs_FdIoctl(fd* desc, size_t nParameters, uint64_t request, ...);
OBOS_EXPORT obos_status Vfs_FdFlush(fd* desc);
OBOS_EXPORT obos_status Vfs_FdClose(fd* desc);```then also some dirent syscalls
and mount/umount
and sync
real pecan
I got all of these:
```c
OBOS_EXPORT obos_status Vfs_FdOpen(fd* const desc...
U dont need a separate tell syscall
U can just seek(0) and have it always return the offset
flint idol
true
I also have two syscalls related to pipes
create named pipe and create pipe
can't wait to test pipes in production
without testing them at all beforehand
short mortar
It has to stick around and can't be coalesced with others
I've been thinking about it in my design, and I think that it can kinda be solved by making the kernel not allowing userspace to manage/map anonymous memory objects and then the kernel can do what it wishes with them, and they don't have to stick
flint idol
waiiiiiiiit
nvm
obos_status Sys_FdIoctl(handle desc, size_t nParameters, uint64_t request, void* parbuff, size_t parsize);```is this a good way to do ioctl
it should be variadic
but it can't be
wait wut
lean glen
ioctl is not variadic
lean glen
how do you want to make a syscall variadic
flint idol
this sure looks variadic
lean glen
this sure looks variadic
that's the libc function
flint idol
then how's the syscall defined
SYSCALL_DEFINE3(ioctl, unsigned int, fd, unsigned int, cmd, unsigned long, arg)```hmm
ornate ginkgo
Variadic syscall sounds a fun time ngl
lean glen
The prototype stands out in the list of Unix system calls because of the dots, which usually mark the function as having a variable number of arguments. In a real system, however, a system call can't actually have a variable number of arguments. System calls must have a well-defined prototype, because user programs can access them only through hardware "gates." Therefore, the dots in the prototype represent not a variable number of arguments but a single optional argument, traditionally identified as char *argp. The dots are simply there to prevent type checking during compilation.
flint idol
I just read that
ornate ginkgo
Ioctl takes a buffer
flint idol
I just realized my ioctl has highly deviated from POSIX
obos_status(*ioctl)(size_t nParameters, uint64_t request, ...);```that's how it's defined in the driver header
so a driver could have as many arguments as it wants for an ioctl command
and it's literally variadic
so it's rather I fix that
or I stay slightly deviant from POSIX
or rather
if argp is a pointer to a struct
which have my arguments
then I can make this work
short mortar
The actual syscalls don't have to match their function prototypes (?)
short mortar
Yes
flint idol
The actual syscalls don't have to match their function prototypes (?)
yeah but then I need to write annoying code in the syscall to get it to convert from the dumb struct
to the thing the actual ioctl function wants
short mortar
no you interact with libc
You call libc with posix interface, and they you do whatever you want by the time the kernel is called
lean glen
libc is the posix interface
flint idol
I'm just going to change how it's defined
I only actually use ioctl in one place anyway
lean glen
but posix defines linc functions, not how the kernel is called
yeah
so syscalls dont have to match functions
I think that's what you meant but I didnt understand the context in which you said it
short mortar
yeah
flint idol
done
devout niche
I've been thinking about it in my design, and I think that it can kinda be solve...
I had a misthink, it will be fine for only shared mappings to have a vm object
Private you can't share a futex
flint idol
obos has 45 syscalls now
wait, since astral has around 90 syscalls
obos technically has half the functionality of astral /j
🤯
flint idol
obos has 45 syscalls now
well, 10 of those are unimplemented
obos_status Sys_FdWrite(handle desc, const void* buf, size_t nBytes, size_t* nWritten);
obos_status Sys_FdRead(handle desc, void* buf, size_t nBytes, size_t* nRead);
obos_status Sys_FdAWrite(handle desc, const void* buf, size_t nBytes, handle evnt);
obos_status Sys_FdARead(handle desc, void* buf, size_t nBytes, handle evnt);
obos_status Sys_FdSeek(handle desc, off_t off, whence_t whence);
uoff_t Sys_FdTellOff(const handle desc);
size_t Sys_FdGetBlkSz(const handle desc);
obos_status Sys_FdEOF(const handle desc);
obos_status Sys_FdIoctl(handle desc, uint64_t request, void* argp, size_t sz_argp);
obos_status Sys_FdFlush(handle desc);
obos_status Sys_FdClose(handle desc);```but I am implementing them rn
thick jolt
yooo less goo
weak kestrel
```c
obos_status Sys_FdWrite(handle desc, const void* buf, size_t nBytes, s...
obos Linux binary compatibility when
short mortar
OBOS AI car driver 
real pecan
most stable car software
flint idol
and def more stable then nyaux
Come work on obos
thick jolt
u get page faults in obos land? nah we get triple faults here in nyaux land
flint idol
Trust
thick jolt
flint idol
u get page faults in obos land? nah we get triple faults here in nyaux land
Yeah like ~230 times each boot
thick jolt
Come work on obos
i aint giving up on my kernel neverrrr, but i will contribute to obos soon
flint idol
Mhm
thick jolt
Yeah like ~230 times each boot
real
thick jolt
to which nyaux has page faults on purpose :)
def
my slab allocator pooping is on purpose
swapping out to disk? nah we PAGE FAULT CR2 0xffffffff
haughty abyss
have you considered writing code that doesn't crash
short mortar
I mean you can just let kernel use any memory it wants, and when it page faults just map the page wherever it is 
thick jolt
have you considered writing code that doesn't crash
yes i have considered it and said no (im joking im gonna try to debug it later with ur memset idea or wtv)
(atm im too cold to do anything)
haughty abyss
fair enough
thick jolt
(i hate ireland)
haughty abyss
(i hate ireland)
cmon its not that bad
haughty abyss
okay fine 17 knot winds it is that bad
short mortar
I've given up at using my allocator and switched to dlmalloc because of heap corruption
And it ended up being because of my string implementation and not related to it at all
I've discovered the bug after several months
haughty abyss
lol
i rewrote my allocator due to what i thought is a malloc bug
but im pretty sure it wasnt a malloc bug at all
thick jolt
Temperature?
oh its that bad
flint idol
The weather in dublin
Is 13 degrees
For reference, a couple days ago it was -10 degrees
Here in canada
flint idol
Is 13 degrees
Btw I usually wear shorts in this weather
white mulch
lol
thick jolt
The weather in dublin
cork
white mulch
its -3c here rn, apparently -12c tomorrow
flint idol
U in the us?
white mulch
no finland
flint idol
Ah
white mulch
haven't really yet had any bigger cold days yet this winter tho
thick jolt
mhm
flint idol
And raining
white mulch
I like something between -10c and -2c in the winter as then its not too cold
thick jolt
as im typing my hands are icicles
thick jolt
I like something between -10c and -2c in the winter as then its not too cold
are u by chance a yetti
flint idol
For reference, a couple days ago it was -10 degrees
Around that time, it felt like -20
With the wind
And it was windy
thick jolt
obos support risc-v when
short mortar
You haven't been to Russia
short mortar
obos support risc-v when
RISC-V is very easy
flint idol
obos support risc-v when
Soon
short mortar
Once you find the documentation
flint idol
You haven't been to Russia
Not yet, no
short mortar
Which is in random github issues linking to google drives
flint idol
Which is in random github issues linking to google drives
This it,
short mortar
Yes, but then you have 10 other random specs
short mortar
Yes, but then you have 10 other random specs
5 different interrupt controllers (or more, a new one gets developed every day)
short mortar
bruh
thick jolt
best deal
flint idol
I would rather die than use an iPhone
thick jolt
short mortar
I don't like Apple but iPhone 14 is not a bad phone
thick jolt
ios is shit
flint idol
Advanced? Yeah advancing pricing.
flint idol
ios is shit
Jailbreak it
thick jolt
Jailbreak it
cant
short mortar
You can't
haughty abyss
buy a good phone
thick jolt
buy a good phone
ask my dad not to pressure me into buying an iphone again
haughty abyss
lololol
thick jolt
shouldve gotten a samsung z flip
haughty abyss
im google pixel gang
thick jolt
take this phone
custom rom it
done
:)
android 15
stock
not ugly samsung one ui
short mortar
Samsung is ok
shy forge
im google pixel gang
Real
weak kestrel
im google pixel gang
I have a xiaomi but I'm a pixel gang member by heart
flint idol
I might have found the most stupid lines of code in my kernel
ever written
not buggy, but dumb
nvm
I misread them
torpid wigeon
I might have found the most stupid lines of code in my kernel
main()
flint idol
how should I implement this syscall
obos_status Sys_FdWrite(handle desc, const void* buf, size_t nBytes, size_t* nWritten)```
It's rather I copy `buf` into a kernel buffer since I cannot directly access kernel memoryor I somehow make it shared memory with the kernel temporarily
the latter is a bit more difficult, although it is probably faster, since I need not copy, nor allocate, any memory
I might eventually mkae a function like "Mm_MapViewOfUserMemory"
which simply maps some user pages into the kernel address space somewhere
obos_status Mm_MapViewOfUserMemory(context* user_context, void* ubase, void* kbase, size_t nBytes, prot_flags protection, bool lock_pages);```just map it?
lean glen
yea
flint idol
so map the user buffer into the kernel address space
flint idol
or I somehow make it shared memory with the kernel temporarily
aka this
tomorrow I will be making some new vmm functions
page locking
flint idol
```c
obos_status Mm_MapViewOfUserMemory(context* user_context, void* ubase, void...
and this
lean glen
tf is page locking
flint idol
lokcing a page in the working-set
so it doesn't get paged out
I need it in a couple places
lean glen
ah
flint idol
so I figured it is finally time to implement it
lean glen
I'd just call that pinning
flint idol
that also works
concept stays the same
I will also add some flags to configure what happens to the pages when they're unmapped, but still "pinned" or "locked"
typedef enum unmap_flags {
// Default behavior.
// Defers the unmap until the pages are unlocked manually.
UNMAP_FLAGS_DEFER = 0,
// Allow the pages to be unmapped from the address space, but do not unlock the backing memory.
UNMAP_FLAGS_ALLOW = BIT(0),
// Unlocks the pages on unmap, then unmaps them.
UNMAP_FLAGS_UNLOCK = BIT(1),
} unmap_flags;```for example, I could use UNMAP_FLAGS_ALLOW in the ahci driver to ensure that pages don't get freed while there is still i/o on them (albeit the user would be stupid if they do that, but if I do not guard against it, it can cause memory corruption)
what UNMAP_FLAGS_DEFER does is make the unmap just not do anything until after the pages are unlocked
and UNMAP_FLAGS_UNLOCK unlocks the pages on unmap, then continues on as normal
flint idol
for example, I could use `UNMAP_FLAGS_ALLOW` in the ahci driver to ensure that p...
this is probably the one I'll use the most
I'll just make that the default behavior actually
// Maps user pages into the kernel address space. This can be used in syscalls to avoid copying large amounts of memory.
OBOS_EXPORT obos_status Mm_MapViewOfUserMemory(context* user_context, void* ubase, void* kbase, size_t nBytes, prot_flags protection, bool lock_pages);
typedef enum unmap_behavior {
// Default behavior.
// Allow the pages to be unmapped from the address space, but do not unlock the backing memory.
UNMAP_FLAGS_ALLOW = 0,
// Defers the unmap until the pages are unlocked manually.
UNMAP_FLAGS_DEFER,
// Unlocks the pages on unmap, then unmaps them.
UNMAP_FLAGS_UNLOCK,
} unmap_behavior;
// Locks pages from base to base+sz in the working-set.
// If space is not avaliable in the working-set, pages are removed until space can be satisified.
// If the working-set's capacity is too small, then it can be inflated until the pages are unlocked.
// The unmap_
OBOS_EXPORT obos_status Mm_VirtualMemoryLock(context* ctx, void* base, size_t sz, unmap_behavior unmap_action);
// Unlocks pages from base to base+sz from the working-set.
// If the pages caused the working-set capacity to be inflated, then it is deflated once again.
OBOS_EXPORT obos_status Mm_VirtualMemoryUnlock(context* ctx, void* base, size_t sz);```TODO for tomorrow: Implement those
soon I might profile obos to find out how I can make it faster
flint idol
soon I might profile obos to find out how I can make it faster
from some quick logging, it is not because the scheduler is giving the idle thread too much execution time
anyway I am now going to sleep
so I don't write delusional code
short mortar
@flint idol #1061407633745125397 message this just hangs with no image
(also @real pecan ?)
real pecan
<@841762704766140486> https://discord.com/channels/440442961147199490/1061407633...
Nice
This means its an obos bug not hypers
flint idol
<@841762704766140486> https://discord.com/channels/440442961147199490/1061407633...
Thanks then
flint idol
<@841762704766140486> https://discord.com/channels/440442961147199490/1061407633...
Can we debug in 8-9 hours
?
Btw does this PC have an amd cpu
real pecan
yes
flint idol
Do cpuld leafs change between amd and intel
real pecan
yes
flint idol
How much?
flint idol
If it's enough to falsely report an instruction/feature to be supported
Then it is possible it triple faults before getting to the kernel's c main function
flint idol
I couldn't get sysenter to now work on AMD
Does rdrand/rdseed work?
short mortar
What are you testing anyway
flint idol
Does rdrand/rdseed work?
These
flint idol
Ok, so it can't be that
short mortar
what's the command
flint idol
disturbing the peaceeeee
Leave
flint idol
what's the command
Well qemu
thick jolt
oberrow when are u free to play portal 2 with me
short mortar
Though it's nested virtualization
flint idol
Ok
short mortar
thick jolt
nyaux faster real
short mortar
Have you ran it baremetal on your hw?
short mortar
@flint idol
short mortar
I mean you too
thick jolt
short mortar
obos kernel is having issues running on my laptop
Can you test power button? #1236769772805554206 message
@thick jolt
thick jolt
okay hold on
i still need to test something for mr linux mantainer armin wolf
who i forgot to test a driver for
🤦♂️
after this however SOMEONE HAS TO PLAY PORTAL 2 WITH ME
😡
flint idol
Infy spotted in obos thread
real pecan
i still need to test something for mr linux mantainer armin wolf
This is just a student
thick jolt
This is just a student
how
real pecan
I've seen him in acpica threads
flint idol
Do they merge them, or are they merged for them
real pecan
What is that convo about btw
real pecan
WTH does that do
thick jolt
its done via windows wmi
flint idol
WTH does that do
Optimizes stuff, I assume
thick jolt
no not really
it gives more power to the cpu + gpu
and such etc
theres 4 modes
eco, quiet, balanced, perfoamnce and turbo
sorry 5
if its not in one of these modes its in its default state
where it runs like ass
flint idol
eco, quiet, balanced, perfoamnce and turbo
Use turbo to run nyaux
thick jolt
only reason im on windows
short mortar
My laptop also has that
thick jolt
lmao
flint idol
To get max uacpi perf
short mortar
But it can be toggled from bios
flint idol
ok the allocator is a big thing in perf here
using a bump allocator I quadruple the perf of uacpi
holy shit
why the hell is my scheduler so slow
I doubled op/s when I raised the irql to dispatch in uacpi init
devout niche
I doubled op/s when I raised the irql to dispatch in uacpi init
how do you implement irql?
flint idol
cr8
devout niche
i found frequent writing of %cr8 had a deleterious effect on performance
devout niche
and this was much improved by deferring %cr8 writes until such a time as an interrupt of a level > current ipl happened
(then you note you did so, and the ipl lower function writes the lower value to %cr8 again)
white mulch
probably because vmexit
it should be able to be virtualized if supported by the cpu but idk if qemu/kvm does that
flint idol
with these two changes, I get 200k ops/s
which says two things:
- my allocator is prime shite
- my scheduler is slow
my scheduler's algorithm probably isn't too bad
scratch that, it's terrible
it takes 8.4 us
to get the scheduler to schedule the exact same thread
combine that with a thread quantum of 8 with a 1000 hz scheduler tick
every second, the scheduler spends a total of ~1 ms scheduling
idk about you, but that seems slow
short mortar
How do you measure that?
flint idol
How do you measure that?
timer_tick end = CoreS_GetNativeTimerTick();
CoreS_GetCPULocalPtr()->last_sched_algorithm_time = end-start;```Also, what is your scheduler doing?
flint idol
Also, what is your scheduler doing?
idk
I'm rewriting the algorithm part
wtf, it's even slower than that
~28 us per schedule
which means 3.5 ms out of one second is being used scheduling
and this does not include any context switching stuff
flint idol
my spinlocks seem to give me trouble with consistency
when I no-op those, the ops/s count is more or less consistent
otherwise it can drop randomly
flint idol
K I am back
I can now test obos on my laptop
Because I finally got a new charger (been holding that off for months)
damn it
obos hangs
real pecan
is that a regression
flint idol
in obos yes
real pecan
obos has no bugs
flint idol
definitely not
flint idol
obos hangs
the good news about this is that my cousin's laptop also had this bug
I guess obos and lenovo don't like each other
real pecan
at least it doesnt triple fault
flint idol
yes
hold on I think I might know the bug
might be with hyper-threading
as I suspected, it is
there are 8 threads in total
but obos only starts up 4 cores
fixed the bug
if (s_nLAPICIDs == 255)
break; // make continue if more types are parsed
+if (~mLapicId->flags & BIT(0))
+ continue;
s_lapicIDs[s_nLAPICIDs++] = mLapicId->apicID;
damn it
the ahci driver hangs
reading something
being able to hook up a debugger would be reallllly nice rn
@real pecan my laptop has an ec
which is le cool
real pecan
well does it get events or not
flint idol
idk anything
suspend does not work
it rather hangs somewhere
or gets to suspending but never does
real pecan
needs debug prints
real pecan
wdym lol
flint idol
it was 96mb