#Astral

1 messages · Page 13 of 1

analog berry
#

it probably isnt a few seconds long tho

grand shadow
#

yeah

#

in qemu it was like a small pop at the start iirc

#

will finish eating dinner and report if same happens on my desktop

analog berry
#

would be nice to debug that poweroff as well

grand shadow
#

I mean thats on oberrow's computer

#

so I need oberrow to exist

analog berry
#

lol

#

i dont think he actually exists

grand shadow
#

@carmine swallow I actually thing it might be playing some unitialized memory at the start

#

Same thing on my desktop, HOWEVER

#

It played a bit of the song before actually playing the start (I had to reboot the pc cuz I forgot to connect)

#

And it didnt finish the song too

grand shadow
#

Cating it again just says starting stream and gets stuck there

grand shadow
#

No idea I havent looked much into the hda driver, but this behaviour makes me think it is

#

I played a bit of it, realized I had the headphone plugged into the wrong port, rebooted, played it again, it played a wonky version of the middle of the song for a few seconds, then played the actual song start

#

so this is just my guess

#

holy shit I think my hda card is stuck

#

windows does not initialise it

#

or whatever

#

there is no option for it

#

loooooool

#

wtf did you do qwinci

#

lmaoooo

#

lemme see if cutting power helps it

#

Ok cutting power and turning it on again fixed it

#

actually fucking crazy tho

grand shadow
#

qemu seems to be trying to write to read only memory here

grand shadow
#

it seems like it tries to write to the first page of libx11 which uh what

grand shadow
#

gnu hello doesnt build anymore

#

astral has fallen billions must use windows

grand shadow
#

I dont get it? it detects libiconv, adds it to $LIBS in the configure script but it just doesnt pass to the makefile???

grand shadow
#

so LIBICONV is passed to the makefile but it just doesn't add it to the link

#

what the fuck?

#

INTL is passed to the ld

#

maybe its some dependency memes

#

it does depend on libiconv

#

which makes me wonder why is libiconv not adding???

#

manually passing liconv works

#

ugh I think this is happening because of it direclty just linking the fucking .so

#

instead of being normal and passing -l

#

so the linker refuses to add the dependencies to intl because it thinks its an object so you have to pass it directly

#

nvm still happens

#

it only happens in hello too?

#

doing just -lintl outside of it works

#

just removing the libiconv dependency from intl

#

idc anymore

#

if it built it built

#

now it complains about undefined symbols to iconv in striconv.c in hello

#

aaaaaaaaaaaaaaaaaaaaaaaaaaaaa

#

stupid fucking autotools wont add the -liconv

fleet osprey
#

this must be the least frustrating time I've seen anyone have using autotools meme

grand shadow
#

@gritty shore looking into the server it seems you ran into this shit while building gnu hello, how did you fix it (if you even remember cuz its been a while)

#

gonna build some other package and see if its not a gnu hello autotools bug

carmine swallow
#

as for the weird issue at the start I think I might know why, I only queue one page of data before starting the stream and the next interrupt is after that one page has been played so it writes to the same page that the controller is currently playing

analog berry
grand shadow
#

Due to my rmdir() being broken

#

I still do think its a bug on gnu hello's makefile stuff when running with libintl and libiconv

#

Since configure detects libiconv just fine and even passes it to the makefile but doesnt have it be in the actual rule

#

I will find out when I build another program with the autoconf GETTEXT stuff

grand shadow
carmine swallow
#

no but I didn't really look into it that much yet (or to neither one of the ones that I own really)

grand shadow
#

Ahh

#

I see

carmine swallow
#

and the queueing stuff is somehow broken in qemu now too lol

#

as in that it plays a little bit of the song and then starts over playing it properly

grand shadow
#

Hmm same thing that happened on my desktop

carmine swallow
#

yeah I am not sure what is it caused by, it wasn't the buffer underflow that happened at the start because I fixed that

grand shadow
#

implementing checking if directories are empty on tmpfs and ext2 on an unlink (I had forgor)

grand shadow
#

back to trying to build some random gnu package to see if gettext works

#

´when do you think they'll turn it off lol

fleet osprey
#

probably never

#

it takes basically nothing to run an FTP server

#

maybe like, 1MB of RAM

grand shadow
#

it is year 2035, the ftp server of the gnu project has had the "we will probably shut this down in the future" notice for 14 years

#

when mkdirat mode

#

wtf?

#

something isnt right

#

I think someone forgot to remove the print lol

fleet osprey
#

yeah, seems like it

grand shadow
#

@prime juniper literally unusuable pls fix

#

one day I will go through the output of configure and fix everything I can there

#

theres shit like dup2 works... no

#

lets see, grep configured

#

building it rn

#

same one that gnu hello has

#

and it built

#

thus, I will say that the gnu hello thing is their bug and not mine and I will not care

#

anyways the built grep works nice, which is neat

#

and e2fsck returns no issues

#

time to fix some other issues

fleet osprey
#

🔥
tons of fixes today

grand shadow
#

think my timers have some issue wrt removing entries

#

the following code breaks:
alarm 1 second
nanosleep for 1 nsec
alarm 1 second
nanosleep for eternity

#

the second alarm never goes off an my timer_remove returns some crazy value

#

so I am looking into that

fleet osprey
#

well, at least if you can replicate it, you have a starting point
better than most of my bugs meme

wild marsh
prime juniper
#

Whoops

grand shadow
#

One day mkdirat will not ignore its mode and when that happens it will be the year of the managarm desktop

craggy tide
#

lol

prime juniper
grand shadow
#

@analog berry if its not too much trouble, can you give me a rundown of how acpi devices work, some examples of cool devices, how to talk to them, how to enumerate them on uacpi, etc? I want to redo how I do drivers soon and having acpi there from the start would be nice but I know like nothing about acpi

analog berry
#

u can look at osdev wiki examples on how u can enumerate devices

#

TLDR devices have _HID/_CID that identify what they are, _CRS for getting the list of resources they provide or consume (e.g. port numbers, irqs, memory ranges, etc), other device specific methods, power states, etc

#

the wiki example is pretty good overview

grand shadow
#

Ill look into it, thanks

analog berry
#

cool, lemme know if u have any questions

grand shadow
#

