Zinnia

[neon flicker]

iirc info tlb has nothing to actually do with the tlb

[eternal wharf]

yeah info tlb is just an entry-by-entry page table dump

[near tartan]

we are so back

[grave peak]

Nice

[marsh holly]

Epic

[neon flicker]

waow

[near tartan]

before doing anythin else, i should probably use a real interrupt timer though

[near tartan]

we are so back

(yet again)

[near tartan]

fail

and cringe

[near tartan]

apic proving to be quite annoying

[fiery marlin]

your code is just too fast for time to pass

what seems to be the issue?

[near tartan]

i mean it's probably me just misconfiguring the lapic, but it seems to spin into an infinite interrupt handler loop

[fiery marlin]

Do you write to eoi? lol not sure what I was thinking

[near tartan]

yea

[fiery marlin]

Yeah nah that won't be your problem

How are you setting up the timer?

[near tartan]

i'm setting the divisor to 16

and the init counter to -1

then i poll 10ms with the hpet

and stop

yea i think i see the issue

but even then, i have no idea what i'm actually doing lol

[fiery marlin]

Magic numbers

[near tartan]

yes

[fiery marlin]

Have you tried a smaller divisor?

[near tartan]

i think this is the issue lol

[fiery marlin]

Yeah lol

That was my next comment

[near tartan]

oh one thing that i forgot about

is it possible to interrupt an interrupt?

if yes, how is that handled

[fiery marlin]

Depends on the interrupt flag

[near tartan]

i knew it at some point but i did so much rv64 that i forgot

[storm bobcat]

depends whether or not it's a trap gate

[fiery marlin]

so exceptions can happen at any time, and with the exception of NMIs/MCEs the cpu doesnt really have the concept of being in an interrupt

if you're in an isr - its up to you to have flags.if cleared to prevent non-exception interrupts

you can have nested interrupts though, and it works like you expect. The cpu does normal interrupt entry stuff.

[near tartan]

does that work infinitely or is there some limit?

(assuming infinite stack)

[fiery marlin]

it works until you run out of stack space 😛

and for idt entries, make sure you're using interrupt gates and not trap gates (trap gates leave the interrupt flag set upon entry). They are useful, but you'll know when you want one.

[near tartan]

yea i'm using interrupt gates

[near tartan]

finally running on real hw again

[near tartan]

logs are hopefully easier to read now

[neon flicker]

Not enough color smh

[near tartan]

smh

oh i also finally got clock sources

[near tartan]

HPET working on real hardware, LAPIC is not as much of a fan of my code

[hoary cave]

hpet at 0x0000000000000000

sounds healthy

good job :^)

the format of the logs reminds me very much of linux

not a bad thing at all

[near tartan]

that's the idea

[near tartan]

https://cdn.discordapp.com/attachments/1287456798407790684/1290809675943776298/assert.gif

[jade moon]

I love the name of this project. Just stopped by to say that lol.

[near tartan]

based

[near tartan]

alright, the scheduler seems to be properly working now

now i need an actual file system

initrd in probably NOT going to cut it

i'll start with fat32, i need that shit anyways for esp

[neon flicker]

le cool

[neon flicker]

I like how I was the origin of this

in the managarm thread one day I posted this

[near tartan]

good gif

https://media.discordapp.net/attachments/594925688914706462/890948499380797460/makesweet-rvejc6.gif

also good gif

[neon flicker]

yes.

[near tartan]

since i now have an arm laptop i should try to port to aarch64

[neon flicker]

my arm is a laptop

[near tartan]

and i need to check if cross compilation actually works

i have my doubts

hm

if i rewrite my bootstrap tool in python i can reasonably have a self-hosting kernel

i don't think i'll manage to port rust stdlib anytime soon

although, rust with networking is kinda nice

[neon flicker]

when mRuststdlib @managarm peoples?

[near tartan]

i think managarm already has a rust port

and llvm obviously

just not upstream

tbh if the mlibc target was upstream, i'd exclusively use mlibc abi bits instead of linux

gpl

[neon flicker]

this

[near tartan]

the project is licensed as lgpl 2.1

but i do consider just going bsd-3

[hoary cave]

mine is gpl3

idk shit about licenses

[near tartan]

that's super copyleft iirc

i like the "give back" aspect of the gpl

but i also don't want to force people

[hoary cave]

as i said, i don't know shit i just picked one that i thought of first

[near tartan]

lol

[hoary cave]

i can always relicense or something

not that big of a deal

[grave peak]

yeah gpl is an L

[hoary cave]

yea therefore my kernel is an L

[near tartan]

i'm so close to unironically doing a uGPU project

[hoary cave]

time to relicense

[near tartan]

real

[hoary cave]

i would do uXHCI/uUSB if it didn't sound so retarded + if i had any resemblance of motivation

[grave peak]

uUSB lol

[near tartan]

uSB

lol

[grave peak]

huh

[near tartan]

yea

[grave peak]

i was gonna do one as well btw

what are your ideas for it

[near tartan]

join forces?

[hoary cave]

feel free

i wouldnt be of much help anyway

[near tartan]

i have written some DRM drivers for linux before

[hoary cave]

i'd probably quit like my last project

[grave peak]

which gpus do u wanna support

[near tartan]

anything atombios

[grave peak]

amd?

[near tartan]

yea

[grave peak]

i se

[near tartan]

i915

[grave peak]

i was gonna do intel

[near tartan]

and potentially nvidia gsp

[grave peak]

but im probably not starting any time soon

[near tartan]

i'd make the library contain DRM structures as well

