Astral

[grand shadow]

damn thats fucking hot

[robust geyser]

yeah thats a lot of fpses

[winged basin]

fastral

[robust geyser]

how the heck do i make mesa do llvmpipe

LIBGL_ALWAYS_SOFTWARE=1 doesnt work

ok i had to set some more variables, llvmpipe on my host with 1 thread does 3620-3650 fps

astral with 4 threads gets only 200-300 more fps, on linux it's 2x more

but host vs guest probably makes quite a difference

[grand shadow]

I also need more shootdown optimization since thats what I think the big smp issue is?

I think its in general memory subsystem contention and that

or host vs guest bs too

[robust geyser]

yeah i see a bunch of munmaps and mmaps

systrace is kinda useful :^)

[carmine swallow]

I wonder how can file->vnode be null (it was in syscall_fsync)

[gritty shore]

How do you set it to use one thread?

I get around 4800 FPS

[robust geyser]

LP_NUM_THREADS

[gritty shore]

I know because it's all I've been doing for a week trying to make my impl faster

Mine runs at 5200

[carmine swallow]

and also there is some weird stuff happening after I run X two times, it fails to find objects that are clearly there (ls worked before I ran X) + sometimes when you try to type in a command like /usr/bin/bash it decides to strip off some chars from the end (though idk if that's related or if its some skill issue within hzlibc)

[grand shadow]

wtf

[grand shadow]

happy new years!

[willow rapids]

i'm jealous

[neon crane]

fireworks.nse if it was good

[gleaming bay]

Memory: MiB / MiB 🔥

[grand shadow]

I should copy managarm and do a 2025 retrospective blog post

[grand shadow]

doing the gha ci for mlibc-linux-os-test made me wonder if I could also do it for astral to create a minimal image

[tired robin]

Guys

[opal lotus]

guys
disappears

[dense valve]

Uptime: secs 🔥

[proper meteor]

My retrospective: nothing that wasn't already talked about in the previous articles

Nah I'm exaggerating, there's stuff to talk about, but not as much as I would have liked to

[grand shadow]

@robust geyser did you end up getting any more progress into xhci?

[robust geyser]

not really, i'm still stuck on the usb stack lol

xhci is functional, just the usb stack

[grand shadow]

hmmm

I dont really have any experience with how that works to give any ideas

[robust geyser]

yeah sadly me neither, i know roughly what to do but i dont want it to end up completely shit

but maybe im overthinking and expanding it to work with ehci/uhci wouldn't be as bad in the future

[grand shadow]

wouldn't it be something like

mass storage-----\ / xhci
hid ------------------> usb -- ehci
etc. --------------/ \ ohci

and the only thing you have to abstract there is simpler things like interrupts and data transfers?

[robust geyser]

yeahhh something like that, but the details is where it gets fuzzy for me

i plan on having a single usb worker thread that does the port management, similar to keyronex

except in keyronex it's per controller

actually i think it being per controller might make things slightly easier

[grand shadow]

certainly

less locking etc

plus you could bind a controller per cpu and pin that thread to the cpu

I dont think I support allocating interrupts in other cpu but that shouldn't be too bad to do

[robust geyser]

god damn it, i think i need to pull out a piece of paper and actually write it all down to figure out how things should work

idk what needs to happen inside the worker thread and what doesn't

[grand shadow]

thats always a good idea I always do that when implementing something difficult

better to organize your thoughts written down than all around our brains

especially with our short attention spans nowadays :p

[robust geyser]

i really want to write the device enumeration code in a synchronous way, using blocking operations

but that means i can only enumerate a single device at a time

driving everything using callbacks makes for some ugly code, which is annoying

eh whatever, i think enumerating one device at a time is an okay limitation

[grand shadow]

how long does enumerating a device take?

if its something like 1ms it really is just microoptimizing it atp

[flat copper]

is spawning a ton of threads (well, dozens at most ig) not an option

[robust geyser]

well, you need to issue an "enable slot" command, an "address device" command, fetch some descriptors and at that point you know what class driver to use so you can switch to async completions

fetching descriptors is probably like 5-6 transfers in total, each transfer is 3 trbs

so you submit a total of 20-30 command per device enumeration

it probably takes like 50-100ms

[grand shadow]

oh dang

[robust geyser]

that's like an extreme case i'd say, i don't know honestly

maybe i should just suck it up and do async all the way

[grand shadow]

worst of the worst cases I write a worker thread pool impl and you use that to dispatch them on parallel

thats probably a good thing to have anyways

but for a first implementation having it be serial shouldn't be that bad

how many devices does a system usually have connected?

[robust geyser]

keyboard, mouse, maybe a usb drive

[grand shadow]

thats not so bad

[robust geyser]

in qemu device enumeration is really quick, idk about real hardware

that's what i'm worried about considering this whole thing was a "let's make astral more usable on real hw" project :^)

booting astral off usb would be sick

you have a fat32 driver, right?

[grand shadow]

I do

its not the best but it works

[robust geyser]

that means you'll be able to install astral from usb, epic

[grand shadow]

though I would rather when booting out of a usb drive use something like squashfs or w/e

idk the name of the cow to memory fs thing

[robust geyser]

that might be it

[grand shadow]

yeah seems like so

but yeah, if it ends up taking too long to start on real hw we can optimize that later, its something that doesn't sound like it would need an insane amount of rewriting to fix

[robust geyser]

ok then i'll try to get something going soon, it is my bedtime soon and im tired lol

but i think making it xhci only for now would be fine

im also figuring out how usb hubs work along the way so that also slows me down a bit

[grand shadow]

holy shit astral usb support better than managarm?

[flat copper]

overlayfs?

[grand shadow]

idk

anyways, I should get to work on the astral page cache rework thing

last thing I was doing related to that was supporting bigger read/writes in a single operation

on nvme

by actually setting up a prp list properly lol

its not something that will immediatelly have an effect but once I have the new page cache working it'll be able to cluster pages in using an iovec

and also do that for virtio block

for the virtio block case theres the whole descriptor allocation thing but I might as well just write something like a general purpose descriptor allocator for the kernel

so that I can use it in other drivers

and also have to make sure one operation won't starve the rest

can't wait for disk i/o to actually not be unbearable

the simple page cache already helped a ton but I've outgrown that

[willow rapids]

i have none

[grand shadow]

I also have to fix some os-test stuff, the pty tests seem to hang

lowk want to have a ci thing similar to that mlibc-linux thing I did

[grand shadow]

https://tenor.com/view/spongebob-screaming-spunch-bob-spunch-bop-spongebob-sad-spongebob-gif-26152448

nothing ever works

[tired robin]

Somebody who know how nvram works? like except the uefi function to read it

[opal lotus]

bro wrong thread

[formal patio]

wrong thread, X Y problem

[viscid flame]

how hard is xhci usb stick driver

[carmine swallow]

I don't think its that bad, its just scsi

[robust geyser]

it's not specific to xhci, but usb

and yeah, it's just usb mass storage which uses scsi behind the scenes

[robust geyser]

okay, i got to the point where my usb stack is trying to fetch device descriptors but i need to restructure some xhci stuff to be able to complete transfers - after that i should be able to start expanding the usb stack, writing class drivers (hid, msd) lol

the usb stack is still kinda rough but it's much better than everything being hardcoded inside xhci.c

[robust geyser]

it finally woooorksssss

[grand shadow]

[robust geyser]

i totally did NOT spend the past 40 minutes debugging a typo

[grand shadow]

💀 what was the typo

[robust geyser]

- setup_trb.dw0 = (uint32_t)setup->bmRequestType | ((uint32_t)setup->bmRequestType << 8) | ((uint32_t)setup->wValue << 16);
+ setup_trb.dw0 = (uint32_t)setup->bmRequestType | ((uint32_t)setup->bRequest << 8) | ((uint32_t)setup->wValue << 16);

:3

[grand shadow]

https://tenor.com/view/skeleton-gif-26826812

[robust geyser]

i went insane over why qemu was stalling on the setup trb

i was ready to give up

anyway with this out of the way...

tomorrow i will continue with configuring endpoints and probably the first class driver, which will be hid keyboard

i'm not doing a full hid parser yet, so i'll use boot protocol instead

should be good enough for now

[grand shadow]

hell yeah

good work

[robust geyser]

thanks

[marsh sparrow]