Will do

grand shadow
grand shadow
#

@analog berry does acpi need pci to initialise everything or can I use it to find the pci bus

carmine swallow
analog berry
#

namespace load only requires access to pci bus 0

#

the rest can be iniitalized later

#

namespace initialize requires access to the entirety of pci

grand shadow
#

I assume theres anoter table that isnt mcfg that says pci is real then?

analog berry
#

the order:

  • uacpi_initialize
  • read MCFG
  • uacpi_namespace_load
  • find pci busses
  • uacpi_namespace_initialize
grand shadow
#

Or how does it work in legacy pci

analog berry
#

i mean if uacpi is accessing it then yes it does exist automatically

#

firmware wouldnt be trying to talk to it if it didnt exist

#

if no mcfg assume legacy pci if its ever accessed

grand shadow
#

Alright ty

analog berry
#

npnp

grand shadow
#

the nanosleep for eternity would then proceed to insert an entry into the past

#

inventing time travel one bug at a time

grand shadow
#

my ppoll had broken signal handling, oops

#

fixed that now and make -j2 is faster again

grand shadow
#

I also need to revisit how I keep track of time

#

but that will come after I redo my driver stuff

#

qemu is slow as shit because as it turns out reading out of the hpet every time you want to know what time it is isnt that good lol

#

like actually crazy

#

so it might not even have been my slow as shit I/O but just fucking HPET

#

I love footguns that only appear like a year and a half later

robust geyser
#

just keep time in a global variable that you update on every timer interrupt

#

and map the page containing that variable read-only in every userspace process :^)

#

i love virtual memory for being able to do stuff like that

grand shadow
#

yeah I was probably thinking of something like that

#

my timer is one shot but I could figure something out

robust geyser
#

good enough, no?

#

just read hpet into that variable

#

hm actually you end up with the same problem but in a different place lol

#

yeah you might need some proper time keeping here

grand shadow
#

I should find out the average time it takes to access the hpet

#

apparently its like 1 us?

wild marsh
#

check for invariant tsc and just use the tsc as the global time variable :^)

grand shadow
#

so what I want from the new driver stuff I will make will be:
-have buses discover hardware and other buses under themselves (architecture specific root bus -> acpi bus -> pci bus -> virtio bus -> virtio block device, for example) and call to initialize them (by looking into a section marked for that specific bus to look for drivers in)
-have handling for buses to do hotplug for connection and removal on devices and buses under themselves via a callback or something
-have handling for deinitialization calls on system power off

#

anything else that would be interesting to have?

robust geyser
#

kernel modules you can load and unload at runtime

#

:^)

obsidian pivot
robust geyser
#

its not that hard if you are writing your kernel from scratch and not trying to retrofit*

obsidian pivot
#

Just a bit of elf funniness

fleet osprey
#

I'll add to this

#

automatically loadable kernel modules

#

so if a new device appears, it can know what driver to load for it, and do so automatically

supple hatch
obsidian pivot
#

Plug n play

supple hatch
#

plug n poop

tribal dust
#

poop n play

obsidian pivot
#

pooping play

supple hatch
#

@grand shadow catting /dev causes a page fault

#

lol

grand shadow
#

oops

#

I think I forgot to add a check lmao

supple hatch
#

lol

supple hatch
#

cat the root directory

#

lol

#

CAT THE WORLD

obsidian pivot
#

@grand shadow

#

yea chown does nothing

#

same with chmod

#

yeah the ext2 driver might somehow be broken?

#

I made an nvme disk

#

with an ext2 partition on the first partition

#

and it doesn't like it

#

"bad signature"

#

the debugfs tool is fine with the partition

#

unless I've done something wrong

grand shadow
grand shadow
obsidian pivot
grand shadow
#

By default it boots from the disk and not a partition

obsidian pivot
grand shadow
#

To nvme0n1p1

grand shadow
#

I think the tmpfs root has mode 0 by default

#

Just a very tiny detail meme

#

@obsidian pivot did it work

obsidian pivot
#

I'll be back in 1 and a half hour

grand shadow
#

mkay

grand shadow
#

I have fixed the tmpfs meme and the devfs memes on the latest 2 commits

fleet osprey
#

nice

obsidian pivot
#

@grand shadow

#

when booting from nvme0n1p1

grand shadow
#

Hm

obsidian pivot
#

nvm

grand shadow
#

Can you boot from the initrd and mount the nvme disk

#

Oh

obsidian pivot
#

I don't have init there

grand shadow
#

Lmao

obsidian pivot
#

on my partition

#

how I mount

#

mount?

grand shadow
#

mount -d /dev/nvme0n1p1 /mnt ext2

#

Iirc

#

Just run mount and itll say what you need

obsidian pivot
#

that was it

obsidian pivot
#

@grand shadow check this out

grand shadow
obsidian pivot
#

if anyone was wondering how you can make your own

obsidian pivot
grand shadow
grand shadow
obsidian pivot
grand shadow
#

Capybara

obsidian pivot
#

I meant borrow

split gazelle
#

even macos

#

for some reason

supple hatch
#

does it crash it

split gazelle
#

no

obsidian pivot
#

what does it do

split gazelle
#

it returns the raw ufs directory structure of /dev

#

back in the old unix days, everything is literally just a file

#

to the point you can cat directories

#

some bsds and sysv derivatives have removed it on all directories but /dev because some older programs needs it

grand shadow
#

while I figure out the new driver stuff I should do something very silly (make smp not suck hard because jesus christ)

analog berry
#

Truee

grand shadow
#

and after that implement sysconf and after that have glxgears run multicore

#

since it checks sysconf for the number of processors online

prime juniper
#

Something Managarm should also implement (tho we have some other scheduler memes to fix for that to be useful first). @lean kettle how’s that thread migration going?

lean kettle
#

Unless the floods get so bad that it's literally impossible for me to return I'll be in Austria again by the 17.

prime juniper
#

Alright. I’ll remind you again later this week then and/or check up on if Austria is Netherlands 2.0 now meme

#

Enjoy your time in London until then

lean kettle
#

Family wanted me to extend me being in the UK on quite short notice and the Airbnb there was cheap and the friend I'm visiting knows the place and was also OK with staying with me for a bit longer lol

