#Astral
1 messages · Page 13 of 1
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
would be nice to debug that poweroff as well
@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
So I assume it was playing some unitialised memory
Cating it again just says starting stream and gets stuck there
Any idea why?
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
qemu seems to be trying to write to read only memory here
it seems like it tries to write to the first page of libx11 which uh what
I dont get it? it detects libiconv, adds it to $LIBS in the configure script but it just doesnt pass to the makefile???
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
this must be the least frustrating time I've seen anyone have using autotools 
@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
yeah that's weird, I have seen the codec get stuck when you do passthrough but not after rebooting
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
Lmao
Hmmmmm
Forgot to mention but while configuring smth else I ran into an assert in ext2 so I will investigate it when Im home today
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
Did you find out what the issue with your computer's card was?
no but I didn't really look into it that much yet (or to neither one of the ones that I own really)
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
Hmm same thing that happened on my desktop
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
implementing checking if directories are empty on tmpfs and ext2 on an unlink (I had forgor)
back to trying to build some random gnu package to see if gettext works
´when do you think they'll turn it off lol
probably never
it takes basically nothing to run an FTP server
maybe like, 1MB of RAM
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
wait
wtf?
something isnt right
I think someone forgot to remove the print lol
yeah, seems like it
@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
it has the autoconf GETTEXT thing in configure.ac
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
🔥
tons of fixes today
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
well, at least if you can replicate it, you have a starting point
better than most of my bugs 
inb4 dennis meant to put the print in the managarm sysdep
Whoops
One day mkdirat will not ignore its mode and when that happens it will be the year of the managarm desktop
lol
Aight bet. Sounds like I know my next PR 
@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
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
Ill look into it, thanks
cool, lemme know if u have any questions
Will do
Itll also let me clean up the init code a bit, I might also do it for the filesystem code
@analog berry does acpi need pci to initialise everything or can I use it to find the pci bus
namespace load potentially needs pci yeah
namespace load only requires access to pci bus 0
the rest can be iniitalized later
namespace initialize requires access to the entirety of pci
I assume theres anoter table that isnt mcfg that says pci is real then?
the order:
- uacpi_initialize
- read MCFG
- uacpi_namespace_load
- find pci busses
- uacpi_namespace_initialize
Or how does it work in legacy pci
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
Alright ty
npnp
integer overflow in the timer code that converts microseconds to the timer value, oops!
the nanosleep for eternity would then proceed to insert an entry into the past
inventing time travel one bug at a time
my ppoll had broken signal handling, oops
fixed that now and make -j2 is faster again
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
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
yeah I was probably thinking of something like that
my timer is one shot but I could figure something out
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
I should find out the average time it takes to access the hpet
apparently its like 1 us?
check for invariant tsc and just use the tsc as the global time variable :^)
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?
Nice
It's not even that hard
its not that hard if you are writing your kernel from scratch and not trying to retrofit*
Just a bit of elf funniness
sure
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
So PnP
pnp
Plug n play
plug n poop
poop n play
pooping play
lol
i will cat /

