#OBOS (not vibecoded)

1 messages ยท Page 30 of 1

thick jolt
#

probs ur other codebase relys on that or smthin

#

mmm

#

i could give waitable objects a new field

#

called interrupted

#

and check if that was enabled

#

but again idk that may be stupid too

#

where is the waitable_header structure defined

#

i dont have clangd working

#

and i dont want to bear -- make the project

#

or whatever build system u use

#

hold on i have a search feature

#

found it

#

omar do u think adding a new field called interrupted is a good idea

#

i want to check this againist you

#

whenever u come back let me know

#

im not gonna touch anything until i know what i am thinking of is a good idea or no, i really do NOT wanna nyauxify obos

#

code is very well written btw

#

ill give you this

flint idol
#

lgtm

#

that's what I was thinking too

#

but I didn't wanna tell you the solution

weak kestrel
#

@thick jolt did you get muted

thick jolt
#

yes

#

๐Ÿ˜ญ

weak kestrel
#

L

flint idol
#

a note: not all waitable objects have use_signaled=true

#

which causes the signaled field to be ignored

#

(I really need to document my code)

thick jolt
#

im adding it

#

oh right

#

okay but its still complaining

#

even after i changed it to 0

#

weird?

flint idol
#

it's one bit

#

so : 1

white mulch
#

why would you have a field with 0 bit width

thick jolt
#

OHHHH

white mulch
#

you can't store anything in 0 bits

thick jolt
#

sorry i did not understand what that meant

#

i dont do those in C

weak kestrel
flint idol
white mulch
weak kestrel
#

:p

thick jolt
flint idol
#

they're just bad

thick jolt
#

yea probs

#

anyways

#

now that i added this field

#

in abort_wait

flint idol
#

for stuff like fixed-bit structures

thick jolt
#

what i could do is just make interruptable true or whatever

#

signal the object

#

and then we can check

flint idol
#

and not make the user set that field then call signal threads

thick jolt
flint idol
#

ah okay

thick jolt
#

whats the naming scheme for your functions

flint idol
#

don't forget to name it in obos' naming convention

thick jolt
#

like CoreS

#

and stuff

flint idol
#

#1141057599584878645 message

#

here

thick jolt
#

hold on brb

#

i need to tell my parents my voice is back

flint idol
#

you could that as CoreH_AbortWaitingThreads

thick jolt
flint idol
#

obos_status

thick jolt
#

okay

flint idol
#

implement in wait.c pls

thick jolt
#

okay

flint idol
#

wrong

#

set interrupted to true

#

then just return CoreH_SignalWaitingThreads(obj, true, false);

#

otherwise you're repeating code

thick jolt
#

how is this

flint idol
#

look again

thick jolt
#

whoops sorry

flint idol
#

np

thick jolt
#

OHHHHH

#

WAIT

#

hold on

#

okay now i have the function @flint idol

flint idol
#

wooo

#

now add the proper support for it in the waiting functions

thick jolt
#

in CoreH_SignalWaitingThreads

flint idol
#

no

#

the waitonobject function

#

I can do wait on objects since that is more complicated

thick jolt
#

hold on

lean glen
#

just do

#

if(interrupted)

#

return ABORTED

thick jolt
#

i added this

#

now if it isnt

flint idol
#

wrong

thick jolt
#

what do i do here

flint idol
#

just do

#

if (obj->interrupted) return OBOS_STATUS_ABORTED after the block function is called

thick jolt
#

done

#

will i make a pr?

flint idol
#

now test it

#

of course

#

make a mutex in one thread

thick jolt
#

how do i test it ๐Ÿ˜ญ

flint idol
#

on another

thick jolt
#

where

flint idol
#

basically:

mutex mut;
// thread one
acquire(mut)
interrupt_wait(WAITABLE_OBJECT(mut));
// thread two
// calls into wait on object
assert (acquire(mut) != ABORTED);```
thick jolt
#

in which function

flint idol
#

nowhere

#

you need to test it

thick jolt
#

kentry?

flint idol
#

sure

thick jolt
#

okay

flint idol
#

arch/x86_64/entry.c

#

go to the bottom of the file

#

and add it somewhere

thick jolt
#

do i need to create threads or

flint idol
#

that is in the completely wrong place

#

and not only that

thick jolt
#

oh

flint idol
#

that was pseudocode

#

the thing I sent

thick jolt
#

sorry

flint idol
#

it's np

thick jolt
flint idol
#

bottom of the file

thick jolt
#

oaky

flint idol
#

wait if you're gonna make a pull request

#

how don't you have a fork

#

afaik that's the only way to pr if you don't have write access

#

to a repo

thick jolt
#

fuck

#

but wait

flint idol
#

just fork it

thick jolt
flint idol
#

then you can git remote set-url origin link/to/fork

flint idol
#

but above the inline asm

#

around line 860

lean glen
#

860 lines

#

in the entry file

#

wtf

flint idol
#

no, 950

flint idol
thick jolt
#

here???

flint idol
thick jolt
#

okay

flint idol
#

the inline asm is just a test program

#

for syscalls

thick jolt
#

okay

#

now

flint idol
#

also you need to make it multithreaded

#

it's the only way

#

to test it

thick jolt
#

okay

flint idol
#

but unfortunately, my threading api is bumcheeks

thick jolt
flint idol
# thick jolt <:nooo:750466870993223750>
// not psuedocode
thread* thr = CoreH_ThreadAllocate(nullptr);
thread_ctx thr_ctx = {};
void* stack =  Mm_VirtualMemoryAlloc(&Mm_KernelCtx, nullptr, 0x10000, 0, VMA_FLAGS_KERNEL_STACK, nullptr, nullptr);
CoreS_SetupThreadContext(&thr_ctx, (uintptr_t)thread_entry_here, (uintptr_t)&any_user_data_here, true, stack, 0x10000);
CoreH_ThreadInitialize(thr, THREAD_PRIORITY_NORMAL, Core_DefaultThreadAffinity, &thr_ctx);
CoreH_ThreadReady(thr);
#

take this snippet

thick jolt
#

okay now that ive created

#

a thread

#

i will create another as well?

flint idol
#

nah you only need one

thick jolt
#

okay

lean glen
#

why CoreH

#

what is CoreS

#

what

#

wa

flint idol
#

as you already have another thread: the kernel main thread

flint idol
flint idol
thick jolt
#

whats the api for creating a mutex

flint idol
thick jolt
#

okay

flint idol
#

acquire:
Core_MutexAcquire(&mut);

#

release:
Core_MutexRelease(&mut);

thick jolt
#

okay

flint idol
#

and to convert a mutex to a waitable_header*:

#

WAITABLE_HEADER(mut);

thick jolt
flint idol
#

that's implicitly called when you acquire a mutex

#

and it's already acquired

thick jolt
#

okay

#

so now i need to call my abort_wait

#

yes?

flint idol
#

yes

#

after you acquire the mutex in thread one

#

which is the kmain thread (where the entry code executes)

#

then you also must acquire the mutex in thread two

thick jolt
#

but u said i only needed one thread

flint idol
flint idol
thick jolt
#

ohhh

#

cause this kmain is already a thread

flint idol
#

ye

thick jolt
#

okay brb i might be gone for an hour or 2

flint idol
#

sure

thick jolt
flint idol
#

through the user data

flint idol
thick jolt
#

i dont have auto complete working so

#

whats the field im looking for?

flint idol
#

&mut

#

change it to that

thick jolt
flint idol
#

no

thick jolt
#

oh

flint idol
#

pass &mut there

vale nymph
#

wtf rust

flint idol
#

no

#

mut->mutex

thick jolt
#

so its a function i can call?????

#

oh no

flint idol
#

huh???????

thick jolt
#

nvm

thick jolt
#

๐Ÿ˜ญ

flint idol
#

know c?

thick jolt
#

yes

flint idol
#

you know how YOU'RE CALLING A FUNCTION

#

oops caps lock

thick jolt
#

what is the function called

flint idol
#

&any_user_data_here is a placeholder

thick jolt
#

oh

#

so change that with my mutex?

#

yes or no?

flint idol
#

yesa

thick jolt
#

okay

flint idol
#

&mut

thick jolt
flint idol
#

yup

#

actually

#

acquire the mutex after having started the thread

thick jolt
#

okT

#

okay

flint idol
#

and in both threads after having acquired the mutex, add ur interrupt wait function

#

and one of those waits should fail

thick jolt
#

like this

flint idol
#

with aborted

#

if you did all correctly

#

you see where I add thread_entry_here

#

that's also a placeholder

thick jolt
#

yea

#

so the entry will be what?

#

exactly

#

js to make sure

flint idol
#

the entry point of your other thread

#

the one u want to start

thick jolt
#

the one im running in right now?

flint idol
#

nay

#

read again

thick jolt
#

i havent created 2 threads hiold on

thick jolt
#

nvm i dont understand

#

im sorry.

#

wait

#

do i put test_program into it

#

probs no

#

sorry

flint idol
#

you are making another thread, yes

#

for hte other part of the test

#

?

#

MAKE THAT THE NETRY POINT

#

oops caps

#

lock

thick jolt
flint idol
#

wut

#

wut

#

wut

#

wut

#

wut

quaint rivetBOT
#
Anti-spam Message

Possible spam detected for user: oberrow. Please contact a moderator to be unmuted.

thick jolt
#

SORRY

#

@real pecan

#

@white mulch

barren merlin
#

.!unmute @flint idol

quaint rivetBOT
#

@flint idol is not muted.

barren merlin
#

next time ban

thick jolt
#

wait really????

white mulch
#

oberrow or nyaux not get timed out every day challenge meme

thick jolt
flint idol
#

he's talking to me

thick jolt
#

yes

#

but your serious??

barren merlin
#

no

#

I'm not

thick jolt
#

oh thank god

barren merlin
#

I'm not evil

flint idol
#

can someone explain to him

#

how thread entry points work

torpid wigeon
#

who

thick jolt
#

i know how they work

#

i just dont understand what entry point you want me to give it

flint idol
#

the one u make

#

for the test

thick jolt
#

okay so ill create a new function in the file

#

okay

#

okay i made one

flint idol
#

make it static

#

and name it whatever

#

no need to follow the naming convention

thick jolt
#

void static?

flint idol
#

also give it mutex* mut as a parameter

torpid wigeon
#

why is the void upper case

thick jolt
#

okay

#

my bad

flint idol
thick jolt
#

thanks

torpid wigeon
#

40 stars on obos

flint idol
flint idol
thick jolt
flint idol
#

why are you doing &mut->mutex

#

just &mut

#

it's that simple

thick jolt
#

sorry

flint idol
#

np

thick jolt
#

its &mut

flint idol
#

indeed

#

after acquire don't forget to call your interrupt wait function

thick jolt
#

my abort_wait

flint idol
#

yes

thick jolt
#

nono

#

okay

#

after mutex acquire?

flint idol
#

yes

thick jolt
#

okay

flint idol
#

also do the same thing in the other thread you start

#

acquire+abort_wait

#

then Core_ExitCurrentThread

#

also you need to make sure the wait gets aborted properly

#

by checking the status of acquire

thick jolt
#

okay

#

do i remove mutex acquire probs not right?

flint idol
#

if (obos_is_error(status)) printf("fail");

flint idol
thick jolt
#

kk

flint idol
#

btw

#

in mutex acquire you will need to make some changes

#

when it calls Core_WaitOnObject it never checks the status

thick jolt
flint idol
thick jolt
#

okay

#

leave the one in this thread right?

flint idol
#

the idea here is to create two threads racing for the mutex, and the one that doesn't get it first will simply hang acquiring it

thick jolt
#

okay

flint idol
thick jolt
#

yea i understand

flint idol
thick jolt
flint idol
#

not quite there yet

#

obos_status status = Core_MutexAcquire(mut);

#

and also: WAITABLE_OBJECT(*mut)

thick jolt
#

okay done

flint idol
#

so it should look like:

obos_status status = Core_MutexAcquire(mut);
CoreH_AbortWaitingThreads(WAITABLE_OBJECT(*mut));```
thick jolt
#