prime juniper
#

Aight. Sounds nice. Enjoy!

lean kettle
#

Thanks! NekoRave

grand shadow
#

ohh you mean smp

prime juniper
#

We have smp but thread migration might be meh. Sysconf is mostly stubbed (with the same defaults posix has)

grand shadow
#

just added the include dependency stuff to my makefile 2024 is the year of the astral desktop

grand shadow
#

@carmine swallow @robust geyser pull and do a make clean-kernel all to generate the .d files

#

it finally happened, I stopped being lazy and made it better

robust geyser
#

good stuff

#

ty

grand shadow
#

and now I have changed all _cpu()->thread to current_thread()

#

I will also rename _cpu() to current_cpu() because something something reserved

analog berry
#

_cpu is perfectly fine

#

__cpu or _Cpu is reserved I think

#

But your version sounds better definitely

grand shadow
#

yeah current_cpu would also be more readable

gritty shore
#

curcpu() superiority

grand shadow
winged basin
#

linux loves underscores in its code but i resent them

#

everything is ___this() or ____that()

flat copper
#

just have _

wild marsh
#

foo calls _foo calls __foo calls ___foo

analog berry
grand shadow
#

_____________variable_____________

#

fuck it

#

xX_____________variable_____________Xx

#

like those stupid nicknames people use in online games

flat copper
grand shadow
#

alright so that should be all the current_cpu() races fixed

#

now onto tlb shootdowns

#

one day I'm gonna learn how to use libX11 or whatever and write a small portable suika game clone

#

which reminds me, I have some silly X11 programs in my backlog I should port

prime juniper
#

Might yoink them if they work on XWayland

grand shadow
#

git push works

#

:')

#

I do like the tone of green flanterm picks

#

wait FUCK I did a typo

#

😭

obsidian pivot
#

ps2moune

supple hatch
#

im cold

grand shadow
#

hi cold I'm mathewnd

tawny oak
grand shadow
tawny oak
#

haha very cool

grand shadow
#

first commit pushed from inside it and I managed to make a typo which is very fitting

fleet osprey
#

Based

#

Can't wait for the day where you can repeat this, then, still within Astral, open Discord and come brag in here meme

tribal dust
#

do osdev in astral

#

build a DOS in real mode assembly then run it in bochs

grand shadow
#

I have qemu and nasm and qemu seems to half work

grand shadow
#

Ill have to start crawling towards it slowly to get some progress done

#

Maybe after smp I can do a gtk port or smth

robust geyser
#

gtk is piss easy

#

literally steal from vinix lol

#

it worked on lyre

#

it worked(works?) on vinix

#

almost zero effort port, as long as your kernel isnt poop

grand shadow
#

I mean if it worked on lyre it probably works on vinix

neon crane
#

when fetching the current thread, you can simply mov rax, [gs:offsetofcurrentthreadincpustruct]

#

this is atomic so the gs base wont change during this fetch

#

you can also raise IPL/CR8 or disable interrupts

grand shadow
neon crane
#

i see

grand shadow
#

That was one of the most long standing smp bugs and Im glad I finally went and fixed it

#

Now I have to make my tlb shootdowns faster and then just fix whatever appears after

#

The tlb shootdowns are by far the biggest issue with smp

#

I do an ipi per page which is bad and I plan on just doing one per vmm_unmap etc

neon crane
#

that's what i plan on doing, i already have the infra in place

#

honestly it's kind of weird

#

you can only do one TLB shootdown at once

#

there is rudimentary support for batching but

#

idk I'm pretty sure it's air tight at least

grand shadow
#

How are you approaching them?

neon crane
#

in a very stupid way, step 1 is to acquire a spin lock that guards the entire operation

#

step 2 is to invalidate the pages on the local CPU

#

step 3 is to acquire the CPU local TLB shootdown lock on all CPUs but our own, then fill in the details about the TLB shootdown in the CPU local struct

#

step 4 is to fire an IPI to every CPU but our own

#

this IPI will invalidate the specific pages and release the TLB shootdown lock

#

step 5 is to re-acquire and release the CPU local shootdown lock on all CPUs but our own after the IPI

#

step 6 is to release the main lock and return

#

its kinda stupid, I know

#

l84: i do notice that i also release the spinlock to the initiator PRCB's tlbs lock which should be fixed

#

i might add an assert in the future there & shit

grand shadow
#

I do wonder if just reloading cr3 would be faster above a certain page count than looping through the whole thing invalidating pages

neon crane
#

maybe

#

well you will have to do it if you invalidate any pages you have set the global bit on as reloading cr3 won't invalidate those

grand shadow
#

Wrt to calling KeIssueTLBShootdown, do you just do that after the unmap operation (unmap -> shootdown -> release pages) or do you do it in an intermediate step (make pages inacessible -> shootdown -> unmap)?

neon crane
#

As soon as things are unmapped but I plan on refactoring it

#

Technically you don't need to do it until you reuse that memory region

#

Practically you should

#

Such an optimization would probably only be valuable in kernel mode since the kernel trusts itself

#

Sorry I was a bit incoherent right now

#

What I'm trying to say is there's an optimization that you can do in kernel mode where you only issue a TLB shootdown when reusing a region of memory

#

And that it should be disabled in debug mode to catch potential use after free bugs which can manifest in a nasty way in release mode

grand shadow
#

Yeah fadanoid had told me about it, I dont think I will do something like that because I dont trust myself lmaoo

neon crane
#

that's why you disable it in debug mode 😄

grand shadow
#

True

neon crane
#

speaking of do you actually have a debug/release distinction?

#

where you disable certain sanity checks in release mode

grand shadow
#

Nah I just have two defines for e9 logging and syscall logging

neon crane
#

i see

grand shadow
neon crane
#

clear the present bit in the PTE

#

and set another bit to tell the page fault handler that this page is to be freed and it's inaccessible

#

or something

grand shadow
#

My original idea was to make them inacessible, shoot down and then unmap and release since the physical address will still be in the page tables

#

But that needs going through the ptes twice

neon crane
#

so?

#

is that a problem

#

userspace typically rarely unmaps memory so I think it's fine

grand shadow
#

Fair

wild marsh
winged basin
#