@sharp carbon I hacked together an shm implementation and it has a big impact on glxgears perf on Managarm

I noticed that it uses this case though:

   Linux permits a process to attach (shmat(2)) a shared memory
   segment that has already been marked for deletion using
   shmctl(IPC_RMID).  This feature is not available on other UNIX
   implementations; portable applications should avoid relying on it.

Or actually, it may only try to do another attachment from the same process

but it definitely does an shmat of a IPC_RMID'd shm object

and needs it to succeed

[grand shadow]

Huh, interesting

[marsh sparrow]

so if you didn't implement this lazy deletion behavior that explains why didn't see a perf improvement

I think the relevant client side code is here:
https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/gallium/winsys/sw/xlib/xlib_sw_winsys.c?ref_type=heads#L122

[sharp carbon]

I don't quite remember how I implemented it but that's definitely a possibility

[marsh sparrow]

No idea how this even works on BSDs

the mesa comment even says that the RMID needs to be after the attach on BSDs but it's immediately RMID'd in the creation function afaict

It might just fall back to something SCM_RIGHTS based on BSD

[marsh sparrow]

Actually at least on freebsd it works by default since 2015: https://reviews.freebsd.org/D3603

which is probably why nobody complained when Mesa changed it's strategy to RMID immediately in 2023

[robust geyser]

idk how, but that happens lol

shit just dies 💀

[wild marsh]

nvm

[robust geyser]

did u mean to send that message here?

[wild marsh]

yes

[robust geyser]

ah ok sorry

i was a bit confused because it seems random lol

[robust geyser]

well some more progress, i wrote a very simple hid boot protocol driver (no report parsing yet) but i don't seem to get any activity on the intr in endpoint, the controller doesn't even process the trb that i enqueued so that's probably why - after i figure it out i should be getting some hid reports in

usb_xhci_fetch_trb addr 0x000000007e5d4070, CR_CONFIGURE_ENDPOINT, p 0x000000007d417000, s 0x00000000, c 0x02003001
usb_xhci_slot_configure slotid 2
usb_xhci_ep_disable slotid 2, epid 3
usb_xhci_ep_enable slotid 2, epid 3
usb_xhci_queue_event v 0, idx 31, ER_COMMAND_COMPLETE, CC_SUCCESS, p 0x000000007e5d4070, s 0x01000000, c 0x02008401
usb_xhci_fetch_trb addr 0x000000007e5d4080, TRB_RESERVED, p 0x0000000000000000, s 0x00000000, c 0x00000000```
it enabled the endpoint, but for some reason nothing else happens

[viscid flame]

did you setup ioc ?

[robust geyser]

yes

as i said the trb is not being processed

i ring the doorbell but it doesn't try fetching another trb

i send a usb SET_CONFIGURATION request, i do the hid boot protocol setup (send SET_PROTOCOL with wValue=0 and SET_IDLE with wValue=0), i set up the endpoint context, set bits 0 and ep_index in the input context's A bitmask, i submit a Configure Endpoint TRB

after that i get the logs from above, which indicate that EP with ID 3 was enabled, that's EP 1 IN, which is the interrupt endpoint

and after that i try submitting a Normal TRB to the endpoint's queue and ring the doorbell but nothing happens

i guess i'll compile qemu with DEBUG_XHCI to figure out what's going wrong

holy shit i am retarded

i forgot to set up the device context

thanks qemu for not batting an eye 👍

[robust geyser]

🔥

the 4 byte reports are from the mouse

[analog berry]

crazy work

[grand shadow]

Good stuff

[flat copper]

astral usb before working astral ps2

[grand shadow]

Lmfao so true

[robust geyser]

does your keyboard stack not have the concept of a super/windows/meta key?

i might be genuinely blind but i dont see it

[grand shadow]

Nop

U can add it if u want

[robust geyser]

fair

ill just skip it for now, not a big deal

baller

time to make mouse work and boot into xorg

[willow rapids]

xorg is love, xorg is life

[analog berry]

did u write a hid parser as well?

[robust geyser]

nah, this is just boot protocol

but i want to try writing a proper hid report parser

[analog berry]

ah

[robust geyser]

that way i could use qemu tablet instead of mouse

and get proper absolute positioning

the qemu gtk backend seems broken for some reason, i can only move the mouse on my 2nd screen and it doesn't capture properly lol

on my main screen it only moves the mouse for one frame after capturing, so you have to uncapture and then make a big swing while clicking the window so it moves it lol

[grand shadow]

SIGMA

I think my mouse thing only supports relative movement but it shouldnt be too difficult to add an absolute position flag or w/e

[robust geyser]

yeah no i wasn't worried about that

but it's gonna take a whiiile for me to write a proper hid parser lol

i have no idea how that thing works

[grand shadow]

Damn is it that bad

[robust geyser]

and it honestly scares me

eh, kinda

you basically get a bytecode-ish description of how to parse reports

[sharp carbon]

on a scale from JVM to AML how bad is the bytecode

[robust geyser]

somewhere in between, it's not that bad

what scares me is that it tells you how to parse it on a bitwise level

[grand shadow]

uhid at infy

[young chasm]

the sdl backend works much better with mouse capturing, i moved to it when i added usb-tablet (it auto captures keyboard when mouse is over qemu and releases it when mouse leaves it)

[robust geyser]

the report field widths are in bits

[robust geyser]

the only gripe i have with the sdl backend is that ctrl+shift+q doesn't work to quit qemu

but yeah i noticed that it works better with regard to capturing mouse

[young chasm]

yeah and the compat monitor does not support resize and scroll :D

[willow rapids]

is it the one that looks like vga text mode?

[robust geyser]

this thing

[neon crane]

i prefer the sdl backend because it doesnt completely suck at capturing the mouse, although i think thats just because im on windows

[neon crane]

i usually use telnet for that

[willow rapids]

on windows with the gtk backend the qemu monitor looks like vga text mode

here

[robust geyser]

ah

[young chasm]

this is the sdl one on linux

[willow rapids]

ah so it's what i thought it would be

[robust geyser]

oops lol

i also had to comment out ps2 init because otherwise xorg would not take any input from my usb mouse

[analog berry]

i dont think its even turing complete, its basically just a list of offsets and stuff i think

[robust geyser]

yeah, srry for wording is badly 💀

it's just a weird description format

[analog berry]

yeah its basically designed so a device can spit out the byte data in any way it wants

[robust geyser]

(gdb) bt
#0  _panic (msg=msg@entry=0x0, ctx=ctx@entry=0x0) at lib/panic.c:20
#1  0xffffffff8006f877 in sched_yield () at sys/scheduler/scheduler.c:184
#2  0xffffffff800356c2 in poll_dowait (desc=desc@entry=0xffff800090d09eb0, ustimeout=0) at io/poll.c:108
#3  0xffffffff800671a2 in syscall_poll (fds=0xd28000, nfds=3, timeoutms=<optimized out>) at sys/syscalls/poll.c:76
#4  0xffffffff80075784 in arch_syscall_entry ()
#5  0x0000000000000000 in ?? ()```

funny

lol i can reproduce this quite consistently

let me check if it also happens without xhci/usb lol

nope, that means something is wrong with my code

amazing 💀

[grand shadow]

Do u sleep with ipl => IPL_PDC

[robust geyser]

good question, probably considering i do not touch ipl anywhere in the code

oh right i forgor i'm not allowed to block in dpcs 💀

god DAMN IT

[grand shadow]

You arent 💀

[analog berry]

btw mathew what are u working on for astral atm

[grand shadow]

I was working on a proper nvme prp thing and then on a descriptor allocator for virtio-block etc so I can do proper > PAGE_SIZE dma

[robust geyser]

can i wake threads up from an isr?

[grand shadow]

One of the steps for page clustering for the page cache

[robust geyser]

or should i do it from a dpc

[grand shadow]

Can be done from an isr

[robust geyser]

okay good

[analog berry]

ah cool

[grand shadow]

After that its adapting non-cached i/o and then doing some fork posix bs related to dma I once saw korona talk about

[analog berry]

when drm

[analog berry]

lol

[robust geyser]

okay nice, it works flawlessly after i moved all the blocking stuff to a thread lol

i'm not very happy with the design tho but mathew will be the judge of that

also idk if you saw my message about the ps2 mouse being preferred over the usb one in xorg?