gotcha

#

thats all done

flint idol
#

and the same thing on the first thread, but you don't dereference any pointers

thick jolt
#

okay

flint idol
#

to mut

#

then you compile obos

#

and in theory, status in one of the threads will be aborted

#

which you can printf

thick jolt
flint idol
#

printf("%d", status);

#

don't forget

thick jolt
#

in arch_kernelmainbootstrap

flint idol
#

yup

thick jolt
flint idol
#

now you will most likely run into a small bug with mutexes

#

because acquire doesn't forward the status of WaitOnObject

#

anyway gtg eat

thick jolt
#

so lets make someone changes to that

flint idol
flint idol
#

Gl and godspeed

lean glen
thick jolt
#

idk

flint idol
#

Oh wait I don't gtg eat

#

Yet

#

Brb though

thick jolt
#

okay

flint idol
#

Bqck

#

*back

thick jolt
#

making changes to acquire

#

is this correct @flint idol

#

wait

#

no nvm

#

i have no idea

#

@flint idol

#

OOHOHOHOH WAIT

#

@flint idol

#

i did this

#

is this correct yes or no

#

in acquiring

#

i think hes gone

#

hello?

#

also having these build errors

#

@flint idol ??????

flint idol
#

Huh weird

flint idol
thick jolt
#

13.3.0

flint idol
#

Hmm

#

Try clang

#

Reconfigure with -DOBOS_USE_CLANG=ON

#

You need to delete the cmake cache

#

Tho

thick jolt
#

how

#

i dont use cmake

flint idol
#

rm CMakeCache.txt

thick jolt
flint idol
#

rm build/CMakeCache.txt

thick jolt
#

doesnt exist

#

found it

flint idol
#

Can you ls build

thick jolt
#

x86_64

flint idol
#

Oh ok

flint idol
thick jolt
flint idol
#

And obos will be built with clang

thick jolt
#

okay

#

ill change the names

flint idol
#

#include <locks/wait.h> at the top of the file maybe?

#

idk

#

I do that tho

#

ur toolchain is cursed

thick jolt
#

now its just this

flint idol
#

you define this in wait.h, right?

thick jolt
#

i didnt put it in wait.h

flint idol
#

well no wonder then

thick jolt
#

๐Ÿคฆโ€โ™‚๏ธ

flint idol
#

bruh