crtc, connectors, etc

[grave peak]

i was gonna make it so it can work with an existing drm system, or be a drop-in one itself

based on the configuration

[near tartan]

how would that "link" together?

[grave peak]

compile time option

[near tartan]

how would you connect the user's structs to the internal ones

naming convention?

[grave peak]

oh i havent designed that yet, but ye

something like that probably

will have to see once i get there

[neon flicker]

amd retarbios

[hoary cave]

imo having some sort of function pointer thing would be better

[near tartan]

like flanterm?

[hoary cave]

yeah i guess

[near tartan]

with a callback struct

[neon flicker]

#1141057599584878645 message

[hoary cave]

yea yea

[near tartan]

real

[grave peak]

for embedded stuff?

[hoary cave]

just callbacks would be nice

[near tartan]

nah

an actual gpu

:D

[grave peak]

like was it a project of some sort or why

[near tartan]

yea, a hack week project at work

never submitted it because some parts are missing

but it's a driver for the S3 Trio64

[grave peak]

whats a hack week

[near tartan]

a week off where you can do whatever

and go "hacking"

on company time

[grave peak]

oh damn

was there not an existing driver for that gpu?

[near tartan]

no, only a fbdev driver

i ported it to drm

[grave peak]

nice

should've upstreamed it

[near tartan]

it can only do one resolution mode atm, i don't properly parse the memory modes yet

next hack week

[grave peak]

did u implement 2d/3d accel for it?

[near tartan]

don't think so

the card can barely handle moving the cursor plane lol

[grave peak]

ah

well interesting project nonetheless

what do u do for work

[near tartan]

i do llvm and risc-v hardware enablement at suse

[grave peak]

nice

[near tartan]

here's a pic of it in action

[grave peak]

cool stuff

[near tartan]

but generally, i know nothing else about drm/gpus so this is more of a learning exercise for me

same with my os tbh

teaching myself how shit works under the hood

[grave peak]

my biggest achievement is getting a bare metal kernel to render a 3d triangle on an igpu

[near tartan]

woah

[grave peak]

like with shaders and stuff

[near tartan]

i'm too stupid to even get gpu passthrough working

i have an amd raphael igpu but it refuses to not load the kernel module and put it through vfio

[grave peak]

here it is

[near tartan]

zaaamn

[grave peak]

this is bare metal not even passthrough lol

took 99999999 reboots

[near tartan]

fun

[grave peak]

i was too dumb to realize i could passthrough and ssh into it

[near tartan]

tbf, my current mainboard has a com port, so in theory i could debug early crashes

[grave peak]

the main problem is iteration time

[near tartan]

yep

[fiery marlin]

Damn cool

[grave peak]

u get 0 feedback from the gpu

the screen just goes black

so u have to do random shit until it works

[near tartan]

currently, menix won't even boot on real hardware if you don't add smp=1 to the cmdline

it gets stuck somewhere

[grave peak]

it cost me so much pain lol

[near tartan]

but i can't tell because it happens before fb init

[grave peak]

those are fun bugs

i usually debug those with hang debugging

or in your case u can do triple fault debugging

[near tartan]

i need to buy an rs232 breakout board

[grave peak]

if it reaches a triple fault location it made it there

kinda like printf just visual

[fiery marlin]

Yeah I can imagine lol

[grave peak]

its almost 2k lines of just stuff like that

building out dword buffers and commands

and shaders look like this

just dumped from whatever mesa produced for that igpu

[fiery marlin]

Bloody hell

Looks like a wifi driver

[grave peak]

lol

shaders talk to each other via special gpu shared memory buffers

its all very interesting and cool

[neon flicker]

holy shi

cool

[fair lintel]

we can sort that out once I'm back

[near tartan]

based

[near tartan]

@jovial crypt may i cross-reference your atombios parser

[jovial crypt]

Yea that's fine

[near tartan]

should've thought about that

though, being able to load the kernel as init is funny

[near tartan]

we are so back

[near tartan]

i caved and made fbcon not a module anymore

it's now exclusively for early print only

weird

menix does NOT like my framework laptop

[fiery marlin]

interesting, I also have a framework I use for testing - would be curious to hear what the issue is when you find it

[near tartan]

if only there was serial

I don't even get past the allocation screen apparently

[brisk totem]

i think you can get serial

if you really hate yourself, you can reflash the embedded controller (the code is on github)

and i2c to it

to get logs

[brisk totem]

if you have a Suzy Qable thingy (or any other equivalent ChromeOS debug cable), minicom -D "$(cros_sdk -- dut-control -o cpu_uart_pty)" can get you UART on the AP apparantly

from another device

no disassembly required

https://chromium.googlesource.com/chromiumos/third_party/hdctools/+/main/docs/ccd.md

see also https://www.howett.net/posts/2023-04-framework-ec-card/

or whatever

[near tartan]

I don't hate myself that muh

ive had tons of EC related bugs tho

i mean tbh serial won't change much because it should already output to fb

[near tartan]

@fiery marlin i think i know what the issue is

i get a reset before really early arch init

which hints that its a problem with COM1

[near tartan]

i found the issue

if you try probe serial it crashes

i patched out serial and now it works

[brisk totem]

lmfao what

[near tartan]

[brisk totem]

maybe irq stuff?

[near tartan]

dunno

[brisk totem]

like you get an irq you didnt expect or whatever

[fiery marlin]

Oh lol, thanks for the ping

I wonder if there's something non standard about it

[near tartan]

probably not present and port io on it causes a #UD?