not sure how to handle that

[grand shadow]

Oh yeah thats cuz it just opens /dev/keyboard0

Andr /dev/mouse0

[robust geyser]

ah

so what would be a solution, multiplex all of the input devices in the xf86-input-{keyboard,mouse} drivers?

[analog berry]

btw how does it even know to open those

did u have to patch that in

[robust geyser]

yeah

[grand shadow]

It has an astral specific patch yes

[grand shadow]

Hmmm no idea

[analog berry]

ah

[grand shadow]

I wonder if theres a way to tell it to use multiple keyboards/mouses?

If not worst cause we make a /dev/keyboard that can select a specific keyboard with an ioctl or just has data from all other keyboards ditto for mouse

[robust geyser]

the patch has this line char *kbdPath = xf86SetStrOption(info->options, "Device", "/dev/keyboard0");

which suggests you can override the keyboard path somehow

same with mouse

[analog berry]

wouldnt a proper solution be to listen on all mouse and keyboard devices that exist?

like on a laptop u can use both a touchpad and a usb mouse at the same time etc

[robust geyser]

yeah, i'm assuming that's handled in userspace somehow and not by the kernel

[analog berry]

yeah

thats possible in astral as well right

u just have to patch it to open all keyboards

[grand shadow]

Thats the issue idk how those xf86 drivers can support rhat

Since atm it only opens one

I could try looking at the linux or other oses versions

[analog berry]

yeah maybe check out how the linux driver does that

probably something to do with evdev

btw looks like even freebsd supports it

https://en.wikipedia.org/wiki/Evdev

maybe astral should as well

[robust geyser]

userspace still has to find all input devices, open and then multiplex them

but yes, evdev would be very nice

[analog berry]

if u do evdev u can just use the builtin xorg driver

it should have all of that implemented

[robust geyser]

that's true

[analog berry]

but i guess right now u could steal the multiplex code or smth

[grand shadow]

the xf86-input-keyboard for sun just opend /dev/kbd

[robust geyser]

i got it to pick up the mouse but keyboard doesnt work now lol

it turns out you can change the input device in xorg.conf

[analog berry]

oh cool

[grand shadow]

nice

bsd just opens /dev/wskbd

so yeah

xf86-input-keyboard just doesnt support that

[analog berry]

does bsd just multiplex in the kernel or something

thats pretty bad design ngl

[grand shadow]

hurd does something even cooler it just passes consoleFd

static Bool
OpenKeyboard(InputInfoPtr pInfo)
{
    pInfo->fd = xf86Info.consoleFd;
    return TRUE;
}

[robust geyser]

ah i know why overriding the keyboard path doesnt work

because the driver gets the path from xorg.conf

and then just hardcodes keyboard0 anywayu

[grand shadow]

trolled

I wrote that patch like 3 years ago so I dont even remember how that shit works 💀 💀

[robust geyser]

thats fair

[grand shadow]

its the same patch as this

old astral ☠️

man I wish discord allowed u to update the pictures

[robust geyser]

holy

[grand shadow]

wait turns out you can

tested it on a private server

if u delete the image and pass a link instead

its not working here wtf

[robust geyser]

https://github.com/48cf/Astral/commit/5174f05303bcf1dcf0f0c35761f19f7116f8d19c

i don't want to upstream it just yet, considering it's pretty shit lol

and it doesn't do proper hid

also the two files, usb.c and xhci.c, probably have more asserts than the rest of the kernel

oh, and the branch includes a marginally better implementation for urandom

i was fucking around and found out the one astral had was complete dogshit (no offense but it was literally sampling the current time from boot ☠️)

and it was very slow, it took like 10 seconds to cat /dev/urandom >/dev/fb0

[grand shadow]

I know lmao I just did some bullshit so I would have one

also discord is fking stupid it doesnt want to embed anythinbg on the post now

[robust geyser]

i replaced it with my old shitty mt implementation

and now it can fill the framebuffer with truly pseudorandom garbage in less than 0.1s

🚀

[gleaming bay]

Oh shit watch out rust because this is blazingly fast

[grand shadow]

BLAZINGLY 🔥 FAST 🚀 GARBAGE 🦀

I'll take a look at the xhci code once I am done with this prp shit

[robust geyser]

yeah no worries

[grand shadow]

I'm having to rewrite the function because me from months ago did it horrendously wrong

[robust geyser]

any work that i do will hopefully be contained to the usb stack now

[grand shadow]

tho keep in mind I know jack shit about xhci it'll be more general design stuff

[robust geyser]

that's exactly what it needs tbh

i just wrote it based off vibes

there's a few weird things that will need a clean up

mainly the way i do completions, theres like 3 different structs that i use for that 💀

[grand shadow]

can't bitfields cause issues? or has that not been a problem anymore in modern gcc

[robust geyser]

i think they have some weird semantics but i'm not doing anything weird

[elfin turtle]

afaik it's fine. technically the compiler can reorder them but gcc/clang dont. so they aren't portable but rarely do I see people who dont abuse the hell out of gnu extensions

[grand shadow]

I see

[grand shadow]

small issue wrt the init routine for hid and xhci: depending on how those get put on the init section by the linker the xhci code would run before any class drivers would be registered, as the xhci init routine does not depend on the class drivers routines

my suggestion would be moving the class driver thing to an usb.c init routine and having the class drivers expose themselves in a section like with timekeeper stuff

[robust geyser]

oh, hmm

i'll look into that

[grand shadow]

I think you might not even need a linked list for the drivers anymore then? since then you can just iterate over a section of pointers to those structs

so no usb.c init routine needed

[robust geyser]

that's true, good point

[grand shadow]

lmao I am seeing that in hid, if you look at the usb port wrong during init it'll assert fail

[robust geyser]

absolutely

[grand shadow]

would be nice to turn a bunch of those asserts into error returns later, but thats not an immediate concern

[robust geyser]

yeah, that's why i decided to make a lot of these functions return int

error handling should be pretty easy to add

and i should also look into not leaking a million structures related to transfers every time you make a transfer

detailssss

i fixed the usb class driver stuff, now it uses a section to iterate through them

i ripped it from timekeeper sources just like you said

[grand shadow]

based

[sharp carbon]

no that happens on linux as well

[neon crane]

i see

[willow rapids]

the gtk backend also makes the mouse more laggy

[robust geyser]

@grand shadow sorry for ping but i have a question, do you know if there's a sane way to delay root mounting for some amount of time so i can enumerate usb devices? i'm working on msd class driver and it currently panics before it can enumerate them lol

[grand shadow]

hmmmm

maybe it would be sane to just wait for usb device enumeration to be complete before moving on? or have some sort of "pending inits" thing that is waited before doing anything related to mouting

how does linux handle that sort of stuff I wonder

brb

[grand shadow]

seems like linux has an argument rootwait which tells the kernel to wait for the root to be available before mounting

[robust geyser]

ah cool

[grand shadow]

something like that could be implemented for astral, it shouldn't be super complicated especially if you just do a busy check -> sleep loop

as I dont have anything like inotify

also btw

        printf("xhci: controller doesn't support msi-x\n");
        return -ENODEV;

[robust geyser]

whoops

[grand shadow]

in astral errno returns are positive

[robust geyser]

oh really?

[grand shadow]

yeah

[robust geyser]

oh yeah i see it now

i need to adjust all of my code lol

[grand shadow]

I try to keep returns for faillable functions only for error propagation

[robust geyser]

i think i also used negative errno returns somewhere in usb code

[grand shadow]

and instead use a pointer

yeah thats where I found it originally I just ctrl + f'd the first file I had open

💀

[robust geyser]

return best_driver ? 0 : -ENODEV;

this too

[willow rapids]

first os i've ever seen doing that lmao

although tbf i haven't really looked at many oses' source code

[grand shadow]

// reset the port and shi...

https://tenor.com/view/skeleton-gif-26826812

[robust geyser]

lmao

i already implemented that

it's just hub->ops->set_port_feature(hub, port, PORT_RESET);

of course with the additional __assert(ret == 0);

now i need to implement scsi so i can do usb msd

[grand shadow]

/dev/sda will be real

[robust geyser]

sda is so dumb

i made block_register allocate names in the format blk%d

but we can change it if you want sd[a-z]

[grand shadow]

I would rather U just call it /dev/scsi0