#
execute_process(COMMAND x86_64-elf-gcc -print-file-name=no-red-zone/libgcc.a OUTPUT_VARIABLE LIBGCC)
if (LIBGCC STREQUAL "no-red-zone/libgcc.a")
    # Use normal libgcc
    execute_process(COMMAND x86_64-elf-gcc -print-file-name=libgcc.a OUTPUT_VARIABLE LIBGCC)
endif()```
#

this is how I get it..

#

can you run x86_64-elf-gcc -print-file-name=no-red-zone/libgcc.a

#

and show me the output

thick jolt
flint idol
#

hmm

#

can you go to line 52 of src/build/x86_64/toolchain.cmake and add message("hai")

#

and reconfigure cmake

#

after deleting cache

real pecan
flint idol
#

I gave you an exact path

#

you didn't use it

#

relative to the repo's root

thick jolt
#

oh

#

@flint idol

thick jolt
real pecan
#

Thats managarms kernel btw

thick jolt
#

ik

real pecan
#

This is still funny

flint idol
#

@real pecan obos curse

flint idol
flint idol
#

Did you reconfigure cmake and delete the cache

thick jolt
#

yes

flint idol
#

Rather, delete the cache then reconfigure the cache

real pecan
#

Lol

real pecan
flint idol
flint idol
#

If it isn't then I have an idea of what the bug is

#

If it is then I also have an idea of what the bug is

thick jolt
#

hold on

#

im like playing cs 2 with streaks and laura, after this match ill do so

#

its 2-2

flint idol
#

Bruh ok

thick jolt
#

wdym bruh ok ๐Ÿ˜ญ

real pecan
#

What's your premier rating

thick jolt
#

zero

#

havent played cs

#

before

real pecan
#

Ohh

flint idol
#

Why'd you wanna contrib to obos

thick jolt
#

๐Ÿ˜ญ

real pecan
#

Nyaux obos merge when

thick jolt
#

I JUST FELT NICE

#

๐Ÿ˜ญ

flint idol
#

Lol was joking

thick jolt
#

:sib

#

๐Ÿ˜ญ ๐Ÿ˜ญ

torpid wigeon
thick jolt
#

lmao

torpid wigeon
#

what happened to rust

thick jolt
#

bro

#

i write nyaux in c now

#

im on my 3rd rewrite

torpid wigeon
#

L

thick jolt
#

to which im not giving up

real pecan
#

W

thick jolt
#

WDYM L

#

๐Ÿ˜ญ

#

C IS A W

flint idol
#

*nay

#

W

torpid wigeon
#

nyaux you need rust handholding

weary hound
flint idol
#

Is the right answer

torpid wigeon
short mortar
#

C is painful

flint idol
#

Skill issue

thick jolt
#

skill issue

torpid wigeon
#

yea exactly what you're having

torpid wigeon
#

rust gave you some sort of harness troll2

thick jolt
#

with rust i had more UB

#

then anything

short mortar
#

I'm thinking about writing stuff in Ada for pmOS

flint idol
flint idol
short mortar
flint idol
#

Ada is a W

short mortar
#

I know SQL, it should be similar

flint idol
#

I wouldn't say that if ironclad weren't written in it

torpid wigeon
#

i'd rather use V

real pecan
#

Didnt go well for mint

short mortar
real pecan
#

JVM when

torpid wigeon
#

wasm

short mortar
#

After I get a disk driver

flint idol
#

When uJVM

real pecan
#

Lmao

short mortar
#

And a shell

short mortar
real pecan
#

Pmos running Minecraft playing on a server running on managarm

torpid wigeon
#

uAPI headers need to be finished first

real pecan
short mortar
white mulch
#

jvm has some weird instructions that idk how to implement

#

like invokedynamic

flint idol
#

Just write the drivers for obos then everyone needs to write shims for the obos driver interface

torpid wigeon
#

@flint idol finish pci headers for infy

flint idol
#

Done

torpid wigeon
#

fake

white mulch
#

minecraft on obos when

#

or first more like openjdk on obos when

real pecan
# real pecan Lol

Oberrow back then: scared to touch acpi
Oberrow now: first hobby os with S3 suspend

thick jolt
#

im back

flint idol
#

Bruh

thick jolt
#

i did it exactly

flint idol
#

I will be with you in a bit

thick jolt
#

kk

flint idol
#

line 50 of the same file, insert this:
message(${LIGCC})

#

then delete cache and reconfigure

flint idol
# thick jolt oaky

btw, if 9+47 is airplane, and your boat has a flat tire as you fly through the desert, what should you have in your back pocket?

thick jolt
flint idol
thick jolt
flint idol
#

well I know the workaround

#

replace that if line with:

if (LIBGCC STREQUAL "no-red-zone/libgcc.a" OR LIBGCC STREQUAL "")
#

line 51

#

@thick jolt

thick jolt
#

okay

flint idol
#

and remove the message line at line 50

thick jolt
#

ok

#

i did hto

flint idol
#

good

#

if that doesn't work, try replacing the if at line 50 with:

if ("${LIBGCC}" STREQUAL "no-red-zone/libgcc.a" OR "${LIBGCC}" STREQUAL "")
#

@thick jolt

thick jolt
#

oaky

flint idol
#

while this does lead me to raise the question of why your gcc doesn't have the no-red-zone libgcc, we can ignore that for now

thick jolt
#

can u just compile my changes @flint idol and test them please

flint idol
#

send patch

#

git format-patch

#

don't forget to make a commit

thick jolt
flint idol
#

then you can pop that in here and I will apply it and test it for you

thick jolt
#

i ran git format-patch

#

where are the patches

flint idol
#

in the repo root

thick jolt
#

i see nothing

#

only ur patches

flint idol
#

did you make a commit

#

?

thick jolt
#

yes

#

i can make a fork

flint idol
#

can you ls in the repo root

flint idol
thick jolt
flint idol
#

git log

#

make sure

#

you committed

thick jolt
#

yep is my commit

flint idol
#

git format-patch HEAD

thick jolt
#

still nothing

flint idol
#

git format-patch HEAD~1

thick jolt
#

okay i have the patches

flint idol
#

send

thick jolt
#

apply them and try

flint idol
#

compiling

thick jolt
#

kk

flint idol
#

good news mr. nyaux man

#

after fixing a bug in my code

#

your stuff worked

#

partially

thick jolt
#

YESSS

#

wdym partially

#

whats wrong

flint idol
#

you forgot to add an exit thread statement

#

to the test thread

thick jolt
#

well u can fix that

flint idol
#

yeah

thick jolt
#

and then

#

u can commit this

#

!!

#

make sure to give me credit

#

๐Ÿ˜Ž

flint idol
#

ofc

flint idol
thick jolt
#

๐Ÿ˜Ž

flint idol
#

then commit my code making the fixes

#

to the test

#

although there is a slight problem, sometimes the status for both threads is SUCCESS

flint idol
#

I will debug that

thick jolt
#

okay

flint idol
#

bruh

#
    if (obj->interrupted) 
        return OBOS_STATUS_ABORTED;
    CoreH_ThreadBlock(curr, true);```