but instead i've decided to do two sets of macros ({D,F}PCPU_{LOAD,STORE}). the F variant uses fixed offsets so they can be immdiates, while D uses variable offsets. i set up a .cpu_local section in the linker script and i arrange for a struct cpu_local to be positioned first (so that i can use offsetof on members of that in the F macros) followed by anything else defined with attribute section .cpu_local

#

the FPCPU_ are guaranteed to be atomic (amd64 %gs-relative, AArch64 %x18-relative, RISC-V %tp-relative, m68k they just directly touch the struct), the DPCPU are not guaranteed (they are on amd64 and aarch64, but this is impossible on riscv)

grand shadow
#

ok so smp support had bitrotted a bit but I have fixed that
wrt to it working, it ran configure and make -j3 (running with 2 cores) without crashing which is a start
I am redoing my shootdowns atm which should speed it up quite a bit hopefully

grand shadow
#

I wonder two things:
is a broadcast (all but self) ipi slower than sending an ipi to every single core individually? and do you need to EOI an ipi?

#

I cant find anything in the sdm about the later but I probably am just blind

#

I assume you do need an eoi though

obsidian pivot
#

nope

#

at least I don't and it works fine

grand shadow
#

oh bruh

obsidian pivot
#

and design

grand shadow
#

meh I might just send it indivually in my tlb shootdown, might allow me to do some other optimisations too

grand shadow
#

well good news

#

it works

#

bad news

#

its still slow

#

so I suppose thats just an astral skill issue somewhere

#

and glxgears segfaults meme

#

bad action

#

I assume its because of the changes I did to a vmm function

grand shadow
#

I wouldnt imagine there'd be that much contention at 2 cpus though?

grand shadow
#

the oberrow curse finally got to me @obsidian pivot

obsidian pivot
#

t'was bound to happen

#

gl on your journey

#

#1061407633745125397 message

#

found first message in astral thread

grand shadow
#

oop wait

#

I think I found the issue

#

yeah

#

that was stupid

obsidian pivot
#

what was it

grand shadow
#

I <3 logic errors

obsidian pivot
#

I love off-by-one bugs that cause two-weeks of debugging, two rewrites of an allocator, and your kernel earning the title "cursed" for the next year or two (it is cursed)

grand shadow
# obsidian pivot what was it
-                               newrange->start = (void *)((uintptr_t)range->start + range->size + difference);
+                               newrange->start = (void *)((uintptr_t)range->start + range->size);
#

glxgears still segfaultsaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa

#

oh oops

#

I shouldnt program while tired

#

ok glxgears works single core at the normal fps

#

2 core makes it

#

uh

#

why

#

WHY

#

mouse accelerated graphics I guess

#

the fuck

#

everything works at normal speed when I move the mouse

#

hm

#

its either my scheduler being sucky for smp (though still 2 cores makes it bad like that???) or some other skill issue

#

well

#

at least its stableish meme

#

considering most of the cpu time seems to be on the idle thread, I'm assuming its some other locking issue

grand shadow
#

could it be a race in my poll system?

#

since most of the ipc goes through it

#

and this shit is ipc heavy

#

shit

#

it might be a lost wakeup?

#
                if (revents == 0 || spinlock_try(&desc->lock) == false || spinlock_try(&desc->wakeuplock) == false) {
                        removefromlist(&pending, iterator);
                        insertinheader(header, iterator);
                }

                if (desc->event == NULL) {
                        iterator->revents = revents;
                        desc->event = iterator;
                }
        spinlock_acquire(&desc->eventlock);
        if (desc->event) {
                spinlock_release(&desc->eventlock);
                interrupt_set(intstate);
                return 0;
        }
#

seems like so

#

it does a check for desc->event in poll_dowait() but the spinlock_try(desc->lock) check prevents it from reaching desc-event = iterator;

#

that'd probably also explain why moving the mouse around makes it happy again

#

now I just have to go back in time and see what reason I had for desc->event = iterator to be down there

#

wait no

#

the desc->event is still reached

#

I'm just tired

#

still seems to be missing some wake up......

#

printing a ! on the sched_wakeup in poll_event and a . before the yield in poll_dowait shows a few seconds of delay every once and a while between the . and the !

#

its like a second

#

whatever I'll figure it out tomorrow thats enough

carmine swallow
#

btw I figured out one of the hda issues, I had set it so it only generates an irq after it has initially played two pages worth of data and the stream was started when there was two pages of data in the buffer and then it wouldn't generate an irq until it was done playing those two pages (and then it would be too late because the controller would already be playing the third page)

grand shadow
#

Huge

#

Does it work on your machine now

#

It might do on mine

robust geyser
#

cool stuff

#

i should try and build gcc with gcc-mlibc on linux to see if its really an mlibc allocator bug

grand shadow
#

@analog berry moving here from managarm

Smp seems to be stable with the new tlb shootdowns (didnt crash for me lol even with configure and make -j) and the only issue I think is some lost wakeup in some event code or smth

grand shadow
#

But

#

He did it on a newer version of gcc

robust geyser
#

i can try on the same version as we tried with astral

grand shadow
#

Would be cool

robust geyser
#

yea no problem i just need to grab linux-mlibc

#

damn this shit old

#

gcc 11.2.0

#

oh astral is on 12.1.0

#

i thought gcc was on like 14.2 nowadays

#

ok this is pain, for some reason mlibc wants libgcc and libgcc wants mlibc?

grand shadow
#

Libgcc moment

craggy tide
#

the way Vinix/Gloire solve it is by just using libgcc-binaries

#

you can compile gcc twice otherwise, but it doesn't really improve much

prime juniper
#

Yeah after working around that

#

I got a compile error in some gcov bs on Linux mlibc

carmine swallow
carmine swallow
#

so you could just make it not link against it pretty sure

grand shadow
#

If you leave an iso here I can try it later on my machines

carmine swallow
#

I tried it on the laptop but still got no sound (which I kinda expected tbh)

grand shadow
#

It could be some other issue on yours

#

Though I think it should be fixed on mine

#

When I get home Ill try it

grand shadow
#

I should see if qemu is fixed now after fixing that vmm logic issue

#

Since iirc it was a bad action access that crashed it too

craggy tide
#

ever since i added complex functions it does