bro

block_register takes a name

[robust geyser]

yeah i know

[grand shadow]

and parted depends on that

💀 💀

[robust geyser]

wdym parted depends on that

[grand shadow]

at least my implementation does

it uses the name to determine which type of disk it is

[robust geyser]

????

are u fucking serious?

[grand shadow]

so /dev/nvme* is nvme /dev/vioblk* is virtio-block

yeah

[robust geyser]

no wayy

[grand shadow]

I think linux also does it this way?

[robust geyser]

okay well then, i'll just generate sd[a-z] then 💀

if you hit z you panic

[grand shadow]

bro just do scsi0

to infinity

[robust geyser]

but usb devices show up as sd[a-z] on linux...

[grand shadow]

I am not linux

[robust geyser]

based

[grand shadow]

if anything depends on it actually being named sda outside of linux specific code thats just stupid

in linux virtio block is vd* and in astral its vioblk*

I accidentally did the same thing the bsds do ☠️

they name it vioblk

[robust geyser]

    char name[8];
    snprintf(name, sizeof(name), "scsi%d", __atomic_fetch_add(&block_dev_id, 1, __ATOMIC_SEQ_CST));

    block_register(&desc, name);```

🙏

nothing will go wrong trust

[opal lotus]

(has linux-rp option enabled)

[grand shadow]

ok mister linux-* options

[opal lotus]

(only reboot)

[grand shadow]

I mean if someone has more than 999 scsi disks connected then they have bigger issues

especially related to their mental sanity

[opal lotus]

if usb wasn't a thing then anyone having 1 scsi disk would be insane

[grand shadow]

sata:

[opal lotus]

point still stands

[grand shadow]

ok mr rich person

to prove your point send me a 1tb nvme drive over mail kthx

[opal lotus]

pick your poison

i will send you an intenso drive

@formal patio can confirm they're very good

[grand shadow]

https://tenor.com/view/spongebob-screaming-spunch-bob-spunch-bop-spongebob-sad-spongebob-gif-26152448

[opal lotus]

(i bought one and it arrived broken)

[grand shadow]

but yeah, @robust geyser the design seems sane aside from the asserts-which-could-have-been-errors and the memory fountain

[robust geyser]

thanks for the brief review

[sharp carbon]

there is no scsi involved with sata disks

the controller is ahci and the protocol is ata

[grand shadow]

oh bruh

I could've sworn sata used scsi in some way

[robust geyser]

they look similar

they might even be similar

maybe that's why they get the same device naming in linux? :^)

[grand shadow]

oh atapi uses scsi

[sharp carbon]

that's because linux uses the scsi subsystem to control sata drives through a scsi-to-ata translation layer

[robust geyser]

thats fucking disgusting

but it makes sense

[sharp carbon]

and yeah atapi is just scsi packets sent over ata

[grand shadow]

https://tenor.com/view/skeleton-gif-26826812

wtf

[robust geyser]

@grand shadow i got astral to read from a usb device but i'm getting stuck in detectpart lol

inside vmm_unmap

it gets stuck somewhere inside arch_mmu_invalidate_range

do you have any idea how i can debug this?

oh my fuck i think i know why

[grand shadow]

Sounds spooky, sounds like something is stuck in an irq

And is not getting the shootdown

[robust geyser]

im calling into usb code which blocks and shit

but actually, it should be fine

block_register is called from an xhci thread

[grand shadow]

Check what the other cpus are doing

And if any is stuck

Using gdb or w/e

[robust geyser]

well, cpu 4 is spinning lol

inside xhci_xfer_complete

it tries to signal a semaphore

[grand shadow]

Hm

Spinnijg where

And why

[robust geyser]

on the spinlock_acquire inside semaphore_signal

good question

i'll try to figure this out

[grand shadow]

Oh boy sounds like some tasty memory corruption

Since the semaphore code unlocks becore yielding

Obv

Or unitialized semaphore

do u use a different mechanism for completion instead of the default one in usb.c?

[robust geyser]

no, i use the usb one

buuut... allocaitng the semaphore instead of pointing to the stack fixes that

[grand shadow]

probably better to figure out why the original logic broke thanr relying on an allocation there

I remember this was a bug in my pushlock code

but it was caused by the semaphore code

[robust geyser]

interesting

[grand shadow]

https://github.com/Mathewnd/Astral/commit/81c7d77ad04b3a694ff998375fd661c464ae2617

[robust geyser]

i think this might be some sorta uaf

in my code ofc

[grand shadow]

could be

maybe it gets a xfer_complete on that stack even after the thread already returned

idk in which cases it would do it twice

[robust geyser]

hmm, that's wrong

the 3rd "got csw" print

it's gonna be a fun night

oh btw i added a little scsi subsystem so if you ever, for whatever reason, want to add support for any other scsi backend device you can do so semi-easily

[grand shadow]

based

[robust geyser]

btw, how does the page cache work?

or more like

i basically copied the iovec thing from nvme, where it does next_page, then figures out how many lbas to transfer and then does the transfer

but i am seeing full page transfers, does the page cache read/write full pages to the device?

[grand shadow]

it does, full pages

[robust geyser]

detectpart transfers showed as data_length=1024 (2 blocks) and any fs operation shows me 4096

[grand shadow]

all dma is page sized right now, which is why I am going to change that

[robust geyser]

that makes sense

[grand shadow]

the page cache is just a big hash table of <vnode, offset> inspired by svr4

but I am gonna change that to probably a radix tree

per vnode

[robust geyser]

astral becoming based

AAAARGH this shit is so annoying

[grand shadow]

more like I've outgrown my shit decisions and gotta go back and fix the tech debt ☠️

but yeah, the new page cache will have everything for clustered page-in and page-out

which should increse performance a ton when running out of the disk

[robust geyser]

can i expect that whatever i wrote wont break?

i mean the iovec disk io stuff

it's not gonna be a big refactor thankfully

if it does change

[grand shadow]

if you copied the nvme shit it probably wont break but will be just slow

but if it does its probabaly just rewriting however usb does to do scatter gather dma

[robust geyser]

no, sorry, what i meant is will your page cache rewrite change the api

[grand shadow]

probably not

havent seen any need so far

since the disk part is really just "fill this scatter gather with block data"

[robust geyser]

gotcha

im also gonna have to figure out a way to like

make it so you can do usb transfers directly to phys memory

because currently xhci does the virt->phys lol

[grand shadow]

wdym

[robust geyser]

that's so you can "dma" directly to buffers on stack

[grand shadow]

oh wait I see what you mean

hm

[robust geyser]

i think a flag somewhere in usb_xfer_t should work

like USB_XFER_PHYSICAL_BUFFER or whatever

and i'll also have to add sg support

[grand shadow]

yeah

how does usb scatter gather work (like how nvme has prps) and how does it interact with mass storage

since it might just be worth it to instead of passing a void * you just pass an iovec in the usb_xfer_t

[robust geyser]

each TRB has a CH (chain) bit, i think you can just use that to chain multiple of them to achieve SG

honestly i might just change usb_xfer_t to either a) take an iovec_iterator_t and do SG if needed or just normal transfer or b) take a virtual pointer, translate it to a physical address and transfer into that (must not span across pages)

[grand shadow]

the issue with the second approach is that you have to do one transfer per page which unless mass storage can do some crazy shit like splitting a read into multiple transfers would slow stuff down

[robust geyser]

the second approach meaning taking a virtual address?

that would be used only for stuff that transfers small amounts of data on the stack

like device descriptors or whatever

mass storage and anything else that transfers big amounts of data would use iovec exclusively

great thing about usb is that the host controller abstracts all of that away from the device, the device doesn't do dma - the controller does

i think xhci has a limit of 64K per transfer but idk if that applies to the entire transfer or just a single TRB, and you can chain them together and transfer GBs using SG

[grand shadow]

hot

sounds good

makes it easier for smaller things like hid and faster for things like mass transfer

probably just make it a union or w/e and control which is used using a flag

[robust geyser]

yup that's what i had in mind

does iovec_iterator carry the size too?

[grand shadow]

yeah

it carries the same info an iovec does + the support variables to iterate over it over multiple sources

[robust geyser]

i think it does, in that case i need a union of iovec_iter* and struct { void *buffer; size_t length; }

sounds good

i'll cook something up soon

[grand shadow]

based

though keep in mind when you do an iovec_iterator_next_page it might return something in another page but in an offset there and there might not be the full page of space

so if it has an alignment or size it won't like, just EIO

I'll do that in my nvme prp thing :P

[robust geyser]

xhci spec says this

[grand shadow]

since theres the whole nvme alignemnt requirements for dma and if userspace does an O_DIRECT with bad alignment.. EIEIO

[robust geyser]

so technically it can dma to byte aligned buffers

[grand shadow]

damn

speaking of prp shit I need to stop procrastinating that ☠️

[wild marsh]

yeah, though keep in mind you also need to set the TD size for each TRB in the chain

[robust geyser]

do you just set it to the number of TRBs left in the chain?

[wild marsh]

it's the number of packets left in the chain

in case you do more/less than one packet per TRB

i'm pretty sure this math is correct from the managarm driver ```cpp
// TODO(qookie): For xHCI 0.96 and older, this should be (progress + chunk) >> 10.
auto tdSize = tdPacketCount - (progress + chunk) / maxPacketSize;
// Last TRB always has TD Size = 0
if ((progress + chunk) == view.size())
tdSize = 0;