#

you're supposed to do that after the block

flint idol
#

I don't usually push code with a test in it

#

and I will be making a proper commit message

thick jolt
#

lol

#

๐Ÿ˜ญ

thick jolt
#

let me know when u commit

thick jolt
#

๐Ÿ˜Ž

flint idol
#

will take a bit for you to be on the contributors list

#

because bah github

flint idol
#

I have some other TODOs for you

thick jolt
#

on

#

but

flint idol
#

not pressuring you

thick jolt
#

ofc now

#

not*

#

but whenever im free

flint idol
#

just if you're ever bored

thick jolt
#

yea

#

ill contribute

#

add me to the contributes list lol

flint idol
#

github is stoobid

#

so it might take a bit

thick jolt
#

frfr

#

all good

flint idol
#

and if it's ultra stupid I'll add you to the credits

flint idol
#
// NOTTODO: Test.```
lol
#

in arch/x86_64/ssignal.c

flint idol
# thick jolt okay

if you're ever bored again and feel like contributing to obos, here are some current TODOs that I have for you:

  • fix the m68k port
  • fix the gdb stub
  • rewrite the disk swap interface
  • make the driver loader mostly platform-independant
frank flare
flint idol
#

after I finish this small thing in obos

#

I will be doing vfs syscalls

flint idol
#

I am currently fixing a bug related to standby/dirty lists and shared pages.
Previously, it would blindly assume that it could put any page on standby/dirty, which included shared pages.
This behaviour is incorrect, as if a page is shared, it's possible, and very likely, that the other shared page(s), are still using it while it's supposed to be treated as standby memory, or memory that will become standby (i.e., dirty pages).

#

The solution was to add another reference counter to struct page (physical page ofc)