carmine swallow
craggy tide
#

and in any case on other non-x86 archs you want it anyways, so...

grand shadow
#

@carmine swallow works on my desktop fine

#

gonna test on laptop now

#

though ^Cing it and trying to cat it again hangs it

#

Laptop works too

#

Good work qwinci

grand shadow
#

same shit as last time lmao

carmine swallow
#

I have no idea about the card getting stuck tho KEKW

#

nor it hanging if you try to cat it again into there, that doesn't happen in qemu

grand shadow
#

you can ctrl c and then cat again in qemu?

#

hmmm

#

funky

carmine swallow
#

yeah you can

#

at least as far as I tried

grand shadow
#

also did this fix the sdl delay

carmine swallow
#

Ill have to try, there is some kind of issue with doing a full build with make now tho

grand shadow
#

wait

#

did I push install-astral

carmine swallow
#

ah there is not even a source for that

grand shadow
#

oml I'm so dumb lmao

#

that was just a small test I had done

#

there pushed the removal

carmine swallow
#

did I ever happen to say why did tyrquake get stuck in "initializing palettes"? I can just find me saying about it but nothing about what the problem was

grand shadow
#

I dont thunk so

grand shadow
#

disabling the setitimer system calls makes it go away

#

fun

supple hatch
#

hi mathew

#

i exist !!!

grand shadow
#

hello nyauxmaster 5.0

grand shadow
#

hm yes poll is returning with revents = 0 for the fd

#

makes complete sense

#

yes

#

totally sane to return from the non-interrupted path where an event had to happen and you have a desc.event pointer to the data but it has revents 0

#

so there is a race here

#

it wasnt a race but me being an idiot

#

(the revents = 0 part)

#

seems like the xorg server is getting stuck in a setitimer call

#

for like a second

#

every once in a while

#

while fvwm is starting

#

that is progress on figuring out wtf is going on

#

my guess would be its stuck trying to schedule into the cpu where the itimer timer entry is on

#

honestly what I could do is temporarily raise the priority of the thread wanting to reschedule

#

and send an ipi to the other cpu to end the timeslice asap or something

#

that actually makes sense why its a bit laggy

#

x loves setitimer

#

I will add a sched_reschedule_on_cpu() function then that will handle optimising that shit

#

one thing I know for certain

#

smp on astral sucks lol

#

that's something I'll have to slowly work on

#

a proper smp scheduler, better locking, maybe even lockless things where I can fit it

grand shadow
grand shadow
#

and yeah seems like implementing the sched_reschedule_on_cpu() fixed that bullshit

obsidian pivot
#

seems as if we're both dealing with our schedulers

#

gl and god speed

grand shadow
#

the framerate is still unstable but at least its not whatever the fuck was happening before

#

2 cores

#

there is probably something else fucking me over

#

seems to slowly stabilize towards the upper 100s though

#

and its not dying so

#

smp seems stable

#

wonder if this random stuttering could really just be because of my scheduler not being written with per cpu queues

grand shadow
#

progress is at least being made and that makes me happy

#

just has rough edges

fleet osprey
grand shadow
#

Soon I will also change read, write and a few others to write directly to the page cache/device/pipe instead of the shitty way Im doing it rn

#

Think this just takes changing a few memcpys to the possible copy from user macro and then passing it directly

#

Ill need to see what to do wrt to readv/writev though

#

I forgot if it has any atomicity guarantees about the rw

#

It is

#

So Ill have to look into how I will do that

#

The socket read/write already takes in a descriptor about the operation that I can just slightly change if need be

#

Id also need to change the vfs_read/write page cache copy to support the new iov stuff

robust geyser
#

just lock for the duration of the copy, wouldnt that work?

#

in case of readv/writev

#

or just hope that it is going to be fine™️

#

iirc llinux does that with a lot of things, like i think directory listings are supposed to be atomic?

#

but i think that linux doesnt care

#

its one of those stupid things which probably dont matter in real world tho

#

this might be a bigger problem, but who would writev and write to the same fd at the same time anyway?

#

or writev from two different threads

grand shadow
#

My mind comes to named pipes, which you could write to from multiple processes and itd come out the other way in a way it should not

robust geyser
#

ah yeha that makes sense actually

grand shadow
#

I think just changing the vnode read/write functions to take in an iov and have a helper would be the better option

robust geyser
#

i cant help much im not knowledgable enough beyond "just slap a mutex around it™️"

grand shadow
#

Also pipe I/O has a guaranteed atomicity based on the size that I dont know how it interacts with readv/writev

#

Id assume it gets treated as just one big chunk

supple hatch
grand shadow
#

smp isn't very quick but it really seems stable now

#

the whole wget gnu hello etc etc make -j5 with 4 cores works fine

analog berry
#

Should try it on the managarm 128 core pc

robust geyser
#

you can build gnu hello again?

grand shadow
#

thats an issue with gnu hello's Makefile.am I am pretty sure

robust geyser
#

also i should try smp too but i cba to build astral again meme

analog berry
#

CBA?

grand shadow
analog berry
grand shadow
#

idk smp is still not 100% ok in astral

#

like its slower for some reason which I am still trying to find

#

either a scheduler meme or an ipc meme or something

#

just remembered another optimisation I still dont do, wake up a core to run a thread when its woken up if theres a core idle

robust geyser
#

you should try to schedule it on a core the thread has affinity for

grand shadow
#

I dont have per core queues yet, which is why I want to just redo the whole thing

#

also this

#

man my bad design decisions really are biting me in the ass now

#

but its not unsalvageable like old astral (at least not yet)

obsidian pivot
#

probably

analog berry
#

Inb4 astral rewrite

grand shadow
#

yeah scheduler

#

it really is unacceptable

#

though its something I've been neglecting since forever so its better I start fixing it now than later

analog berry
#

Since u only have one queue u have insane contention

grand shadow
#

even with like two cores?

analog berry
#

The lag is definitely contention I think

#

Where its coming from idk

#

U have lapic running on both right

grand shadow
#

I think I might just be doing a lot of shootdowns too

grand shadow
analog berry
#

What are u shooting down lol

#

Are they unmapping stuff

grand shadow
robust geyser
#

you only need to shootdown if mapping flags become more permissive