(tdPacketCount is the total size / packet size aligned up)

the field also is only 5 bits so if it's above it's limited to 31

[robust geyser]

hm, i thought i can just split the transfer across however many TRBs i want and just chain them together

[wild marsh]

you can

[robust geyser]

yeah but the TD size

what does "packet" even mean in this context

[wild marsh]

bMaxPacketSize

[robust geyser]

oh wtf

[wild marsh]

on the wire data is sent in units of packets

with the final packet being indicated by either being zero length or less than bMaxPacketSize

[robust geyser]

that's so annoying

[wild marsh]

i mean xhci handles all that

the only part where you need to be aware of the packet size is when setting up the endpoint context, and for computing the TD size field

[robust geyser]

idk why it couldn't just compute it on its own

it knows the endpoint max packet size

[wild marsh]

technically it doesn't know how many TRBs are left in the chain

[robust geyser]

hm

[wild marsh]

and it does not know the total TD size ahead of time

[robust geyser]

okay that's fair

[wild marsh]

i'm pretty sure the td size information is used for building the packet schedule and for bandwidth computation reasons (although the latter only really matters for isoch EPs i'm pretty sure since those have real-time requirements)

[robust geyser]

i'll implement sg tomorrow after i figure out this fucking stupid retarded issue with completions

idfk what's going on anymore, it seems like i'm hanging onto some stack variable somewhere after it leaves the scope but i don't seem to be doing that anywhere

and the moment i heap allocate one of the structures used for completion it works, great

https://gist.github.com/48cf/2e986d36619186902c11b258af222f28

[robust geyser]

@grand shadow if you have some time later could you try and take a look at this completion bullshit? i must be overlooking something really simple lol, important functions are probably xhci_ring_submit{,_and_wait} and xhci_process_events

[grand shadow]

sure

[robust geyser]

thanks a lot

[grand shadow]

I fnished the nvme prp stuff

Im gonna see if I can find the issue iretq is talking about and if not I will look into the virtio block side of things

[grand shadow]

sorry I didnt do that, I will try to do so in the morning

[robust geyser]

it turns out it was a god damn use after free

i attached the same submission to two trbs

so the first completion wakes up the thread and that destroys the stack frame

and the second one would just write and read garbage on the stack lol

[robust geyser]

GEE I WONDER WHY SHIT IS BREAKING

I PUT THE COMPLETION CONTEXT ON THE STACK

AND THEN RETURN IMMEDIATELY

SURELY NOTHING WILL BREAK

...that's the second stack corruption i was battling with

https://gist.github.com/48cf/7d292d1db774923fc17597760420ae22

kidna messy but it does the job

i hope nothing will break if i exploit pointer alignment, both xhci_xfer_submit_t and usb_xfer_t are at least pointer aligned so i should be able to use bit 0 of the ctx/xfer pointer to store information

that way i can only access stack if it's intended

and with that no more heap allocation are needed, all the transfer structures live on the stack 🔥

time to implement scatter-gather transfers for usb msd

[robust geyser]

it works

[robust geyser]

well, it would simply be too easy if it just worked

msd breaks when you spam write requests, for some reason the bulk in/bulk out requests get interleaved??? idk

and when trying to boot off usb it dies in pmm internalhold on an assert that page is not free (somehow a stack page is marked as free???)

usb_xhci_ep_kick slotid 3, epid 4, streamid 0
usb_xhci_fetch_trb addr 0x000000007de8b9c0, TR_NORMAL, p 0x000000007ce9c000, s 0x00001000, c 0x00000424
usb_xhci_xfer_start 0x7f94a00053b0: slotid 3, epid 4, streamid 0
usb_xhci_xfer_error 0x7f94a00053b0: ret -3
usb_xhci_queue_event v 0, idx 125, ER_TRANSFER, CC_STALL_ERROR, p 0x000000007de8b9c0, s 0x06001000, c 0x03048001
usb_xhci_ep_state slotid 3, epid 4, running -> halted
usb_xhci_runtime_read off 0x0038, ret 0x7e5b97d8
usb_xhci_runtime_read off 0x003c, ret 0x00000000
usb_xhci_doorbell_write off 0x000c, val 0x00000003
usb_xhci_ep_kick slotid 3, epid 3, streamid 0
usb_xhci_fetch_trb addr 0x000000007de8e170, TR_NORMAL, p 0x0000000078d64000, s 0x00001000, c 0x00000424
usb_xhci_xfer_start 0x7f94a00053b0: slotid 3, epid 3, streamid 0
usb_xhci_xfer_error 0x7f94a00053b0: ret -3
usb_xhci_queue_event v 0, idx 126, ER_TRANSFER, CC_STALL_ERROR, p 0x000000007de8e170, s 0x06001000, c 0x03038001
usb_xhci_ep_state slotid 3, epid 3, running -> halted```

for some reason both endpoints become stalled lol, interesting

[marsh sparrow]

stall is just the generic "return -1" of USB

it just indicates that something is wrong with the actual request (= the request did reach the device but it couldn't process it)

[robust geyser]

yeah i know but i don't know what's wrong lol

everything else works

[marsh sparrow]

for example for mass storage it can mean that the device doesn't support the SCSI command that you're trying to execute

[robust geyser]

i think i might be messing up the mass storage state machine

it has a pretty strict model of how data is fetched/pushed to endpoints

but again, the entire thing is this: https://gist.github.com/48cf/3cc5d07bdae9da0552d3d680b6b82dbb

if you submit an xfer without a completion it will wait for it to be completed, so i don't see how i can be messing this up

[marsh sparrow]

you must ensure that the device has seen the command before you try to receive the status

if you do the in transfer before the out transfer is done, that'll be problematic

[robust geyser]

can the hci process trbs out of order?

ah, but they're different command rings

but again, i wait for completions

[marsh sparrow]

for different endpoints: yes

[robust geyser]

i thought that a transfer completion would be enough to move on

[marsh sparrow]

and in and out are always different endpoints of course

[robust geyser]

if the hci completed the transfer that means the device has seen the data

ugh this is so annoying

[marsh sparrow]

yes, waiting for the trb to complete is enough

[robust geyser]

well then i do that!

i should be good, but yet it doesn't work

i'll dig into it more at some other point, i think hid is more interesting to work on than mass storage, and i don't think there's anything wrong with the usb stack that causes it

[marsh sparrow]

mass storage should be easier though

[robust geyser]

yeah it should, but something somewhere refuses to function properly

[marsh sparrow]

it only breaks if you send many requests?

do you have locks around this function?

[robust geyser]

no, that's a good point

lol

you think a simple mutex around all the bulk endpoint transfers is enough?

basically acquire before the sending cbw, release after reading csw

[marsh sparrow]

yeah

[robust geyser]

that's crazy, it actually works now 💀

[marsh sparrow]

nice lol

[robust geyser]

thanks for figuring this out

kinda slow, but it works!

[obsidian pivot]

"kinda slow," he says as he continues to demolish my (kernel's) highest io performance stat

[robust geyser]

amazing

[robust geyser]

considering it should be zero-ish copy, yes it's pretty slow

pretty sure the entire io stack operates on iovec_iterators, which are passed directly to drivers for SG DMA

[analog berry]

Damn good job

[robust geyser]

:(

[grand shadow]

The thing is it doesnt do any >PAGE_SIZE dma yet, thats coming with the new page cache

[grand shadow]

BruH I thought I had fixed that

[robust geyser]

lmao is that a known issue

maybe im just running an out of date branch

[grand shadow]

I never got any more of those error after rewriting the scheduler and debigging a bit

[robust geyser]

ah, i guess i'm not running a branch that old

[grand shadow]

Can u take a look in gdb to see the flags

But good progress tho

[robust geyser]

(gdb) p thread->flags
$1 = 3

queued and running

[grand shadow]

☠️

Uhhhhhhhhh

[robust geyser]

lmao i wish i could help

[grand shadow]

https://tenor.com/view/agora-deu-o-krai-memo-viu-gif-7890243084758874215

[robust geyser]

i wonder if i messed up something in usb/xhci

[grand shadow]

Agora deu o carai mesmo

Probably not

I think I ran into something like that a few months ago but I was genuinely never able to reproduce it and the only thing I was able to do was add an assert

Can u get a backtrace as well

[robust geyser]

#0  _panic (msg=msg@entry=0x0, ctx=ctx@entry=0x0) at lib/panic.c:20
#1  0xffffffff8006f51f in switch_thread (thread=thread@entry=0xffff80008079cb00) at sys/scheduler/scheduler.c:42
#2  0xffffffff8006ff9f in yield (context=0xffff8000807f7f28) at sys/scheduler/scheduler.c:171
#3  0xffffffff8007550d in arch_context_saveandcall.nostackchange2 ()
#4  0x00000000000003e8 in ?? ()
#5  0x0000000000000000 in ?? ()```