i don't know how else to explain it

because on my PC it simply just says no ACK and disables it

[near tartan]

notices small bug
"how bad can it be?"

this shit is sucha rabbit hole man

[near tartan]

man i have no clue why it's dying now

[near tartan]

i hate interrupt handling so much

my Framework is throwing a gpf on an iretq

hate stack corruption

the worst part is that this is not happening in qemu

only on the framework

@neon flicker help

[near tartan]

even better, my pc just does nothing

aaaaaaaaaaaaaaaaaaaa

[neon flicker]

gl,hf

[near tartan]

[neon flicker]

what you can try to do is make sure

the interrupt frame's last 5 values are valid

before returning

unless you have no printf

then gl

[near tartan]

i do

[neon flicker]

you printed them?

[near tartan]

yea

sec

it does this

[neon flicker]

y do you push gs

and why do you only swapgs once

at the end

[near tartan]

a stub does it on entry

[neon flicker]

ah I see

[near tartan]

/* Internal function called by one of the stubs. */
.align 0x10
interrupt_internal:
    pushq    %gs                    /* Push CPU ID. */
    push_all_regs
    mov        %rsp,    %rdi        /* Load the Context* as first argument. */
    xor        %rbp,    %rbp        /* Zero out the base pointer so we don't backtrace into the user program */
    .extern isr_handler
    call    isr_handler            /* Call interrupt handler */
    mov        %rax,    %rsp        /* interrupt_handler returns a pointer to the new context. */
    pop_all_regs
    add        $0x18,    %rsp        /* Skip Context.error, Context.isr, and Context.core fields. */
    swapgs_if_necessary            /* Change GS back to user mode if we came from user mode. */
    iretq

/* Define 256 interrupt stubs using the macro above. */
.rept 256
.align 0x10
interrupt_\+:
    cli
    swapgs_if_necessary            /* Change GS to kernel mode if we're coming from user mode. */
.if !(\+ == 8 || (\+ >= 10 && \+ <= 14) || \+ == 17 || \+ == 21 || \+ == 29 || \+ == 30)
    pushq    $0                    /* If this is an interrupt that doesn't push an error code, push one ourselves. */
.endif
    pushq    $\+                    /* Push the ISR to the stack. */
    jmp        interrupt_internal
.endr

/* Build a table of all the interrupt stubs */
.section .rodata
.global interrupt_table
interrupt_table:
.rept 256
    .quad interrupt_\+
.endr

[neon flicker]

as for you pushing gs?

why do you do that?

[near tartan]

this might be old code

lol

when i thought that gs == gs:0

💀

[neon flicker]

well uh remove it

and don't forget to remove it from

the interrupt frame struct

[near tartan]

ye

[neon flicker]

and from the add rsp, 0x18

smh, cli on isr entry

[near tartan]

idk if i need it

i'm grasping

[neon flicker]

depends if you use interrupt gates

[near tartan]

no

[neon flicker]

or task gates (I think that's what they're called)

[neon flicker]

y not

[near tartan]

wait

[neon flicker]

in your idt

if you do then on entry, eflags.if is clear

[near tartan]

i guess i do lol

[neon flicker]

then you can remove that useless cli

[near tartan]

won't i corrupt my stack?

[neon flicker]

huh

[near tartan]

nvm

okay it still works in qemu

but idk about real hw

let's see

real

[neon flicker]

idk what this means

[near tartan]

success

[neon flicker]

did it work?

[near tartan]

why does this work suddenly

im confuzzled

[neon flicker]

reboot

for good measure

[near tartan]

k

lol i should implement uacpi

if i just hard shutdown it hangs the uefi on the next boot

[neon flicker]

RetarBIOS

[near tartan]

real

maybe this was just lucky

let me try busybox

[neon flicker]

reboot again

[near tartan]

if that works we have a winner

@grave peak anything advanced my kernel needs for uacpi?

[neon flicker]

memory allocation

[near tartan]

that's it?

[neon flicker]

no

[neon flicker]

https://github.com/UltraOS/uACPI/blob/master/include/uacpi/kernel_api.h

[near tartan]

hm

maybe i can make this a module

[neon flicker]

I wanted to do that many moons ago

but decided against it

because it would be hard to use it in the kernel

[near tartan]

true

okay no it was just lucky

still happens

[neon flicker]

gl then

[near tartan]

oh shit

[near tartan]

i was actually able to cause it in qemu

but only with kvm

so no debugging 😢

[neon flicker]

why can't you debug with kvm?

[near tartan]

idk, if i -enable-kvm then gdbserver doesn't stop at my breakpoints lol

[grave peak]

all basic stuff

[near tartan]

is there any way for me to get -d int logs with kvm enabled

[grave peak]

no

[near tartan]

and gdb?

[grave peak]

yes

[near tartan]

doesn't work for me :(

[grave peak]

as in, no you can't

[near tartan]

fuck

bug doesn't happen in normal qemu which i could debug
bug happens in KVM which i can't debug

i hate everything

[grave peak]

well what u call normal qemu is emulation so its not very precise and doesnt do a lot of checking

[near tartan]

i mean, it's very likely an isr stack corruption thing but i have 0 idea where i have to look

[grave peak]

if it repros under kvm it could be race condition

since kvm is faster by an order of magnitude

or close to that

[near tartan]

race condition between what?

[grave peak]

maybe u enable interrupts somewhere u shouldnt or have a tiny race window

[near tartan]

hm

i'm on a single core right now

but maybe some interrupts are firing where they shouldn't

[grave peak]

yeah