grand shadow
robust geyser
#

-x or -w

robust geyser
#

or if you unmap

#

so yeah...

#

i see

grand shadow
#

which is also why I am gonna stop being a lazy fuck and actually make they go directly to/from where they need to go

analog berry
#

Youre only sending tlb shootdowns if a process has multiple threads right

grand shadow
#
        bool do_shootdown = // do shootdown if
                current_thread() // scheduler is up
                && arch_smp_cpusawake >= 2 // and there are multiple cpus in the system
                && (page >= KERNELSPACE_START // and its either in the kernel
                || ((page == NULL || (page >= USERSPACE_START && page < USERSPACE_END)) // or in userspace...
                        && thread->proc && thread->proc->runningthreadcount > 1)); // in a process which has multiple threads running
analog berry
#

Didn't know gears were multithreaded

grand shadow
#

its because its shooting them down in the kernel

#

due to me not copying directly to the page cache or whatever

#

and the heavy amount of ipc

analog berry
#

I dont understand

grand shadow
#

like

#

every read/write/send/recv/whatever maps and unmaps some memory in the kernel temporarily to store the whole data

#

and if you do a lot of these you do a lot of shootdowns

#

because I dont queue them yet

analog berry
#

Wait ur doing that literally in the kernel

#

Bruuuh

grand shadow
#

yeah ik it sucks

analog berry
#

Optimize this

grand shadow
#

I am working on it rn lol

analog berry
#

Nice

grand shadow
#

ok, I've implemented enough for read(2) and write(2) to write directly to stuff and for stuff to go directly to the page cache too

#

noticeable improvement in glxgears performance for single core and startwm time for multicore

#

still missing recvmsg and sendmsg and other iov things though

#

that will be for tomorrow as I am too tired

#

used to be at like 200 for single core

#

now its almost 250

grand shadow
#

every day that passes astral sucks a little less :D

obsidian pivot
#

WWWW

grand shadow
#