not very interesting

i already killed the vm that's what i have in the terminal

but hey rebooting and installing nyancat into /mnt again worked lol

[grand shadow]

Yeah that seems to be a very rare race comdition

[robust geyser]

when you have some free time can we look at trying to boot from usb? i added a root_wait flag but something goes wrong when it tries mounting scsi0 on root

this happens, to be precise usb: device matched with driver 'usb-msd' (score: 60, config: 0) scsi0: 16777216 blocks with 512 bytes per block mm/pmm.c:internalhold:120: (page->flags & PAGE_FLAGS_FREE) == 0 failed cpu0: Oops.

with a backtrace from vfs_mount all the wya to xhci_data_xfer, which tries to vmm_getphysical on a stack page and dies 💀

[grand shadow]

Wtf can u give me the exact backtrace as well as a print of page

That sounds like either stack overflow or something deleted the stack

[robust geyser]

well, it's in kernel_entry so i don't think there's a proper stack yet

backtrace is #0 _panic (msg=msg@entry=0x0, ctx=ctx@entry=0x0) at lib/panic.c:20 #1 0xffffffff8005b05b in internalhold (page=<optimized out>) at mm/pmm.c:120 #2 0xffffffff8005b1a5 in internalhold (page=<optimized out>) at mm/pmm.c:121 #3 pmm_hold (addr=addr@entry=0x7fd16000) at mm/pmm.c:137 #4 0xffffffff8005e600 in vmm_getphysical (addr=0xffff80007fd16000, hold=hold@entry=true) at mm/vmm.c:709 #5 0xffffffff8003c352 in xhci_data_xfer (xhci=0xffff8000000a2640, dev=0xffff8000000b8060, xfer=0xffff80007fd169c8, sub=sub@entry=0xffff80007fd16938) at io/usb/xhci.c:1017 #6 0xffffffff8003cadd in xhci_ctrl_xfer (ctrl=<optimized out>, dev=<optimized out>, xfer=<optimized out>) at io/usb/xhci.c:1112 #7 xhci_ctrl_xfer (ctrl=<optimized out>, dev=<optimized out>, xfer=<optimized out>) at io/usb/xhci.c:1092 #8 0xffffffff8003981e in usb_msd_scsi_submit (host=0xffff80007e593ee0, cmd=0xffff80007fd16a40) at io/usb/msd.c:100 #9 0xffffffff80041740 in scsi_read (private=0xffff80007e593ee0, buffer=0xffff80007fd16b40, lba=<optimized out>, count=<optimized out>) at io/block/scsi.c:112 #10 0xffffffff8003f244 in rwblock (minor=<optimized out>, iovec_iterator=0xffff80007fd16b40, size=4096, offset=0, write=<optimized out>, done=0xffff80007fd16b28, flags=<optimized out>) at io/block/block.c:137 #11 0xffffffff80054fea in devfs_getpage (node=0xffff80007e591660, offset=0, page=<optimized out>) at fs/devfs.c:402 #12 0xffffffff8005c083 in vmmcache_getpage (vnode=vnode@entry=0xffff80007e591660, offset=offset@entry=0, res=res@entry=0xffff80007fd16d30) at mm/vmmcache.c:169 #13 0xffffffff8005319c in vfs_read_iovec (node=node@entry=0xffff80007e591660, iovec_iterator=iovec_iterator@entry=0xffff80007fd16e10, size=size@entry=220, offset=offset@entry=1024, bytesread=bytesread@entry=0xffff80007fd16e90, flags=flags@entry=0) at fs/vfs.c:553 #14 0xffffffff80053436 in vfs_read (node=node@entry=0xffff80007e591660, buffer=buffer@entry=0xffff8000000a2248, size=size@entry=220, offset=offset@entry=1024, bytes_read=bytes_read@entry=0xffff80007fd16e90, flags=flags@entry=0) at fs/vfs.c:633 #15 0xffffffff8004964e in ext2_mount (vfs=0xffff80007fd16f78, mountpoint=<optimized out>, backing=0xffff80007e591660, data=<optimized out>) at fs/ext2.c:2039 #16 0xffffffff80053c7e in vfs_mount (backing=0xffff80007e591660, pathref=<optimized out>, path=path@entry=0xffffffff8007aeed "/", name=name@entry=0xffffffff8014b340 <argument_buffer> "ext2", data=data@entry=0x0) at fs/vfs.c:130 #17 0xffffffff80009f71 in kernel_entry () at main.c:52

(gdb) p pages[(uintptr_t)addr/4096]
$6 = {backing = 0x0, offset = 0, hashnext = 0x0, hashprev = 0x0, vnodenext = 0x0, vnodeprev = 0x0, {{freenext = 0x0, freeprev = 0x0}, {
      writenext = 0x0, writeprev = 0x0}}, refcount = 1, flags = 1}```

[grand shadow]

Ohhh shi I dont think I set up page_ts for the limine reclaimable memory

Or I dont set them as used

[robust geyser]

ill try to move that part of initialization into a dedicated thread

[grand shadow]

Yeah the issue is I dont set them as used I think Id have to check the

Nah

U dont need to

Set the limine reclaimable pages as used on the pmm init

I can cook up a patch in 15 mins

Cuz Im not at my pc yet

[robust geyser]

yeah i figured considering you're on your phone

but one problem i see with that is that uhh

what refcount do you give them?

[grand shadow]

1 probably

The running thread holds that reference

Or only limine does for other cases

[robust geyser]

oh lol it booted into xorg

for (int i = 0; i < e->length / PAGE_SIZE; ++i) {
    page_t *page = &pages[(e->base / PAGE_SIZE) + i];
    page->refcount = 1;
}```

boot from usb🔥

now time to see if this will work on real hw, let me hook up a display to my spare pc

[grand shadow]

Did u also remove the free flag

[grand shadow]

Hell yeah

[robust geyser]

no lol, good point

[robust bobcat]

🔥

well done

[robust geyser]

looks like i wont be booting astral on the optiplex :(

[grand shadow]

sadge

does it support msi? I think my pci stack also supports msi

if not then I have uacpi

[robust geyser]

well see then thing is

oh yeah

sorry i throught the message meant controller does not support msi lol

im restarted

now im pretty sure the controller does support regular msi

[grand shadow]

https://tenor.com/view/spongebob-crying-geometry-dash-sad-spunch-agony-god-i-love-trampolining-gif-25250082

[robust geyser]

ill boot into linux and see if it has msi

[sharp carbon]

pretty sure every device is required to support regular msi by the pcie spec

[robust geyser]

uhh what the helly

[gleaming bay]

Uhhhhh

LGTM!

[robust geyser]

well turns out i nuked linux and installe windows on this thing

and now the display driver is broken, great

but i guess monkuous is right

i didnt know that was a thing :^)