#
// A reference count of virtual pages that have this page paged in.
// Must always be <= refcount.
_Atomic(size_t) pagedCount;```
#

this vmm work inspires me to unfuck my pagecache

#

it's not buggy, just shitty

flint idol
#

this branch is getting out of hand

white mulch
#

maybe you should merge it lol

flint idol
#

I want to get my syscalls finished first

#

and fix any regressions in the m68k port

#

in a separate discord server, I predicted that I would have ~70 syscalls by the end of this

#

and I can never forget TTYs

#

which I need to implement

#

basically everything here

#

plus this vmm work

flint idol
#

after getting myself to stop procrastinating

#

I am now going to finish the new api to the vmm

#

streaming obos in voice one

#

for those who care for some reason

torpid wigeon
#

those who care ๐Ÿ’€

flint idol
#

this shit is so boring

thick jolt
#

cant believe my code for obos worked first try ish

flint idol
#

rea;

#

real

thick jolt
#

i knew nothing about thread blocking btw

#

crazy

flint idol
#

mhm

#

crazy

thick jolt
flint idol
#

I can in a bit

#

actually call me

thick jolt
#

okay

astral mason
#

huh?

thick jolt
astral mason
# thick jolt WHERES UR MANGA PLUS OS

Manga I haven't drawn any panels for yet lol, still working on the script. OS, er, I forgot about XD, I think I was trying to figure out how to read a Ext2 file path

#

Lemme find my OS' thread

#

OK Idk how to link to a thread but it's called AquaOS

astral mason
#

thank you

flint idol
#

I should have Mm_MapViewOfUserMemory implemented

#

I will not be testing this.

flint idol
#

uh oh

#

obos in debug mode broke

#

it's clang doing dumb shit with kasan

#

it looks like it's poisoning the stack

#
if (OBOS_USE_CLANG)
    add_compile_options($<$<COMPILE_LANGUAGE:C,CXX>:-Wno-error=unknown-pragmas>
                        $<$<COMPILE_LANGUAGE:C,CXX>:-Wno-unknown-pragmas>
                        $<$<COMPILE_LANGUAGE:C,CXX>:-Wno-error=unknown-attributes>
                        $<$<COMPILE_LANGUAGE:C,CXX>:-Wno-error=c23-extensions>)
    if (OBOS_ENABLE_KASAN)
        set (OBOS_ENABLE_KASAN OFF)
        message (WARNING "OBOS does not support Clang's ASAN implementation. If you really care about this, make a PR, as I don't.")
    endif()
endif()```
#

fixed it

white mulch
#

have you tried setting the asan call threshold to 0?

flint idol
#

I have no idea what that means

white mulch
#

-mllvm -asan-instrumentation-with-call-threshold=0 should get rid of clang making inline shadow map checks if that's what its doing

flint idol
#

this is only to the compiler right?

white mulch
#

yes

flint idol
#

k

#

I'll try

#

still crashes

#

resorting to plan B

flint idol
#

I love this stack trace

#

poor man's stack trace

#
#define OffsetOfReg(reg) ((uintptr_t)&(((ioapic_registers*)nullptr)->reg))

could clang be treating this as UB

#

and cause UBSan to yell at me?

#

I'm just gonna spam OBOS_NO_UBSAN until it boots

#

actually I'll just properly fix the bugs

weary hound
flint idol
#

why the hell did my 2nd monitor just die on me nooo

thick jolt
thick jolt
#

for the love of allah

real pecan
#

It has a built-in even

flint idol
flint idol
thick jolt
#

corrupt stack

#

/j /j

flint idol
thick jolt
#

๐Ÿ˜ญ

flint idol
#

so yeah it turns out indexing an array at index -1 is bad

#

(whoops)

real pecan
#

Works in python

flint idol
#

and in C

#

but UBSan doesn't like it

#

and also it happens to be a bug

#

it boots now

#

since it's getting pretty close to getting merged

#

time to continue vfs syscalls

#

I hope to get these done within a couple hours

#

should be simple enough, right?

flint idol
#

We should be in bash by the end of the month

  • oberrow, august 2024
#

maybe I'm mistaken, but I think we're not in bash

real pecan
#

Well u did a lot of other things

flint idol
#

ye

#

I got "a bit sidetracked"

#

but it was for the better

real pecan
#

Ye

flint idol
#

is it bad that read is able to read even if the target buffer is mapped as RO KEKW

#
void* kbuf = Mm_MapViewOfUserMemory(CoreS_GetCPULocalPtr()->currentContext, (void*)buf, nullptr, nBytes, 0, &status);
if (obos_is_error(status))
    return status;
#

Mm_MapViewOfUserMemory ignores any protection flags the user set

#

so when the kernel gets it's view of user memory, it can do whatever the hell it wants

#

of course the change in prot flags isn't reflected in user-mode

flint idol
#

and the first five bytes of the string literal would be over written with whatever was in the file

#

maybe I should fix that

#

I'll add a parameter called "respectUserProtection"

#

which does the following:

  • when checking if the user pages exist, if anyone of the user pages has different protection flags than the ones the kernel desires in it's mapping, it return OBOS_STATUS_PAGE_FAULT