@carmine swallow btw I changed the rules for read() and write(), now they can be passed an userland buffer
to safely do them you can use the usercopy functions (in the driver case for read it'd be with the USERCOPY_POSSIBLY_FROM_USER() macro for example)
ringbuffer read/write/peek can also now copy to/from user and returns RINGBUFFER_USER_COPY_FAILED if it failed (you should return EFAULT if it does or handle it appropriately)
do note that this means you can take a page fault if youre copying in the ring buffer to/from user or using the user copy
I mitigated this in other places by exploiting the fact that my ringbuffer implementation apparently doesnt need a lock to synchronize reads and writes, it only needs a lock really to protect itself from multiple readers or multiple writers, which can be delegated to a blocking mutex if need be

just telling you tho cuz you're working on the hda driver and this was kinda a major change
tho I'd wait until I have the iov stuff fleshed out since I still need to deal with that and it'd change stuff a tiny bit meme

#

I hope to have smp not sucking so hard by monday hopefully

#

Uni starts again monday

#

And friday is a day off work

analog berry
#

Good work

grand shadow
#

The talk in nyaux reminded me that I need to revisit my timers and make them suck less

#

I suppose finishing the rest of this work for smp, and then work on timers and possibly a scheduler rewrite(?)

#

Idk if I need to rewrite the whole thing or change some of it

#

Defo clean up though

supple hatch
#

i believe in u dwdw

obsidian pivot
#

Kernel rewrite meme

supple hatch
#

do it do it do it

grand shadow
#

Nah

#

Its not a lost cause yet

grand shadow
#

Reading the ULE scheduler paper

grand shadow
#

So far ULE seems simple enough and would possibly help increase responsiveness a ton on X.org

#

Though I still have a few pages to go its interesting

grand shadow
#

@analog berry does acpi allow you to find the cpu topology of the system

winged basin
grand shadow
#

Bet

#

ULE seems simple enough and good

analog berry
#

Ule?

grand shadow
#

The freebsd scheduler

analog berry
#

Ohh

winged basin
#

it's very good

grand shadow
#

IDK why but reading about ULE really hyped me up to rewrite my scheduler for some reason

grand shadow
#

found a bug in recvmsg

#

turns out I was not returning the flags nor the control length field properly

#

and returning them properly also made me find a non initialized stack variable bug in localsockets

#

so thats one less worry now

fleet osprey
#

nice

grand shadow
#

working on a proper iovec abstraction now

grand shadow
#

the goal for this would be to seamlessly replace the (buffer, size) in arguments for iovec_iterator_t and any ringbuffer_blahblah or usercopy_blahlblah calls with the new iovec calls

grand shadow
#

I think the iovec_iterator interface is done

#

I will first implement it for sockets as a first test

#

Then once Im certain its working I will replicate it for the vfs

#

And devfs

grand shadow
#

I should test to see if the bootsector snake clone I wrote works in astral qemu

#

at least that

#

also this is using the new iovec_iterator api for sockets

#

still havent checked the smp performance

#

better but still not satisfactory

grand shadow
#

If I had to guess its the cache being wiped every time it moves cpus

#

Need to run a profiler after I switch everything to iovecs

grand shadow
analog berry
#

No need to profile, it is that lmao

gritty shore
#

Pin tasks to a cpu

grand shadow
#

I will rewrite the scheduler soon to do that

neon crane
#

i wanna see if i can compile & run boron on here

#

(nanoshell requires clang or 32-bit gcc and i dont know if you have either)

#

(but boron rn uses the system compiler)

grand shadow
#

Gimme a sec

grand shadow
#

@neon crane this one should be updated

obsidian pivot
#

the message is a month old

#

but I'll just trust the iso is updated

grand shadow
#

I update the image meme

grand shadow
#

this work I'm doing of using scatter gather for all i/o will pave the way for clustered page in if I ever want to implement it

#

being able to cleanly iterate through the iovecs like its a stream and do stuff like memset/memcpy/ringbuffer rw/getting a page without much changes to existing code is nice

grand shadow
#

alright, I think all devices now support the iovec_iterator

#

all I have to do is just hook and adapt the filesystem drivers now

robust geyser
#

great job

#

i admire how efficiently you implemented it

neon crane
#

what the fuck

#

i think the compositor died

grand shadow
#

wtf

#

what did you do

neon crane
#

idk lol

#

i think i was futzing around with the "restart" option

#

i really dont remember what led up to that point

neon crane
fleet osprey
#

wtf
that's one interesting-looking way to fail

grand shadow
#

fvwm3 probably died then

#

since the startwm script execs into fvwm

neon crane
#

Also the clone process never seems to start

#

I wonder if it's because of qemu on windows' shitty network implementation

#

Other than using -display sdl (the default one is ass and wont keep the mouse locked)

#

I used the exact command line you sent

grand shadow
#

did you run netd

#

netd vionet0

#

I dont start it automatically

neon crane
#

oh

#

funny how it says that because the directory was empty

grand shadow
#

wonder what it even tries to do

#

since rmdir works

neon crane
#

this is uh

#

weird

robust geyser
#

maybe it would be a good idea to use -nostdinc in boron

neon crane
#

i should consider it

robust geyser
#

so it doesnt try to pull in random system headers

#

lol

#

yeah you definitely should

neon crane
#

but yknow

#

what IS the replacement for sys/cdefs.h here

#

its included by freebsd's sys/tree.h too

robust geyser
#

tldr a bunch of shit

neon crane
#

ok no it works without that header lmao

#

oh i think it will get stuck at the python generate_symbols.py step

grand shadow
#

y

neon crane
#

nvm

#

seems like yo udo have python3

grand shadow
#

yeah

neon crane
#

its going!

#

that warning i gotta fix because KeInitializeThread always returns SUCCESS

fleet osprey
#

[CC]\t
love that formatting

neon crane
neon crane
grand shadow
neon crane
#

nope

#

probably my own fault as i develop on windows

grand shadow
#

yeha

neon crane
#

oh god i gotta call git again

grand shadow
#

git sometimes fails for really big repos so you just gotta let it keep retrying

neon crane
#

eh

#

flanterm and limine releases cant be that big

grand shadow
#

the kernel youre using is also using some of the new iovec_iterator stuff but it should be fine too

#

for sockets only anyways

neon crane
#

guess i gotta use deinit

#

oh finally its working

#

80 kib/s

grand shadow
#

bruh wtf

neon crane
#

now 25 kib/s

grand shadow
#

when git cloning I usually get 700kb/s+

neon crane
#

and back to 75

neon crane
grand shadow
#

ohhh

neon crane
#

that might be a cause for slowdown

grand shadow
#

that explains it

neon crane
#

i can't use acceleration cause qemu on windows sucks

grand shadow
#

oh

neon crane
#

tbh i've never seen this lack of acceleration as a downside. it has made me actually optimize my shit

neon crane
#

how do i restart without losing data

#

i assume you have some kind of caching

grand shadow
#

sync

#

or

#

poweroff

#

since it calls into init to kill everyone and then sync

neon crane
#

poweroff didn't work

grand shadow
#

which is safer ig

#

wait what

neon crane
#

gimmie a second

#

oh wtf

#

did it lock up

grand shadow
#

interesting

obsidian pivot
#

I downloaded the astral image

#

root.img and the iso

#

and keyboard input doesn't quite seem to work

#

in Xorg

neon crane
#

😬

#

deadlock?

obsidian pivot
grand shadow
#

do infor registers

grand shadow
neon crane
#

i cant

grand shadow
#

what are you passing to qemu

neon crane
obsidian pivot
#
qemu-system-x86_64 -cdrom bootdisk.iso -M q35 -m 512M -enable-kvm -drive file=root.img,if=none,id=nvm,format=raw -device nvme,serial=deadbeef,drive=nvm -boot order=d -monitor stdio```
neon crane
#

so you can only see the bottom half

#

which isnt too interesting

obsidian pivot
#

-monitor stdio

#

to qemu

neon crane
#

well i can't restart now because i fear that i can't replicate the bug!

grand shadow
#

does qemu have instruction disassembly

neon crane
#

yeah

grand shadow
#

if its in the idle thread its a mutex deadlock or if its in some random context not halted its a spinlock deadlock

obsidian pivot
neon crane
obsidian pivot
#

I got it

#

nosmp worked

neon crane
#

eip always says its in this runqueue thing

grand shadow
#

does keyboard0 exist

obsidian pivot
#

somehoq

neon crane
#

so it's probably a deadlock with your runqueue

grand shadow
grand shadow
neon crane
#

also i wasn't using smp

grand shadow
#

its all being rewritten soon anyways meme

obsidian pivot
grand shadow
#

I'll try building boron here later and see if I can replicate

#

gotta finish this iovec_iterator stuff for ext2

neon crane
#

Also is there no top/htop/what

grand shadow
#

nah

neon crane
grand shadow
#

that needs /proc

neon crane
#

for god's sake that's why I pass -p to mkdir

grand shadow
#

did mkdir -p not work?

neon crane
#

its working now but it's strange to fail like that...

#

i guess it should be good enough for a restart right

grand shadow
#

should be enough

#

weird that poweroff isnt accessible tho

#

I leave it in /usr/sbin/

neon crane
#

is /boot linked to the boot drive

#

nvm uh

#

i guess a different question would be how would I access a drive other than the boot drive from limine

grand shadow
#

mount -d device directory fs

neon crane
#

from limine

#

caught these

#

ill just put them on an ISO normally and try to boot them

grand shadow
#

yeah I boot from the iso and just mount the nvme disk as root

obsidian pivot
#

what nics do astral support

obsidian pivot
#

I need to know what to pass to qemu

grand shadow
obsidian pivot
#

what cmd line would I pass?

grand shadow
#

in the message you downloaded the isos from

obsidian pivot
#

oh really

#

I just looked at the links

grand shadow
#

-netdev user,id=net0 -device virtio-net,netdev=net0

obsidian pivot
#

thanks

#

shit

grand shadow
obsidian pivot
#
qemu-system-x86_64: -netdev user,id=net0: network backend 'user' is not compiled into this binary```
#

guess I'm removing my qemu binaries

#

so is there some sorta make uninstall

#

good

#

TIL don't use make install with a system prefix

neon crane
#

so it is booting

#

but its so fucked up

#

it thinks KbdInitialize is an import

grand shadow
#

damn

neon crane
#

not supposed to!

grand shadow
#

at least it starts meme

neon crane
#

left: my host
right: astral

neon crane
#

honestly great job with it

#

hopefully it gets even better

#

the other objects seem to be fine, uh...

#

here's what it should have said!

obsidian pivot
#

astral is cloning obos

neon crane
#

to authenticate that it was built on astral yknow 😉

obsidian pivot
#

does astral have cmake?

grand shadow
grand shadow
neon crane
#

i transplanted my own but i could have just removed it lol

grand shadow
#

for the build

#

oh lol

#

still good at only one thing seems to be broken

neon crane
#

the memory manager is like the only thing blocking me right now from starting to write userspace code

#

i need to write the userspace facing parts

#

and shit

#

i wonder if i should just write a "first version" "by feels"

#

and then refactor later

obsidian pivot
#

I'll use my host to generate build files on the image

#

then build in astral

#

and see how it goes

grand shadow
neon crane
#

not sure what you mean by "something more like nanoshell"

#

I want to have a posix-ish DLL you can import and use at some point

grand shadow
neon crane
#

there will be some "native" stuff and you can additionally compile stuff for posix compatibility

grand shadow
#

I see

neon crane
#

tbh I might actually start with an mlibc powered ecosystem

#

like, boron.dll will expose system calls, mlibc will link with it

#

and applications will link with mlibc as a shared object

#

example:

int sys_vm_map(void *hint, size_t size, int prot, int flags, int fd,
               off_t offset, void **window)
{
    // N.B. hint ignored. Maybe not when I actually go implement it in boron?
    void* Address = NULL;
    BSTATUS Status = OSAllocateVirtualMemory(CURRENT_PROCESS_HANDLE, &Address, (size + 4095) / 4096, OS_VM_RESERVE, ConvertMmapProt(prot));
    if (FAILED(Status))
        return StatusToErrno(Status);

    if (fd) {
        // map the file in with another syscall
    } else {
        // actually commit it as anon memory
    }
    
    return 0;
}```
#

or even simpler

void sys_exit(int status) {
    OSExit(status);
    __builtin_unreachable();
}```
grand shadow
#

that'd be cool to see a more NTlike OS run mlibc

neon crane
#

about the cwd, i think that i'll have the current working directory as a concept in userspace and not in kernel space.

wild marsh
#

for MAP_FIXED

neon crane
#

but i'm not sure how that'd work with e.g. get_cwd

neon crane
#

can't you relocate the object if it can't be loaded at that addr

#

(side note, that reminds me a lot of the preferred base concept in PE)

wild marsh
#

you need one mmap call for each phdr

neon crane
#

yeah

#

and if you cant load the phdr at that address what do you do?

#

fail?

wild marsh
#

yeah and they need to be placed at known offsets relative to eachother

neon crane
#

or relocate

wild marsh
#

in the best case the mlibc linker more or less does: ```
top_address = max(phdr.p_vaddr + phdr.p_memsz for each phdr)

spc = mmap(NULL, top_address, PROT_NONE, MAP_ANONYMOUS | MAP_PRIVATE, -1, 0);

for each phdr:
mmap(spc + phdr.p_vaddr, phdr.p_filesz, protection_for(phdr), flags_for(phdr), elf_fd, phdr.p_offset)

neon crane
#

ah so this could be encoded with a single OS_VM_RESERVE AllocateVirtualMemory and some file map calls

#

i'll think about it when the time comes though

wild marsh
#

protection_for being self explanatory, flags_for deciding between MAP_SHARED/MAP_PRIVATE depending on whether it's ro/rw

wild marsh
neon crane
#

but wait

obsidian pivot
wild marsh
#

yeah elfs don't have a preferred base

neon crane
#

-1?

#

wheres the size

wild marsh
#

top_address is the size

#

assuming the base is 0

neon crane
#

but it adds p_vaddr

#

what if the image isnt relocatable and has a nonnull vaddr

wild marsh
#

then it's not a shared library

#

and it shouldn't have been processed in that function

neon crane
#

i see

wild marsh
#

actually no, my bad

#

we don't assume base=0

#
    if (mlibc::sys_vm_map(nullptr,
            highest_address - object->baseAddress, PROT_NONE,
            MAP_PRIVATE | MAP_ANONYMOUS, -1, 0, &mappedAddr)) {
neon crane
#

i see

neon crane
wild marsh
#

yeah

#

that's the idea anyway

neon crane
#

i see

wild marsh
#

we reserve as much as the library needs, then use MAP_FIXED to place chunks of the file in the correct spots

neon crane
#

oh that reminded me

#

mmap is kind of weird

#

it behaves in terms of pages

#

that means you can totally split a mmap range in half by doing
void* addr = mmap(pages: 6)
munmap(addr + 0x2000, pages: 2)

#

itll leave only the pages addr, addr+0x1000, addr+0x4000 and addr+0x5000 up

#

doesnt mean i can't adjust to that behavior it's just funny

wild marsh
#

you can also cause a split with mprotect

#

making the middle have different permissions

neon crane
#

cause you just zero out the relevant PTEs

#

but i'm... not seeking to do things too naively

#

like an mmap wont just reserve physical pages instantly

wild marsh
wild marsh
#

so on an operation that split it i needed to replace the existing mapping with 3 new mappings instead

neon crane
#

That's how I plan on doing things too, with something known as a VAD list (virtual address descriptor)

winged basin
#

you can tell mmap()'s origins

#

the APIs were added in 4.2BSD but not implemented, and the design was obviously intended for a page-by-page based representation

grand shadow
#

alright, I think the whole fs interface now uses iovec_iterator to pass the buffer

#

I am keeping the old vfs_{read,write}() as a helper but all of the action is done on the new vfs_{read,write}_iovec()

neon crane
#

what is iovec?

grand shadow
#

the scatter gather list in posix for syscalls like readv

#

I decided to make all my I/O use it

#

and handle it using an iovec_iterator_t that keeps track of some important things and exposes an api to copy data to/from a buffer or a ringbuffer and even get pages from the iovecs

#

so that it can get treated like a normal buffer transparently

#

its still not upstream

#

my reason to do this originally was to support copying userspace buffers from system calls like readv or sendmsg which supply a list of iovecs