[near tartan]

wait a minute

[grave peak]

I think a minute has passed

[near tartan]

everything is broken

maybe I'd be better off completely rewriting the scheduler

it's the worst part of the entire code base

[grave peak]

lol

scheduler or context save/restore code

[near tartan]

scheduler

[grave peak]

like the algorithm?

[near tartan]

i don't think the save/restore is what's causing issue

it likely breaks at some weird rescheduling

pain

i believe my interrupt stubs are correct so far

but the rest is flawed somehow

[near tartan]

okay it happens during context restore

my scheduler is feeding it garbage, hence the gpf because the CS is wrong

which is good, because i can debug that easily enough

[near tartan]

oh man

one trillion dollars to whoever can help me fix this exception

i'm so confuzzled

[brisk totem]

you should print the error code

okay i helped you fix it wheres my money

[near tartan]

jokes on you

[neon flicker]

it is a page fault

[near tartan]

it's not

it's a gpf

[neon flicker]

where money

there is a page fault

[near tartan]

which happens as a result of the gpf

[brisk totem]

isnt this like a CS/SS gpf

[near tartan]

something isn't returning a sane interrupt frame

yes

[neon flicker]

uh

you can get betterer?

[brisk totem]

just hbreak on every iretq

until you find the issue

lul

[near tartan]

what's hbreak

[neon flicker]

rewrite the kernel

[near tartan]

this isn't obos

rewriteos

[neon flicker]

bro the last time I started a rewrite was -1 days ago

wut

-1 days

[near tartan]

[brisk totem]

hardware breakpoint

its a gdb command

[near tartan]

can i use that with lldb

[brisk totem]

its just a normal breakpoint

except its different

i think lldb uses them if available

[near tartan]

well this is basically unusable

because the bug only happens with kvm

[brisk totem]

uhh

[near tartan]

so no debugger for me

[brisk totem]

you can still do gdb with kvm lol

it just doesnt work as well

[near tartan]

it falls through my break points

[brisk totem]

details :^)

anyway now we know its either a race

or an x86 quirk

do you have multiple cores?

[near tartan]

it's not a race because no smp

[brisk totem]

okay

but you have threads

[near tartan]

ye

[brisk totem]

can you add like

cmp [rsp+10], 0x10; 1: jne 1b right before iretq

or whatever the offset for SS is

[near tartan]

can you do att pls

[brisk totem]

no i cant att

[near tartan]

woe

[eternal wharf]

should be cmpq $0x10, 10(%rsp); 1: jne 1b

[near tartan]

okay will try now

[brisk totem]

also idk if its 10

wait

its definitely not 10 lol

why do you trust me?

[near tartan]

lol 10

[brisk totem]

yeah bro trust

[near tartan]

SS should be 0x20, no?

it's the 5th value in the frame

what am i looking for @brisk totem

this happens in user mode btw

[near tartan]

ah

i think i know what's happening

somehow i'm writing cs = 0x2b and ss = 0x20

when ss should be = 0x23

i have no clue why this is being changed though

let's see if this is a scheduler issue

oh yes for some reason it's saving a context where ss = 0x20

how is this possible

[grave peak]

BTW dont forget uacpi_table_unref as indicated by that warning

[near tartan]

ah yes

can i still use the data provided by the table after unref?

[grave peak]

Like which

[near tartan]

as in, if i get the ptr field of uacpi_table

[grave peak]

Well it will be unmapped thats kinda the point

[near tartan]

oh

oooooh