cat the root directory
lol
CAT THE WORLD
uhh
@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
Wtf
Did you set the boot device to nvme0n1p1
By default it boots from the disk and not a partition
Oh yeah uh tiny detail I think i hvent fixed yet
I think the tmpfs root has mode 0 by default
Just a very tiny detail 
@obsidian pivot did it work
I'll be back in 1 and a half hour
mkay
I have fixed the tmpfs meme and the devfs memes on the latest 2 commits
nice
Hm
nvm
I don't have init there
Lmao
that was it
Holy shit I agree
if anyone was wondering how you can make your own
btw what bg colour do you use for astral's console
I forgor lemme get it
uint32_t defaultbg = 0x1b1c1b;
uint32_t defaultfg = 0xffffff;
Capybara
took way to long to steal
I meant borrow
fun fact: you can cat /dev in some bsds
even macos
for some reason
does it crash it
no
what does it do
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
while I figure out the new driver stuff I should do something very silly (make smp not suck hard because jesus christ)
Truee
and after that implement sysconf and after that have glxgears run multicore
since it checks sysconf for the number of processors online
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?
It's something I should look at again at some point
Unless the floods get so bad that it's literally impossible for me to return I'll be in Austria again by the 17.
Alright. I’ll remind you again later this week then and/or check up on if Austria is Netherlands 2.0 now 
Enjoy your time in London until then
Am currently in Birmingham/Coventry right now lol
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
Aight. Sounds nice. Enjoy!
Thanks! 
wait managarm still doesnt have sysconf?
ohh you mean smp
We have smp but thread migration might be meh. Sysconf is mostly stubbed (with the same defaults posix has)
just added the include dependency stuff to my makefile 2024 is the year of the astral desktop
better than me who just doesnt bind threads to cpus unless they specifically ask for it 
@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
and now I have changed all _cpu()->thread to current_thread()
I will also rename _cpu() to current_cpu() because something something reserved
_cpu is perfectly fine
__cpu or _Cpu is reserved I think
But your version sounds better definitely
yeah current_cpu would also be more readable
curcpu() superiority
think I still have some other things to change around the kernel though since all calls to _cpu() are racey if the thread can get preempted
linux loves underscores in its code but i resent them
everything is ___this() or ____that()
just have _
foo calls _foo calls __foo calls ___foo
They run out of ideas for naming internal static functions so they spam _______
_____________variable_____________
fuck it
xX_____________variable_____________Xx
like those stupid nicknames people use in online games
Foo -> FooEx -> FooEx2
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
Might yoink them if they work on XWayland
git push works
:')
I do like the tone of green flanterm picks
wait FUCK I did a typo
😭
ps2moune
im cold
hi cold I'm mathewnd
you pushed this commit from astral?
yeah
haha very cool
first commit pushed from inside it and I managed to make a typo which is very fitting
Based
Can't wait for the day where you can repeat this, then, still within Astral, open Discord and come brag in here 
I have qemu and nasm and qemu seems to half work
Thatd take webkitgtk which pain
Ill have to start crawling towards it slowly to get some progress done
Maybe after smp I can do a gtk port or smth
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
I mean if it worked on lyre it probably works on vinix
btw even if you didn't do this there was a way to fix all the current_cpu races
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
This is what I am still doing in the back, gs points to the cpu structure and I do a gs relative mov
i see
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
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
How are you approaching them?
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
https://github.com/iProgramMC/Boron/blob/master/boron/source/ke/amd64/tlbs.c here's the code to what I just said
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
I do wonder if just reloading cr3 would be faster above a certain page count than looping through the whole thing invalidating pages
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
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)?
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
Yeah fadanoid had told me about it, I dont think I will do something like that because I dont trust myself lmaoo
that's why you disable it in debug mode 😄
True
speaking of do you actually have a debug/release distinction?
where you disable certain sanity checks in release mode
Nah I just have two defines for e9 logging and syscall logging
i see
Realistically the unmap -> shootdown -> release would be better but Id need to find a way to keep track of all the pages and I dont want to add anything to struct page to not make it even bigger
here's a way
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
I mean like for more userspacey stuff where you need to make sure there wont be an use after free
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
so?
is that a problem
userspace typically rarely unmaps memory so I think it's fine
Fair
struct per_cpu __seg_gs *cur_cpu; :^)
i almost ended up doing this
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)
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
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
oh bruh
for the former I'd assume it depends on the cpu model
and design
meh I might just send it indivually in my tlb shootdown, might allow me to do some other optimisations too
well good news
it works
bad news
its still slow
qemu-prof.sh does say that it isnt in the tlb stuff
so I suppose thats just an astral skill issue somewhere
and glxgears segfaults 
bad action
I assume its because of the changes I did to a vmm function
wonder if this could be because I have one queue for all cpus
I wouldnt imagine there'd be that much contention at 2 cpus though?
the oberrow curse finally got to me @obsidian pivot
t'was bound to happen
gl on your journey
#1061407633745125397 message
found first message in astral thread
what was it
I <3 logic errors
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)
- 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
brO
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 
considering most of the cpu time seems to be on the idle thread, I'm assuming its some other locking issue
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
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)
cool stuff
i should try and build gcc with gcc-mlibc on linux to see if its really an mlibc allocator bug
@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
Dennis did that and it works so
But
He did it on a newer version of gcc
Nice
i can try on the same version as we tried with astral
Would be cool
yea no problem i just need to grab linux-mlibc
https://github.com/no92/linux-mlibc god bless
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?
Libgcc moment
yeah?
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
Yeah after working around that
I got a compile error in some gcov bs on Linux mlibc
I didn't try yet
I don't think mlibc needs libgcc for anything on x86_64 at least
so you could just make it not link against it pretty sure
Ah damn
If you leave an iso here I can try it later on my machines
It could be some other issue on yours
Though I think it should be fixed on mine
When I get home Ill try it
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
Yeah
it does
ever since i added complex functions it does
ah
and in any case on other non-x86 archs you want it anyways, so...
@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
this makes my audio card get stuck btw
same shit as last time lmao
nice
I have no idea about the card getting stuck tho 
nor it hanging if you try to cat it again into there, that doesn't happen in qemu
also did this fix the sdl delay
Ill have to try, there is some kind of issue with doing a full build with make now tho
ah there is not even a source for that
oml I'm so dumb lmao
that was just a small test I had done
there pushed the removal
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
I dont thunk so
hello nyauxmaster 5.0
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
and small things like these that dont matter on uniprocessors but can make shit bad in multiprocessors
and yeah seems like implementing the sched_reschedule_on_cpu() fixed that bullshit
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
schedulers are fun until they arent
progress is at least being made and that makes me happy
just has rough edges
yeah, this is certainly an improvement over mouse-accelerated glxgears, lol
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
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
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
ah yeha that makes sense actually
I think just changing the vnode read/write functions to take in an iov and have a helper would be the better option
i cant help much im not knowledgable enough beyond "just slap a mutex around it™️"
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
hi
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
Should try it on the managarm 128 core pc
you can build gnu hello again?
well the intl meme still happens but meh
thats an issue with gnu hello's Makefile.am I am pretty sure
also i should try smp too but i cba to build astral again 
CBA?
it'd probably boot but slow down to a halt
Why is that
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
you should try to schedule it on a core the thread has affinity for
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)
whole scheduler you mean?
probably
Inb4 astral rewrite
yeah scheduler
this is how glxgears runs with 2 cores
it really is unacceptable
though its something I've been neglecting since forever so its better I start fixing it now than later
Since u only have one queue u have insane contention
even with like two cores?
The lag is definitely contention I think
Where its coming from idk
U have lapic running on both right
I think I might just be doing a lot of shootdowns too
yeah
due to me not queueing up ranges like in that optimisation
you only need to shootdown if mapping flags become more permissive
my read/write/recvmsg/whateverf being shit and doing a vmm_map and vmm_unmap
-x or -w
Bruh
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
Youre only sending tlb shootdowns if a process has multiple threads right
yeah
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
Didn't know gears were multithreaded
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
I dont understand
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
yeah ik it sucks
Optimize this
I am working on it rn lol
Nice
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
every day that passes astral sucks a little less :D
WWWW
@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 
I hope to have smp not sucking so hard by monday hopefully
Uni starts again monday
And friday is a day off work
Good work
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
i believe in u dwdw
Kernel rewrite 
Reading the ULE scheduler paper
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
@analog berry does acpi allow you to find the cpu topology of the system
see the SLIT and SRAT tables
Yes
Ule?
The freebsd scheduler
Ohh
it's very good
IDK why but reading about ULE really hyped me up to rewrite my scheduler for some reason
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
nice
working on a proper iovec abstraction now
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
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
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
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
Cuz I have no per cpu queue
No need to profile, it is that lmao
Pin tasks to a cpu
I will rewrite the scheduler soon to do that
@grand shadowcan you send me a complete iso?
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)
Gimme a sec
@neon crane this one should be updated
I update the image 
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
alright, I think all devices now support the iovec_iterator
all I have to do is just hook and adapt the filesystem drivers now
ty
what the fuck
i think the compositor died
idk lol
i think i was futzing around with the "restart" option
i really dont remember what led up to that point
this seems to restart only fvwm and not the system nor X.org
wtf
that's one interesting-looking way to fail
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
maybe it would be a good idea to use -nostdinc in boron
i should consider it
so it doesnt try to pull in random system headers
lol
yeah you definitely should
but yknow
what IS the replacement for sys/cdefs.h here
its included by freebsd's sys/tree.h too
ok no it works without that header lmao
oh i think it will get stuck at the python generate_symbols.py step
y
yeah
its going!
that warning i gotta fix because KeInitializeThread always returns SUCCESS
[CC]\t
love that formatting
oh
Its supposed to, you know, actually print the tab character
did it not chmod +x
yeha
oh god i gotta call git again
git sometimes fails for really big repos so you just gotta let it keep retrying
the kernel youre using is also using some of the new iovec_iterator stuff but it should be fine too
for sockets only anyways
bruh wtf
now 25 kib/s
when git cloning I usually get 700kb/s+
and back to 75
now i am using tcg
ohhh
that might be a cause for slowdown
that explains it
i can't use acceleration cause qemu on windows sucks
oh
tbh i've never seen this lack of acceleration as a downside. it has made me actually optimize my shit
L
1 more thing
how do i restart without losing data
i assume you have some kind of caching
poweroff didn't work
interesting
I downloaded the astral image
root.img and the iso
and keyboard input doesn't quite seem to work
in Xorg
do infor registers
wtf?
i cant
what are you passing to qemu
this ass console won't let me scroll back or page
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```
well i can't restart now because i fear that i can't replicate the bug!
does qemu have instruction disassembly
yeah
if its in the idle thread its a mutex deadlock or if its in some random context not halted its a spinlock deadlock
it works using the console option
eip always says its in this runqueue thing
does keyboard0 exist
somehoq
so it's probably a deadlock with your runqueue
that qemu cmdline doesnt even use smp tho lol
well shit
also i wasn't using smp
its all being rewritten soon anyways 
yeah idk what's up with that
I'll try building boron here later and see if I can replicate
gotta finish this iovec_iterator stuff for ext2
Also is there no top/htop/what
nah
that needs /proc
for god's sake that's why I pass -p to mkdir
did mkdir -p not work?
its working now but it's strange to fail like that...
i guess it should be good enough for a restart right
should be enough
weird that poweroff isnt accessible tho
I leave it in /usr/sbin/
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
mount -d device directory fs
yeah I boot from the iso and just mount the nvme disk as root
what nics do astral support
I need to know what to pass to qemu
virtio only rn
what cmd line would I pass?
theres literally a cmdline with it
in the message you downloaded the isos from
-netdev user,id=net0 -device virtio-net,netdev=net0
my guess would be xterm's default path doesnt add sbin
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
damn
not supposed to!
at least it starts 
yeah
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!
astral is cloning obos
to authenticate that it was built on astral yknow 😉
does astral have cmake?
this is without the kyboard module?
nope, only on the host
i transplanted my own but i could have just removed it lol
anyways about that comment above
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
I'll use my host to generate build files on the image
then build in astral
and see how it goes
do you plan on doing a posix server or doing something more like nanoshell
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
I mean like not unix
there will be some "native" stuff and you can additionally compile stuff for posix compatibility
I see
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();
}```
that'd be cool to see a more NTlike OS run mlibc
about the cwd, i think that i'll have the current working directory as a concept in userspace and not in kernel space.
the hint is needed for dynamic library loading
for MAP_FIXED
but i'm not sure how that'd work with e.g. get_cwd
why
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)
you need one mmap call for each phdr
yeah and they need to be placed at known offsets relative to eachother
or relocate
oh that's fucked up
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)
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
protection_for being self explanatory, flags_for deciding between MAP_SHARED/MAP_PRIVATE depending on whether it's ro/rw
it might also use a bump allocator starting at a fixed address instead of the initial mmap call, and/or it can use only anonymous mmap and read the contents of the file into the mappings
ah, so no preferred base like i thought
but wait
turns out cmake doesn't work like that
yeah elfs don't have a preferred base
i see
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)) {
i see
PROT_NONE with MAP_PRIVATE | MAP_ANONYMOUS simply reserves the address range with no actual backing right?
i see
we reserve as much as the library needs, then use MAP_FIXED to place chunks of the file in the correct spots
the actual code is in this function https://github.com/managarm/mlibc/blob/master/options/rtld/generic/linker.cpp#L418
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
yeah that behavior is kinda annoying
you can also cause a split with mprotect
making the middle have different permissions
if you do things naively it's actually very easy
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
oh and you can cause a split by mmap with MAP_FIXED too
in managarm it was annoying since the address space is made up of mappings which are ranges of pages
so on an operation that split it i needed to replace the existing mapping with 3 new mappings instead
That's how I plan on doing things too, with something known as a VAD list (virtual address descriptor)
it's irking
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
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()
what is iovec?
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