[marsh sparrow]

Somehow linux display drivers peaked in 2020 or so and now it's all downhill

Or is this the windows driver?

[robust geyser]

yes, windows

you can even see the spinner, kinda

[analog berry]

i mean xhci might be a legacy pci endpoint

[robust geyser]

well, i added msi stuff (hopefully working? idk) and added "USB Legacy Support Capability" support which basically disables firmware usb emulation stuff afaik, the controller is now set up but it doesn't seem to do anything :|

maybe i should try booting on my main pc 👀

damn, not even a flanterm ☠️ ☠️

just straight up a black screen

[obsidian pivot]

I should lwk try to run astral on my old laptop

[obsidian pivot]

PS2 is even almost sane on this laptop

too bad im at school

[grand shadow]

Wtf

Maybe I need to add a sort of "super early logging" define that just sets up flanterm first thing

[robust geyser]

considering you already have a thing that hacks in a new address for the framebuffer, that would be nice

only reason one wouldn't set up flanterm early is because they don't want to reinit the context and lose all the logs

anyway - i think i'm gonna try working on a proper hid driver

that way i can make usb tablet work and not go insane about mouse capturing lol

[sharp carbon]

or because mm isn't available yet

[robust geyser]

you can use flanterm without memory management

[sharp carbon]

then it uses an internal bump allocator which just feels horrible

especially because its memory usage is O(number of pixels)

[robust geyser]

32M should be enough

[sharp carbon]

yes but the fact that that static 32M buffer exists at all feels horrible

[robust geyser]

i agree!

[grand shadow]

Yeah this is why I dont set it up first thing

I wait until I at least have some mm

Its still not the best but better than 32m

Tbf an approach for that could be carving out of the memory map

But that needs carefulness to not explode everything

Also for usb boots: I might just take the linux approach of a squashfs + overlayfs

[robust geyser]

yeah that would be cool

i guess you'll need chroot for that

does astral have chroot?

ok yeah you do, dumb question

[grand shadow]

Yeah

Has any other hobby os implemented squashfs and overlayfs?

[robust geyser]

i dont think any hobby os even implemented an overlayfs

[grand shadow]

Hmmmmmm

[robust geyser]

i pushed the xhci rework to my branch

together with the msd driver

now onto hid descriptor parser, time to figure out how the hell does that even work

[grand shadow]

squashfs is just adding a new driver and mounting it like any other driver, the cooler design would be handling overlayfs since that might need some changes to the vfs depending on how I implement ts

I need to finsih the page cache why do I do this to myself why do I find cooler stuff to do

now I wanna do squashfs + overlayfs

☠️

[proper meteor]

what even are those?

[robust geyser]

squashfs is a fancy initrd and overlayfs is a union filesystem

[grand shadow]

yeah squashfs is a compressed readonly filesystem and overlayfs you can mount it and it'll show you an underlying filesystem and have temporary changes for anything u do

like a tmpfs on top of another fs

[robust geyser]

you can mkdir /newroot mkdir /squashfs mkdir /overlay mkdir /workdir mount -t overlay overlay -o lowerdir=/squashfs,upperdir=/overlay,workdir=/workdir /overlay

well, of course oyu have to mount something at /squashfs

otherwise you'll end up having a union of two empty directories

that lets you overlay multiple filesystems on top of each other

you can also omit upperdir and workdir and specify multiple lowerdirs :D that way you can create a union of multiple read-only filesystems

overlayfs is really cool

[grand shadow]

do I look into preparing vio block for the page cache or do I look into squashfs

[proper meteor]

do the page cache

[marsh sparrow]

imo squashfs doesn't seen that useful

[robust geyser]

yes do the page cache

i wanna see if the usb mass storage becomes less shit when you do bigger transfers

[robust geyser]

Collection: type=1, usage=0x0006, fields=5, subcollections=0
  Input: usage_page=0x07, usage_range=0x00e0-0x00e7, size=1, count=8, logical=0-1, offset=0
  Input: usage_page=0x07, usage_range=0x0000-0x0000, size=8, count=1, logical=0-1, offset=8
  Output: usage_page=0x08, usage_range=0x0001-0x0005, size=1, count=5, logical=0-1, offset=16
  Output: usage_page=0x08, usage_range=0x0000-0x0000, size=3, count=1, logical=0-1, offset=21
  Input: usage_page=0x07, usage_range=0x0000-0x00ff, size=8, count=6, logical=0--1, offset=24
Collection: type=1, usage=0x0002, fields=0, subcollections=1
  Collection: type=0, usage=0x0001, fields=4, subcollections=0
    Input: usage_page=0x09, usage_range=0x0001-0x0005, size=1, count=5, logical=0-1, offset=0
    Input: usage_page=0x09, usage_range=0x0000-0x0000, size=3, count=1, logical=0-1, offset=5
    Input: usage_page=0x01, usages=[0x0030, 0x0031], size=16, count=2, logical=0-32767, physical=0-32767, offset=8
    Input: usage_page=0x01, usages=[0x0038], size=8, count=1, logical=-127-127, offset=40

keyboard and tablet descriptors

parsing ts was surprisingly easy

each byte tells you how much data is after it, and it also tells you the type and tag - type can be main, global or local, main items are collections and fields, and global/local items basically modify the parser state, like usage page, logical min/max, when you encounter a main item you basically take the parsed global/local state and create an item, if you encounter a field (input/output/feature) item then you add it to the collection and advance the bit offset by report_size*report_count (you get that by parsing a specific global item)

the entire parser is 120 lines of code, just 3 switches

[grand shadow]

damn interesting

[grand shadow]

I am implementing the very simple generic resource allocator
basically just a struct with a dequeue, a mutex, how much of a resource there is and the max you can allocate in a single go
every waiter in the queue has a small structure on the stack which is put in the queue, there it says how much it wants, the thread to wake up and the next in line

[robust geyser]

damn where page cache💀

[grand shadow]

bro that is for the page cache

its gonna be used for allocating the descriptors in virtio-block

[robust geyser]

oh hm

[grand shadow]

fors scatter gather

[robust geyser]

i see

interesting

[tribal dust]

yes true

[grand shadow]

I will need to add either another bool to the vmm get physical address function or make it take flags

[robust geyser]

flags would be cleaner

imo

[grand shadow]

yeah thats what I am thinking