okay :(

is there a way to keep using the table for me?

or does that not make any sense

[grave peak]

U can keep it if you need it

[near tartan]

e.g. the hpet table

[grave peak]

The warning is there because its an early reference

[near tartan]

i can still access the registers right?

once i saved the actual mmio address

[grave peak]

Some kernels have special early map mechanisms

[near tartan]

i dont

[grave peak]

Ofc

[near tartan]

oki

[grave peak]

In your case its cosmetic then

[near tartan]

i'll fix it though for you

[grave peak]

Just copy the address yeah

You dont need the entire table

[near tartan]

okay terrible discovery, i don't know what this means, but these 2 lines fix the issue

does that mean QEMU is broken?

[grave peak]

Stack corruption?

[grave peak]

Lmao no

[near tartan]

i don't think it's stack corruption anymore

the rest of the registers are fine

[grave peak]

If youre using kvm qemu doesnt really do anything

So if anything its your cpu being broken

[near tartan]

yikes

well the thing is

i don't know where the 0x20 comes from

i've printed out all incoming cs and ss values

at some point 0x23 just becomes 0x20???

which obviously triggers the gpf

[grave peak]

Memory corruption

Add a hardware breakpoint

On that address

[near tartan]

how

[grave peak]

Gdb has a mechanism for that

Watchpoints I think?

[near tartan]

m

what would i be looking for though

i think i can inspect memory with lldb

[grave peak]

When it gets written to with 0x20

[near tartan]

but that's not on a fixed address i thought

since it's on the stack

[grave peak]

Do u get an inconsistent address if you print out the field address?

[near tartan]

wdym by field address?

[grave peak]

Printf(&running->registers.ss)

[near tartan]

oh i get what you want now

i should watch that thread's context store

well, the problem is that my interrupt stub is being passed that 0x20

which i then write

[grave peak]

Hmm

[near tartan]

this is so weird

i'm 99% sure this is not my scheduler's wrongdoing

i don't get it

[neon flicker]

yeah it's obviously the fault of that one hydrogen atom chilling in your cpu

[near tartan]

idfk

[neon flicker]

it threw the results off

and caused qemu to crash

[near tartan]

why would it clear CPL_USER out of the ss

you can even see i pop 0x23 into ss

then it runs the actual code

but gives me back a fucking 0x20

i just noticed, it also seems to set ss = 0 for a kernel thread

this makes no sense

only this field seems to be affected

[near tartan]

this obviously doesn't work on real hw

something is corrupting but I'm so out of ideas

[near tartan]

@fiery marlin holy shit i figured out why the Framework has such weird behavior

it has a legacy keyboard mode

it just works

[brisk totem]

wdym?

[near tartan]

it's connected via ps2 if you don't use usb

[brisk totem]

ah cool

i think its actually behind cros_ec, no?

[near tartan]

idk

[brisk totem]

yeah idk

im pretty sure its done by the embedded controller

[fiery marlin]

lmao

thats actually quite convenient

[near tartan]

yes

[fiery marlin]

I believe the EC firmware is open source, so we should be able to see if its done there

[near tartan]

true

[grave peak]

btw

the reason there isnt uapi pci helpers yet

i got blocked on uapi_status

idk how to do it since obviously there are generic statuses

but i want per-project ones as well

[near tartan]

what have you got right now?

[neon flicker]

So have projects define their own

[near tartan]

how can the api use that though

[neon flicker]

It doesn't

[near tartan]

maybe have something like ELF does for PHDR types

have a range that is reserved for implementations

[grave peak]

yes but it still wont be part of the enum

[near tartan]

yea that doesn't really matter imo

[grave peak]

it matters for type checking

[near tartan]

ah i see

[grave peak]

i wanted to add like

a define

actually u know what we can do

its a bit hacky but

typedef enum uapi_status {
   UAPI_INVALID_ARGUMENT,
   ...

   #ifdef UAPI_DRIVER_UDRM
   UDRM_ENUMERATE_STATUS_CODES
   #endif
} uapi_status;

[near tartan]

enum uapi_status {
    UAPI_STATUS_FOO,
    ...
    UAPI_STATUS_PROJECT = 0x80000000,
};

typedef uapi_u32 uapi_status;

uapi_status udrm_do_foo()
{
    return UAPI_STATUS_PROJECT | UDRM_FOO_IS_BAR;
}

what about this

implicit conversions of an enum to int are allowed afaik

or make a union

union uapi_status {
    enum uapi_status_generic generic;
    enum uapi_status_project project;
};

[grave peak]

very non seamless lol

[near tartan]

yes very

[near tartan]

i'd still just do this

assume status = int

[grave peak]

so how is user supposed to check the return code

[near tartan]

wym

[grave peak]

ret.?

[near tartan]

i don't get it

it's an int

[grave peak]

its a union

u cant do union == UAPI_OK

[near tartan]

i quoted this

the bottom one was a meme

[grave peak]

so the user is supposed to do if (ret == udrm_do_foo()) handle_foo_error();?

[brisk totem]

just make it so that you can define status values in uacpi-libc

[near tartan]

i dont think this is about the values themselves?

i thought it was about how to get project specific codes into the uapi enum

[brisk totem]

if you #define UACPI_STATUS_TYPE you can alias uacpi_staus to whatever you want, and then you gotta #define all the UACPI status codes

[grave peak]

^

pitust this doesnt work

[brisk totem]

why not?

[grave peak]

custom types wont pass typechecking by the compiler

[brisk totem]

why?

[grave peak]

because they arent inside the enum

[brisk totem]

if you #define UACPI_STATUS_TYPE you have to make your own enum with the same items

also thats not how c enums work afaik

[grave peak]

wdym

like redefine the same enum and add extra options?

[brisk totem]

something like that yeah

[brisk totem]

typedef enum x{
    a = 1,
    b = 2,
    c = 3,
} x;
typedef enum y {
    d = 4,
    e = 5,
    f = 6,
} y;

x get_x() { return f; }```
this passes typeck as of gcc trunk

so idk what you are talking about

[grave peak]

huh

this is like not what we want at all

[near tartan]

^

[brisk totem]

i had problems mapping down uacpi status codes into my ones as well

[grave peak]

we want uapi_status to contain driver-specific codes optionally besides the generic ones

its not a mapping problem

[brisk totem]

ah

aah

just have the kernel control status code values

not the drivers

easy

[grave peak]

hm?

[brisk totem]

like, the kernel uapi-kernel-defs.h header (set by the kernel) or whatever is something like c #define UAPI_STATUS_TYPE uapi_status typedef enum uapi_status { UAPI_INVALID_ARGUMENT, UAPI_TIMED_OUT, UACPI_AML_DID_STUPID_SHIT, // from uacpi UDRM_YOUR_GPU_SUCKS_ASS, // from uDRM UHDA_NO_SOUND_CARD, // from uHDA } uapi_status;

etc

and then you can make the layout whatever you want

and you can trivially put all the status values in individual headers

and then #include them all together

[grave peak]

the kernel is supposed to copy paste driver specific statuses manually?

lmao

[near tartan]

[brisk totem]

first of all, that's not that bad

[near tartan]

what's wrong with the way ELF does it though

[brisk totem]

second of all, you can just #include all the header files

[grave peak]

DIY uapi

[brisk totem]

like each driver has a "u<driver>-status-enum.h" header

which is like

all of the entires as enum values

[grave peak]

with like enumerations yeah

[brisk totem]

yeah

so that its just a bit of light macroing

[grave peak]

this idea but manual

[brisk totem]

except that it gives the os all the control around how things actually look like

[grave peak]

what sort of control?

[near tartan]

1 instead of 2

[brisk totem]

also, this lets you set up something like ```c
#define UAPI_STATUS_TYPE EFISTATUS
typedef uint64_t EFISTATUS;
#define UAPI_INVALID_ARGUMENT 2 // EFI_INVALID_PARAMETER
// etc

[grave peak]

like status values

[brisk totem]

what the values are, and what ranges they are in

[grave peak]

how would that work with a macro

[brisk totem]

you make the .h files contain ```c
#ifndef UAPI_INVALID_ARGUMENT
ITEM("Invalid Argument", UAPI_INVALID_ARGUMENT)
#endif

[grave peak]

if I have

#define UDRM_STATUSES \
  UDRM_STATUS(GPU_SUCKS, 0xDEADBEEF, "You gpu sucks") \
  UDRM_STATUS(GPU_SUCKS1, 0xDEADBEEE, "You gpu sucks1")

[brisk totem]

you can autogenerate it trivially with some python before every commit that changes the list

[near tartan]

can we just make error codes 8 byte messages

[grave peak]

lol

[brisk totem]

fucking hell

this is how we got the shitshow that is aml

someone suggesting that 4 byte identifiers are totally fine guys trust

(they are not)

[grave peak]

tbh its what allowed us to get somewhat legible aml disasemblies

[brisk totem]

honestly this + whatever the fuck AML is is why i dont like acpi

[grave peak]

i doubt they would keep full identifiers for release builds

they would mangle them

[neon flicker]

aml's not that bad if you ignore it's existence and let infy do all the parsing for you

[brisk totem]

aml disassemblies right now arent legible at all

unless you are like you

[grave peak]

well u see reg layout and it says like FAN0, 8

u know it controls fan0

[brisk totem]

it would just be called fan0 or something

if they didnt have a stupid naming scheme

[grave peak]

yes but they would probably mangle names for release

[brisk totem]

FDTs dont have people minifying shit

[grave peak]

if they're evil

[brisk totem]

if they're evil they could do that with aml

[grave peak]

fdts dont have bytecode

[brisk totem]

true

[grave peak]

so they dont expose proprietary details

[near tartan]

typedef enum uapi_status {
  UAPI_STATUS_OK,
  UAPI_STATUS_FAIL,
  UAPI_STATUS_PROJECT = 1 << 31,
} uapi_status;

typedef enum udrm_status {
  UDRM_STATUS_OK = UAPI_STATUS_PROJECT | 1,
  UDRM_STATUS_FAIL = UAPI_STATUS_PROJECT | 2,
  UDRM_STATUS_GET_A_JOB = UAPI_STATUS_PROJECT | 3,
} udrm_status;

[grave peak]

wait why do we need two oks lol

[near tartan]

just an example

[grave peak]

actually tbh

maybe we dont care about joining them

udrm can return udrm statuses

but it can have a to_uapi_status

[brisk totem]

also some OSes may want to have multiple "OK" status codes

[near tartan]

OK should default to 0

[brisk totem]

my experience is that dealing with statuses is the most annoying part of uacpi

[near tartan]

then you can do !do_stuff()

[grave peak]

lol how

[brisk totem]

because my statuses are really big

bigger than a uacpi status

[grave peak]

big as in detailed or

[brisk totem]

big as in 64 bits lol

and they dont map down well

[grave peak]

so whats the issue

just INTERNAL_ERROR

u dont have to do precision conversions lol

[brisk totem]

that loses info

and therefore sucks

[grave peak]

oh well

[brisk totem]

it would be much better if you could do proper error propagation

and its also not that hard

[brisk totem]

alternative: the host OS allocates status ranges

[grave peak]

what error propagation

[neon flicker]

smh infy needs to make a uacpi patch for each kernel to convert uacpi statuses to that kernel's statuses

[brisk totem]

like, i encounter error X

[grave peak]

u can technically return any garbage and it will be treated as an error

[brisk totem]

turn it into uacpi status Y

and then uacpi gives me back the same status Y i can turn into X

[brisk totem]

assuming, of course, that i can make my status to be 32 bits

which i cant

because of the wisdom of whoever made uefi

[grave peak]

well

u can always fork and modify the enum to be 64 bits

[brisk totem]

thats super ugly

[grave peak]

and make it use any range

[brisk totem]

just let me do it without patches smh

its really not hard

[grave peak]

like making the enum 64-bits?

i can add that pretty easily yeah

[brisk totem]

make it so that i can #define UAPI_STATUS_TYPE to whatever type i want

[grave peak]

yeah should be easy

[near tartan]

@grave peak untagged enum maybe?

[grave peak]

anyway thats a bit of a tangent

[brisk totem]

and some sort of UAPI_MIN_U<driver>_STATUS for the start of the given driver's status range

[grave peak]

@near tartan i think i have a good idea

so the user has to deal with uapi_status directly only in uapi kernel api right

by returning one of those

[brisk totem]

so the driver just defines ```c
enum uacpi_status {
UACPI_ERROR1 = UAPI_MIN_UACPI_STATUS,
UACPI_ERROR2,
UACPI_ERROR3,
UACPI_ERROR4
}

[grave peak]

we can convert uapi to native driver-specific status type quite easily

even by casting it

but the user calling udrm_initialize can just deal with udrm_status directly and not uapi_status

it may or may not be inheriting from the generic statuses

so my idea is basically dont expose uapi_status to user from driver-specific functions

[brisk totem]

just do this lol

so that you can have a single set of status codes

instead of 10 different sets

[grave peak]

this doesnt solve any problems that we're discussing

please

[near tartan]

yes

[brisk totem]

what is the problem anyway? seems like it solves the "how do you reconcile different projects' status codes together" problem just fine

[grave peak]

my suggestion is we just dont do that

because there's no need for it

DRM in linux has its own error codes

ACPI has its own error codes

no reason to keep them under the same enum

@near tartan thoughts?

[near tartan]

agree

[neon flicker]

Agreed

[grave peak]

i will take that for uacpi yeah

[near tartan]

i mean, we should return uapi_status whenever possible, no?

[grave peak]

i dont think so, because like if you're calling udrm_initialize why do u care if it returns uapi_status or udrm_status?

it doesnt save u any work by doing that i think?

[near tartan]

no

[neon flicker]

Just make all return a boolean

[near tartan]

🤢

[grave peak]

so like, what if uapi_status is only for the actual kernel API statuses

would that work fine

[near tartan]

yea

[neon flicker]

That's what I was initially thinking it would be

[near tartan]

i would return uapi_status for i.e. udrm_initialize

[grave peak]

but why?

what if the error code is UDRM_I2C_TIMEOUT?

[near tartan]

hm

unless you want to define _OK, _FAIL, _whatever for all projects that would be the way to go

okay nvm thinking about it, it doesn't make sense

[grave peak]

like on one hand it would be nice

but then like we have an enum that has UDRM statuses which can technically be returned from uacpi now

so if u do a switch (uacpi_ret) u have to include those lmao

well u can add a default case but still

its kinda just extra noise

[near tartan]

tru

[grave peak]

what if i just let you override the statuses completely, like the entire file with your own uacpi_types.h, would that work?

i can make a macro so that its easier to add them all

[brisk totem]

i mean yeah

that works too

[grave peak]

or would min solve it completely for u

or u probably want _MAX not min if u want to make it 64-bits lol

[grave peak]

what would u define this to if you wanted to make it like efi_status

i guess 0xFFFFFFFF + 1

[brisk totem]

i would define MIN_UACPI_STATUS to 0xc300000000000000

[grave peak]

wtf

[brisk totem]

which is in the oem reserved range

[grave peak]

ohh

that makes sense

[brisk totem]

i think so at least

uh

no

ok now its the correct value

oops

[grave peak]

i thought u kinda stopped doing the uefi thing

[brisk totem]

yeah idk im still doing EFISTATUS types though

because they are neat

[grave peak]

they are good yeah

[grave peak]

everyone using EFISTATUS must also do _In_ and _Out_ otherwise u get kicked out of the efi club

[brisk totem]

i mean, they are stolen from NTSTATUS

[brisk totem]

im doing rust

also i dont hate myself

[grave peak]

lmao

[near tartan]

lol

[near tartan]

i'm still stuck on this god damn interrupt frame corruption issue

i have no idea why this is happening

and why does it only affect ss

this shit is really consistent and reproducible as well

the only time i'm setting these values is during thread creation, and with the correct values as well

how the fuck????

please god find me an x86 god that knows what the hell is happening here

[neon flicker]

skill issue

[near tartan]

okay @eternal wharf hbreak seems to work but it's not giving me any info i didn't already have

the values pushed onto the stack are the same that i am reading

i was able to narrow it down a bit though

something about the syscall handler is broken

WHAT THE FUCK

ARE YOU JOKING

--- a/kernel/arch/x86_64/system/arch.c
+++ b/kernel/arch/x86_64/system/arch.c
@@ -36,7 +36,7 @@ void arch_init_cpu(Cpu* cpu, Cpu* boot_cpu)
        // Enable syscall extension (EFER.SCE).
        asm_wrmsr(MSR_EFER, asm_rdmsr(MSR_EFER) | MSR_EFER_SCE);
        // Bits 32-47 are kernel segment base, Bits 48-63 are user segment base. Lower 32 bits (EIP) are unused.
-       asm_wrmsr(MSR_STAR, (offsetof(Gdt, kernel_code)) | (offsetof(Gdt, user_code) << 16) << 32);
+       asm_wrmsr(MSR_STAR, (offsetof(Gdt, kernel_code)) | ((offsetof(Gdt, user_code) | CPL_USER) << 16) << 32);
        // Set syscall entry point.
        asm_wrmsr(MSR_LSTAR, (u64)sc_syscall);
        // Set the flag mask to everything except the second bit (always has to be enabled).

you can not tell me i missed this

turns out the amd64 manual is a pretty good place to tell you where these values are actually loaded from

but thank you qookie for the tip with hbreak

[near tartan]

i'm baffled how this even worked to begin with

OH WAIT IT DIDNT

i just never tried running with kvm

smhhh

[near tartan]

anyways we are so back

[near tartan]

@fiery marlin i'll continue here, but i've got some questions

if i don't need to modify the device tree, does smoldtb need any allocations?

[fiery marlin]

Sure thing - I'm about to head out for brekky so my replies might be a bit slow

[near tartan]

yea whenever you can 😃

[fiery marlin]

It does build an internal representation of the tree to move around it easier, so it will need an allocator

[near tartan]

ah

[fiery marlin]

But you can use it like flanterm and give it a static buffer, or pass it your own malloc if you have one available

[near tartan]

it's not a problem, since i don't use the dtb for usable memory

i evaluate it as soon as i have slab initialized

[fiery marlin]

Ah nice

[near tartan]

uacpi benchmark is up to 1.6 mil

[finite grail]

where might this be?

[near tartan]

huh

how did we get here

what

mlibc on fent

here's a better look

what the fuck do you mean no dynamic section

it's clearly there

i really don't know what could be causing this at all

wild

[fiery marlin]

I know it says section, but is it looking for a dynamic segment?

[near tartan]

that's also there

[fiery marlin]

Hmm ok

[near tartan]

it works sometimes

i'm suspecting a VM meme

but all i did was replace config variables with defines

yea it was a vm meme

onto the next shit

@neon flicker reference

(fork broken)

[near tartan]

can't wait to finish fat so i don't need an initrd anymore

[uncut jackal]

heyy you're running busybox?

can you send me your config? I'm trying to build busybox for linux-mlibc

[near tartan]

sure

[uncut jackal]

it's a hassle manually disabling everything that doesn't build

[near tartan]

https://github.com/menix-os/bootstrap/tree/main/pkg/busybox

also note the patch

[uncut jackal]

do you just build what you need or do you build everything you can?

[near tartan]

i think i have a bunch of things disabled that didn't compile

like init

or linux stuff

[uncut jackal]

for me init compiles but bootchartd (it is also in init/) doesn't? or maybe it just fails before reaching init so I didn't notice

[uncut jackal]

is that menix specific or is it for mlibc

[near tartan]

i think this is an mlibc thing?

something about header options

[uncut jackal]

ah ok so then i will need it

thanks!

[near tartan]

just try to see if that compiles

i need to port openrc

[uncut jackal]

oh good archival and stuff builds?

that's what I need for nixpkgs bootstrap-files

[marsh holly]

based

I tried porting openrc but couldn't get it to compiled

[near tartan]

openrc my beloved

[fair lintel]

xbstrap with extra steps

#685151198453825566 message

[near tartan]

yes

xbstrap if it didn't have any features

the only reason i don't use xbstrap is because i hate yaml to death

[storm bobcat]

do you use a container

for your stuff

[near tartan]

not yet

but i will

currently it's jinx ordered on aliexpress

[near tartan]

i am so extremely tempted to convert to a microkernel

i'm at a point where i could do that without refactoring all too much

[grave peak]

nooooooo 💀

[near tartan]

💀

i'm cooked

[grave peak]

why do u want a microkernel?

[near tartan]

idk

try something new

"""new"""

[grave peak]

toy story meme

[near tartan]

well the toy story meme is "monolith with limine"

but nothing ever happens so it'll be another nothing burger

[grave peak]

s/monolith/microkernel

[near tartan]

[grave peak]

but no like if it gives u extra motivation to work on the project thats cool

[near tartan]

it will give me extra work

at least

i don't know nearly enough about microkernel architecture

but it sounds so clean in theory

[grave peak]

its just

spawn server

epoll()

write(ipc_fd, pls-do-something-i-could-do-via-syscalls-10-times-faster)

[near tartan]

rofl

tbh who needs messages when you can just do dynamic linking across servers 🧠

[grave peak]

we had that thing it was called a modprobe

[storm bobcat]

that goes against the whole point

of a microkernel

which is isolation

[near tartan]

i thought it meant isolation from the kernel

[grave peak]

isolation from each other

and decoupling of components

[near tartan]

hm

i may be stupid

[grave peak]

u could dynamically link them

[near tartan]

that would be fast at least i guess?

[grave peak]

the idea in your case that u can at least technically restart the monolith microkernel

since its in userspace

which is fair

[near tartan]

it's just that i feel like i've hit a wall of motivation

[grave peak]

wall of motivation?

like u have a lot of it or

[near tartan]

no

english moment

a wall that stops my motivation

idk what exactly it is

maybe it's all in my head

[grave peak]

like the fact that your kernel is a monolith?

[near tartan]

kinda, it feels like i'm just reinventing the wheel with EVERY aspect of this kernel

i want to do something unconventional (even if it's stupid)

[storm bobcat]

so do cool stuff

[grave peak]

nt clone

[near tartan]

i made the project to learn after all

[storm bobcat]

and not shitty unix clone #487598372

[near tartan]

exactly

[grave peak]

special respect for people that do nt clones

[near tartan]

i don't really want to do a clone of anything

[storm bobcat]

so like I said

do cool stuff

[grave peak]

like what?

make an entirely new thing ig

your own api

[near tartan]

i still want a posix layer at least

[storm bobcat]

an actually good vmm

vfs

scheduler

[grave peak]

yeah like xnu which has both

[near tartan]

both posix and nt?

[grave peak]

posix and their own thing

[storm bobcat]

they are not mutually exclusive

[eternal wharf]

come join us it's fun we have turing complete functional macros in yaml

[near tartan]

:(

give me a convincing reason

what can i do with xbstrap

[eternal wharf]

well one reason to use it is that it's an existing tool that (approximately ) works

[near tartan]

does xbbs work with non-managarm packages

if yes i might consider

[eternal wharf]

i mean you should be able to set it up i'm pretty sure

[near tartan]

i can ask arsen

[grave peak]

make xbbs require managarm abi compatibility 💀

[near tartan]

is he around rn?

[eternal wharf]

considering it's 2am he's possibly asleep

but ive no idea what his sleep schedule actually is

[near tartan]

that's what i thought

i was more concerned about his timezone

[eternal wharf]

utc+1

[near tartan]

surely he has an irc bouncer on right?

[eternal wharf]

and yeah he does

[near tartan]

he'll see it in the morning then

[eternal wharf]

but yeah xbbs should be hostable on your own and i think the ansible scripts we use for managing the machines are available on gh