#
    if (respectUserProtection)
    {
        if (kprot & OBOS_PROTECTION_EXECUTABLE)
        {
            OBOS_Error("Kernel is doing shady things, refusing to map user pages as executable inside the kernel address space. If all is in your favour, this is a bug, otherwise it's malware.");
            return false;
        }
        // If the kernel wants an RW mapping, but the user range is RO, then fail.
        if (!!(kprot & OBOS_PROTECTION_READ_ONLY) < rng->prot.ro)
            return false;

    }```
#

it's fair to refuse mapping kernel pages as executable if they're being shared from user mode

#

for safety

lean glen
#

why are you sharing kernel pages

flint idol
#

sorry, it's the other way around

#

user pages are being shared to kernel mode

lean glen
#

why

flint idol
#

kpti

flint idol
#

otherwise I'd need to do very large amounts of memcpy

#

and allocation

#

for reading files

#

and writing files

#

so I thought to myself, why don't I just have a function to map user pages into the kernel context temporarily, so I can just pass the pages mapped in kernel mode to the vfs' read/write functions

#

so that's what I did

lean glen
#

well then you control the protection

#

idk why you add a check

#

you need to read into something, just set the write bit

#

you need to write, only set the read bit

flint idol
#

which is exactly what I did

#

what I added was a way to make sure the user can't do something like this:
Vfs_FdRead(file, "heheheh I am evil", 5, NULL);
and it returning success and doing the read into the RO string literal

#

with that, I should have my vfs syscalls implemented

#

implementing syscalls is really just a bunch of code copy+pasting when they just call into kernel functions with the exact same API

flint idol
#

but I think it's better to do that after merging this branch

#

#1141057599584878645 message
Next thing on the list is partition probing syscalls

#
void OBOS_PartProbeAllDrives(bool check_checksum);
obos_status OBOS_PartProbeDrive(struct dirent* ent, bool check_checksum);```
that will correspond almost directly to a call to either of these functions
#

in fact, the first function can be directly made a syscall

#

without glue code

#

ok finished those syscalls

thick jolt
#

bros doing syscalls

#

while im suffering in the nyaux thread

flint idol
thick jolt
#

๐Ÿ˜ก

flint idol
#

driver interface syscalls now

#
driver_id *Drv_LoadDriver(const void* file, size_t szFile, obos_status* status);
obos_status Drv_StartDriver(driver_id* driver, thread** mainThread);
obos_status Drv_UnloadDriver(driver_id* driver);```
#
obos_status Drv_PnpLoadDriversAt(dirent* directory, bool wait);```
#

these are the functions I will expose

#

and I will add another syscall:

handle Sys_FindDriverByName(const char* name /* assumed to be 64-bytes at max */);```
#

also:

// Returns the next driver in the list
// The handle 'curr' is not automatically closed.
handle Sys_EnumerateLoadedDrivers(handle curr);
#

as well as:

obos_status Sys_QueryDriverName(handle drv, const char* namebuf, size_t sznamebuf /* need not be over 64 */);```
short mortar
flint idol
#

well two things:

  • I can't do that, I do KPTI (user pages and kernel pages are separated through completely different CR3s, as opposed to just a bit in the PTE)
  • even if I could do that, I wouldn't, as I want to be able to give the user a status telling it it page faulted, which could prove difficult if I just let it page fault
short mortar
#

You add a shim function?

flint idol
#

wdym?

short mortar
#

Like save the registers, make pf handler switch to some function which returns error

#

I also kinda have that problem, but my issues are because of nonpreemptive kernel

short mortar
#

Otherwise mapping and unmapping have a huge performance hit

flint idol
#

I'd rather map than allocate then do a slow ass memcpy_k_to_usr

#

at least for large sized IO

short mortar
#

Also kpti assumes userspace pages are still mapped

flint idol
#

does it?

short mortar
#

(at least that's how I've been understanding it)

flint idol
#

that's a misunderstanding

#

you only have the bare minimum of the kernel mapped in a user context

short mortar
#

Yes

flint idol
#

i.e., only enough to make a switch to the actual kernel context+ring3

short mortar
#

And then another mapping with full user context + full kernel

flint idol
#

well I haven't been doing that (oops)

short mortar
#

And then you can copy efficiently

#

I'm not sure, but I think switching page tables is still a barrier against side channels (?)

#

(I'm not an expert and don't have a lot of interest in security vulnerabilities, besides the basics)

flint idol
#

what I do is have it switch to the kernel's CR3 in the IRQ handler when coming from ring3

#

and then do all user memory access through a special function

#

memcpy_k_to_usr+memcpy_usr_to_k

short mortar
#

Yeah, that's reasonable

#

But you have a flag which protects you from reading user memory from ring 0

flint idol
#

ye, SMAP

#

and SMEP

#

which I enable if they exist

short mortar
#

So in your functions, you can just disable that temporarely and read user memory as needed (?)

flint idol
#

nay

#

they have a cursed implementation

short mortar
#

Without inducing costs of page faults