I will need to add a way to atomically get the physical address of a page while ensuring that its in its final resident state (as in, cow'd in for a private mapping for example)

so I will likely make that a flag

alongside the hold reference thing

[robust geyser]

sounds fun

[grand shadow]

yeah we don't want to dma into shit we shouldn't 💀

I'm likely gonna have the iovec iterator next page function call it with that flag unconditionally like it already does with hold

[robust geyser]

@opal lotus regarding evdev, remember how you said it's stupid that it returns events with unix timestamp instead of boot time? it's an ioctl: EVIOCSCLOCKID, you can ask the kernel to use a certain type of clock for the timestamps lol

[opal lotus]

bruh

[robust geyser]

the evtest program likely just asks for realtime timestamps

[opal lotus]

what if you just don't?

does it shit itself

[robust geyser]

idk, probably not, but it's trivial to implement so why not

[opal lotus]

well you need rtc for that

I don't have that yet

[robust geyser]

it's just monotonic + boot time offset

or whatever

or at least that what i think it is lol

man ts hid shit is frying me🥀

maybe i should implement evdev first, then worry about hid?

[opal lotus]

yes

[grand shadow]

I also will have to add a flag for pages that theres dma in progress or w/e to not break fork semantics

[robust geyser]

lol cool

cc @opal lotus

[opal lotus]

💀

[robust geyser]

Wat

[opal lotus]

cpu oops

[robust geyser]

im starting work on evdev on astral bro

yeah

i stubbed poll

[opal lotus]

damn

[robust geyser]

idk what im doing yet 😭

but i handled some ioctls

was pretty easy

input0 is gonna be the multiplexed input device

and input1 and onwards is gonna be real devices

[grand shadow]

yooo

[analog berry]

holy

[robust geyser]

astral way ahead of its time

[robust geyser]

baller

ps2 keyboard over evdev works

[opal lotus]

lmaoooo

wtf is uintmax_t

just put the size_t in the bag

[robust geyser]

i just tried it with xorg, it died on some fuckass ioctl and it turns out i need so many of those just to get it to read the events

if i understand correctly it wants to know which keys are supported or whatever

and which event types a device emits

[neon crane]

thats not the same

[opal lotus]

exactly

you don't need uintmax_t for this

[grand shadow]

dont question code I wrote 3 years ago

[obsidian pivot]

dont question code i wrote 0 days ago

[grand shadow]

hm I still think one of the biggest slowdowns on smp code are the tlb shootdowns

[obsidian pivot]

have u ever read your code and wondered What The Actual Fuck was he thinking

[grand shadow]

and I think if I do something like clustered page ins I can reduce that a ton (as in, page in many pages into the page tables in one go)

[opal lotus]

when do you trigger them

[grand shadow]

unmaps or in cases like cow changing physical address of a mapped page

one per unmap or one per cow page

[opal lotus]

lol i have unmap stubbed

[grand shadow]

kekw

[opal lotus]

works well enough for most things

[grand shadow]

but yeah, considering I do one CoW per anonymous page pretty much (I do the zero page thing for simplicity), that could be reducing smp performance a ton

[opal lotus]

do you need to do a shootdown ipi if the process only lives on the current cpu?

[grand shadow]

you don't

I don't do that

and its fine for most stuff

but when you use something like llvmpipe or java that does heavy multithreading

line go down

[obsidian pivot]

I haven't done this but try prefaulting small areas

[opal lotus]

well if you're faulting and already know the range slice you can probably just page in the entire region

no?

(if it's small enough)

[robust geyser]

what do u consider small?

[opal lotus]

idk <tlb size?

[grand shadow]

I wonder if other operating systems like linux or windows or bsds or w/e actually do this zero page cow thing

[marsh sparrow]

Hm?

[grand shadow]

as in, first fault in a zero'd page and then copy on write it

[marsh sparrow]

yes

[grand shadow]

hm

how do they cope with the tlb shootdown from remapping it?

I mean I guess they could not do the CoW when like the page fault is already for a write

I don't do that

[prime mulch]

This is only a Linux thing I believe

Windows and macOS don't do this because it requires an extra page fault in a number of cases and they don't consider it worth it

well I know Windows doesn't, I believe macOS doesn't either but I'd need to look closer

[grand shadow]

interesting

[marsh sparrow]

it's a trade off i guess

[obsidian pivot]

negative infinity

is pretty small

[analog berry]

How are u so fast

[robust geyser]

its just copying the keyboard code and substituting keyboard packets for evdev inpuit events lol

[analog berry]

Still impressive

[robust geyser]

arguable, but thanks

[analog berry]

im kinda excited to get into these things myself

but it will be a while

[grand shadow]

steam loads on links

crazy

[obsidian pivot]

when audio support??

[analog berry]

When can I install steam on astral

[carmine swallow]

if I ever figure out the weird issues on hzlibc on astral I think you could theoretically run steam on it (though ofc it'd need all the kernel support for 32-bit apps too)

though I haven't actually tested steam on it but it can't be that bad right, I know that factorio + nvidia proprietary driver + llvm + amdgpu work on it on linux

[analog berry]

I think steam is planning to get rid of 32 bit

I read somewhere

[carmine swallow]

that'd be nice, though I guess it might still take a while

[analog berry]

But the glibc compat is an insane feature

[marsh sparrow]

the drivers don't really help, do they?

since astral doesn't have the kernel interfaces

[analog berry]

Well its going to have evdev soon

Then DRM

[carmine swallow]

they were just examples that I tested on it on linux not necessarily related to steam

I guess driver-wise it'd work on llvmpipe

[analog berry]

Yeah if the game just uses opengl.so it will work fine

[marsh sparrow]

how does hzlibc work?

does it translate glibc calls to other libc calls?

[carmine swallow]

it's its own independent libc, though maybe translating the calls could actually work

[grand shadow]

Huh what issues are you having

[marsh sparrow]

but what does it do e.g., if a glibc linked program calls syscall()?

[carmine swallow]

maybe if the executable would be manually loaded by a special loader application then only the symbols inside that could be resolved to a wrapper lib like the mlibc glibc compat thing I made, that'd get rid of the ugly global overriding of pthread functions

[robust geyser]

steam already ships 64 bit binaries im pretty sure

[analog berry]

then we should be able to run it on astral

[marsh sparrow]

I thought about whether we could somehow have per-DSO glibc compat in the past

[carmine swallow]

it doesn't do anything as it doesn't provide syscall() on other platforms than linux but it could be provided by the specific sysdep that then does a switch on the number or something

[robust geyser]

idk if it's a thing on linux but i'm pretty sure the windows binaries are 64-bit since a couple weeks

[marsh sparrow]

that might be useful to run closed source apps like steam on Managarm (w/o wine)

[opal lotus]

running steam implies being able to run chromium

[marsh sparrow]

well, for chromium a native port is more interesting

[marsh sparrow]

One way to achieve this would be attaching syscall handlers to memory regions

then you could look up the origin IP of the syscall

and dispatch to a linux emulation

But that will probably need some tricks to be efficient enough

not sure if there are other / more elegant solutions

[carmine swallow]

how would this help with the libc compatibility though?

or like how would it be handled

[grand shadow]

This gave me an idea Ill cook when Im back home

[marsh sparrow]

Not sure. My idea was mainly for handling syscalls

[carmine swallow]

the weird vnode being null and running xorg corrupting everything so it doesn't find the shared libraries anymore when trying to run stuff

[marsh sparrow]

ig the trick would be to dispatch native syscalls through a vdso such that you only need to check for a single address on the fast path

and on the slow path (when you need to emulate anyway), it doesn't matter that much if you need to look up the memory area

[grand shadow]

Wtf

Do you have a syscall trace?

[carmine swallow]

how do I enable global syscall tracing?

because ideally I think I'd have a full trace given that if I have to run a program to trace stuff then that program might fail to run (for the second issue, I guess statically linking it would be an option but I don't support static linking yet lol)

[grand shadow]

Its in the kernel-src makefile, idk if @robust geyser made an option to enable it unconditionally

But patching out his checks shouldnt be too hard its in kernel-src/x86-64/syscalllog.c

[robust geyser]

oh yeah no i didn't think about that, sorry 💀

probably wise to add a cmdline option to enable tracing for the whole kernel

[grand shadow]

Yeah

I can add that in a sec

[carmine swallow]

syscall: pid 63 tid 64: openat: dirfd -100 path /usr/lib flags 65536 mode 0 (2855 cached pages, 506798 free pages)
syscall return: pid 63 tid 64: 3 OK (2855 cached pages, 506798 free pages)
syscall: pid 63 tid 64: openat: dirfd 3 path libgcrypt.so.20 flags 0 mode 0 (2855 cached pages, 506798 free pages)
syscall return: pid 63 tid 64: 5 OK (2855 cached pages, 506798 free pages)
syscall: pid 63 tid 64: close: fd 3 (2855 cached pages, 506798 free pages)
syscall return: pid 63 tid 64: 0 OK (2855 cached pages, 506798 free pages)
syscall: pid 63 tid 64: read: fd 5 buffer 00007FFFFFFFDB30 size 64 (2855 cached pages, 506798 free pages)
syscall return: pid 63 tid 64: 18446744073709551615 EBADF (2855 cached pages, 506798 free pages)

wait I wonder if this is the vnode being null too because I added EBADF for that, Ill have to test it by changing it to smth else ig

actually nvm it can't be, I only added that to fsync

[grand shadow]

wtf

[carmine swallow]

somehow file->flags is zero

[grand shadow]

thats spooky

wonder if its some openat race? but nothing broke openat in mlibc

[carmine swallow]

yeah idk, the flags inside newfile are fine inside the openat syscall but then somehow get changed so that inside the read syscall they are zero

[gritty shore]

Is steam electron?

[opal lotus]

no but it has a browser embedded

[robust geyser]

the steam client is literally one big webview

its chromium with some light ui around it

it's like a very shitty web browser

that can coincidentally launch video games

[carmine swallow]

also looks like when the close of the dir fd is removed it doesn't happen anymore??

I mean xorg still doesn't find any screens but that's probably unrelated

[grand shadow]

wtf

[gritty shore]

At least it doesn't use that much ram