flint idol
#
    for (size_t i = 0; i < count; )
    {
        MmS_QueryPageInfo(ctx->pt, (uintptr_t)usr_src + i, nullptr, &usrphys);
        if (!usrphys)
        {
            // Mm_VirtualMemoryUnlock(ctx, futex, sizeof(*futex));
            return OBOS_STATUS_PAGE_FAULT;
        }
        size_t currCount = bytes_left > OBOS_PAGE_SIZE ? OBOS_PAGE_SIZE-((usrphys+usroffset)%OBOS_PAGE_SIZE) : (size_t)bytes_left;
        memcpy((void*)((uintptr_t)k_dest + i), MmS_MapVirtFromPhys(usrphys+usroffset), currCount);
        usroffset = 0;
        i += currCount;
        bytes_left -= currCount;
    }```
#

it does this

#

for usr_to_k

#

and vice versa for k_to_usr

short mortar
#

That's what I do as well

#

kinda

flint idol
#

TODO: Could it be possible to include these functions in the user CR3, then drop to the user CR3 to do the k_to_usr memcpy or usr_to_k memcpy?

short mortar
#

How many cycles do pagefaults take on modern CPUs?

flint idol
#

#x86

short mortar
#

For small stuff, you can have some sort of scratch area

#

Which is mapped to both

#

So you first copy there from kernel to userspace-facing mapping

#

And then to userspace userspace

flint idol
#

hmm

flint idol
#

ok so driver interface syscalls are done

#

next up: TTYs-

#

oh

flint idol
#

TTYs are tomorrow nooo

#

then I can merge the branch

#

theoretically

#

wait

#

I'VE BEEN SAVED

#

signal-related syscalls

#
void OBOSS_SigReturn(interrupt_frame* frame);
obos_status OBOS_Kill(struct thread* as, struct thread* thr, int sigval);
obos_status OBOS_SigAction(int signum, const sigaction* act, sigaction* oldact);
obos_status OBOS_SigSuspend(sigset_t mask);
obos_status OBOS_SigPending(sigset_t* mask);
enum {
    SIG_BLOCK,
    SIG_SETMASK,
    SIG_UNBLOCK,
};
obos_status OBOS_SigProcMask(int how, const sigset_t* mask, sigset_t* oldset);
obos_status OBOS_SigAltStack(const uintptr_t* sp, uintptr_t* oldsp);```
#

those are the signal-related APIs I will expose

#

to user mode

#

Current roadmap:

  • Signal syscalls
  • Directory syscalls
  • exec syscall
  • TTYs
  • merge userspace-work
  • OBOS x86_64 gcc target
  • mlibc
  • bash
lean glen
#

then you're gonna realize everything's broken because you didnt test anything

flint idol
#

indeed

lean glen
flint idol
#

that was the plan

flint idol
#

Signal syscalls

#

ok

#

uhh

#

should be relatively easy

flint idol
#

done

#

theoretically since these are just practically memcpys then just calling into the appropriate signal function

#

they should work

#

now dirent syscalls would be simple, if I could find the part of the POSIX spec for them

#

there it is

thick jolt
#

u will hit bash soon

flint idol
#

Yes

thick jolt
#

where as nyaux will be left in the dust struggling to fix bug after bug

flint idol
#

hopefully by the new year

thick jolt
short mortar
thick jolt
#

ill probs hit another bug

#

after this one

#

then after that one

short mortar
#

I need to implement working set

thick jolt
#

yea we def gonna encounter a LOT of bugs

short mortar
#

Then AHCI driver

flint idol
short mortar
#

Before that I'll probably get caught in writing some other random drivers

#

Then decide to "improve" VMM again

thick jolt
#

anyways no more distractions back to debugging nyaux

flint idol
#

say, what if I didn't want to implement alphasort

#

posix mandates it

#

but idk if my kernel needs it as a syscall

#

or if mlibc does it for me

short mortar
#

This should probably be done in libc

flint idol
#

hmm

#

mlibc doesn't

#

even have sysdeps for any of those dirent functions

#

only sys_read_entries

devout niche
#

the read entries one does all that mlibc needs the kernel (or posix server) to do

flint idol
#

stuff like opendir, readdir, closedir, etc.

devout niche
flint idol
#

well what is sys_read_entries supposed to do?

#

I know it reads the dirents

#

but what exactly is the format of the struct it's reading into

devout niche
#

struct dirent

flint idol
#

hold on, I think I found it:

typedef struct dirent {
    uint32_t inode; // Inode number
    uint32_t type;
    char name[NAME_MAX]; // Filename
} dirent_t;```
#

so this

devout niche
#

i think mlibc has its own definition and expects in that form

flint idol
#

ah ok

#

thanks

#

I'm sure it'd be perfectly fine if I always set inode to zero

#

right

#

what could possibly go wrong

#

I'm going to need to make stat syscalls

#

why did no one tell me I could something like man stat.3type

#

to find the struct stat format

#
int sys_read_entries(int handle, void *buffer, size_t max_size,
        size_t *bytes_read);```
is buffer allowed to be NULL here?
#

and if it is, do I just set *bytes_read = however many bytes it would read

real pecan
#

see which stubs call into this and read the posix spec

flint idol
lean glen
#

it is

#

no

#

nvm

#

getdents

#

it's the equivalent of getdents

#

which is used by readdir

#

so read readdir

flint idol
#

k

#

thanks