Zinnia

[near tartan]

the mlibc pr?

[uncut jackal]

yep

[near tartan]

yea it's all just the api/abi itself

the impl isn't there yet

[uncut jackal]

still it's cool

[near tartan]

https://www.ebay.de/itm/335887602569

i bid on this thing

unlikely it'll sell for 700€

[cyan nexus]

only 300€, wow

[near tartan]

it's an auction

[cyan nexus]

yeah but still, only 300€ as of now it's very good

[near tartan]

it will go up 100%

there's still 6 days left

[near tartan]

what

@hoary cave why does this fail suddenly

[hoary cave]

uh good question

what changed?

[near tartan]

i removed the dependency on linux headers

[hoary cave]

hmm

[near tartan]

well, i actually changed something in the gcc patch

one sec

[hoary cave]

config.log?

[near tartan]

i dont even see what it's trying to build

ah libstdc++

[hoary cave]

host-builds/gcc-host/libstdc++/config.log i think

[near tartan]

no such dir

oh wait gcc-host

found it

[hoary cave]

configure:4286:  /build_dir/host-builds/gcc/build/./gcc/xgcc -B/build_dir/host-builds/gcc/build/./gcc/ -B/usr/local/x86_64-menix-mlibc/bin/ -B/usr/local/x86_64-menix-mlibc/lib/ -isystem /usr/local/x86_64-menix-mlibc/include -isystem /usr/local/x86_64-menix-mlibc/sys-include    -o conftest -O2 -pipe -fstack-clash-protection -march=x86-64 -mtune=generic -fcf-protection -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer   conftest.c  >&5
/usr/local/x86_64-menix-mlibc/bin/ld: cannot find crt0.o: No such file or directory
collect2: error: ld returned 1 exit status```

[near tartan]

🗿

wait but why is it looking for crt0

[near tartan]

it's supposed to look for crt1

oh wait the patch didn't apply

that's stupid

okay should work now

[near tartan]

mfw jinx gone

fixed the url

[hoary cave]

mint moved jinx to codeberg wtf

[near tartan]

so real

flanterm too

[hoary cave]

fair but

ugh

[near tartan]

ig this is why you don't depend on trunk

[hoary cave]

who did?

[near tartan]

no remember when we were talking about it

[hoary cave]

ah yeah

i thought you changed it to trunk

anyway did you see managarm/managarm#915?

[near tartan]

amazing

i might actually write a driver now

i need to fix my crts

https://github.com/managarm/mlibc/pull/1333

[near tartan]

okay cool codeberg is rate limiting me after 2 accesses

[near tartan]

😢

something is broken with my crts again

fucking hell

[near tartan]

something seems to be wrong with this

i dont see what

[hoary cave]

nothing

[near tartan]

then why the relocation shit

do i need an extern main???

btw 😃

[hoary cave]

also that's Scrt1

[near tartan]

yes see the error

[hoary cave]

are you statically linking?

[near tartan]

.

[hoary cave]

oh what

[near tartan]

isn't Scrt for PIC?

[hoary cave]

i dont think so

[hoary cave]

ah

im dumb then

[near tartan]

but i dont see what could be causing this

[hoary cave]

maybe missing .extern main?

[near tartan]

it's the same as managarm and linux

[hoary cave]

but that doesnt make sense

[near tartan]

let me try

nope

[hoary cave]

yeah im not sure then

something somewhere is incorrectly assembling that file probably

[near tartan]

yea

[hoary cave]

try looking at readelf/objdump of your Scrt1.o vs one that's known to be good

see if you can find any differences, maybe you need to fix up some patch

[near tartan]

oh wtf

it's a different relocation here

[somber solar]

Tulsi Gabbard took over this kernel

👊 🇱🇷 🔥

[near tartan]

LETS FUCKING GO

i think i got it

fucking stupid

[hoary cave]

that does not look like the solution

but if it works it works™️

[near tartan]

that's how glibc does it

[hoary cave]

WHA

[near tartan]

https://github.com/lattera/glibc/blob/master/sysdeps/x86_64/start.S

also interesting is that there is no PT_INTERP????

i thought that this is supposed to handle it

[near tartan]

cool

ncurses is dying

[near tartan]

im on my 10th cmake recompile

FUCK YOU !!!!!!!

WHY DO THEY NAME THE VERSION 4.0.0 BUT INSTALL TO 4.0

?????

[near tartan]

Menix is now upstream in mlibc

And the entire bootstrap distro is finally building

next step will be fbcon

then vfs

my old vfs impl is dogshit

[uncut jackal]

is this still a microkernel?

[near tartan]

it's not really feasible because i don't get as much time to work on it anymore

so i have to dial back on what i want to achieve

[uncut jackal]

ah it's fine

ig the new hot thing is loongarch now

[near tartan]

yes

[near tartan]

https://tenor.com/view/developer-we-have-a-bug-gif-9159002844106963379

[near tartan]

ok i have purchased the ideapad

[near tartan]

hm, i'm kind of struggling to make abstractions around user-owned memory

i thought of using a UserPtr struct that stores an Arc to the page table + virtual address

[grave peak]

anon_vma?

[near tartan]

elaborate

[grave peak]

Start pointer, end pointer

Struct pages pointing to it

See the ->mapping field of struct page on Linux

[near tartan]

i don't have a page struct

[grave peak]

Then that's gonna be really painful

You're gonna have to have some sort of a data structure for storing that

[hoary cave]

you need a way to keep track of memory in use

physical memory*

[near tartan]

wdym

like which exact regions are free?

hm

then i might actually not be able to use an allocator crate

[hoary cave]

no no, in use

or well, i guess free also by extension

but page struct is what you want

[near tartan]

i need to look that up

i've heard of it before but never seen it

[grave peak]

It's just some struct that stores Metadata about a physical page

Refcount, various links, flags, state, mapping links etc

[near tartan]

isn't that a lot of state for one page?

[grave peak]

64 bytes per page on Linux

Not that much

Considering this allows you to do tons of things at O(1) it's a very good thing

[near tartan]

hm

4gib of mem = 64mib metadata

that's actually okay

[grave peak]

Yours can be smaller depending on your architecture

[near tartan]

so where exactly are these structs stored

[grave peak]

You probably don't need all 64 bytes

[hoary cave]

yeah it is really okay

in memory

[grave peak]

Reserved usable memory

[hoary cave]

you allocate memory to keep track of memory

:D

kind of chicken and egg problem

[grave peak]

A chunk of usable memory gets eaten up at early init

[near tartan]

so i guess i need to have a big static buffer?

[grave peak]

You can just chop off part of the memory map

[near tartan]

ah

[grave peak]

Which is what proxima does for example

[near tartan]

i was about to ask for !linux sources

[grave peak]

Linux has a memory map allocator for that

[near tartan]

because as cool as it is, it's unreadable if you know next to nothing about it

[hoary cave]

bonus points if your pfndb is virtually contiguous and physically sparse :^)

[grave peak]

Yeah that's the best way to do it

[hoary cave]

keyronex

ah

sorry

[grave peak]

But it needs this to do a lot of other allocations and also respect Numa topology which u probably don't care about

So u don't need a full blown memory map allocator

Just a simple thing

[near tartan]

couldn't the memory map allocator be part of the .bss?

[hoary cave]

yeah sure

[near tartan]

idk if that's a smart approach

[grave peak]

Memory map allocator has a static array where u would store memory ranges

[hoary cave]

the only problem with putting stuff in the bss is that if you want to discard it later is becomes quite hacky

[near tartan]

#[link_section = ".reclaim"]

[hoary cave]

but if its < 1 page who really cares

yoo

[grave peak]

But u can have an even earlier allocator to carefully chop off a few pages for it lol

[hoary cave]

:^)

[grave peak]

Depends how elegant u want to be lol

[near tartan]

doesn't need to be too fancy

like rn i just have a [Range; 128]

[grave peak]

It's like begin+end, so 16 bytes per range

A page can fit tons of those

[near tartan]

yea

more than enough for any sane memmap

[grave peak]

Probably even for more insane ones too

[near tartan]

so yall are saying that i should ditch the allocator crate again and roll my own?

or is the page struct unrelated to it

[grave peak]

Ideally when u allocate a physical page what you return is not it's address but a struct page pointer associated with it

[hoary cave]

yeah and consumers store a reference to the page

instead of the address

[grave peak]

Yeah

[hoary cave]

if you need the page address you just page.address()

[near tartan]

and to access i would just hhdm?

[grave peak]

Yeah the address can be derived with one subtraction

[hoary cave]

access what?

[near tartan]

the memory

[hoary cave]

like the memory behind the physical page?

sure

or like

[grave peak]

Yes

[hoary cave]

other kind of mapping

like if it's a kernel stack it would probably just be mapped

or you can have a whole ass vm object abstraction

[grave peak]

You can have a page_to_virt or whatever

[hoary cave]

idk how this shit works

[near tartan]

i would love to have that ngl

abstractions are nice

[hoary cave]

yeah i wish i could help, maybe look at how managarm does them?

they have memory objects

[near tartan]

true

[hoary cave]

and it's c++ so it should roughly translate to rust

[grave peak]

It's probably overcomplicated because speed and micro kernel

[hoary cave]

nah

it's actually very robust

[near tartan]

i hate this phase of planning lol
everything depends on everything

[grave peak]

Ah ok

[grave peak]

Join the nyaux project

[hoary cave]

wrmsr(0xc0000081, asdjkasdka)

[near tartan]

real

well at least he is in userspace

meanwhile I'm seething about imaginary abstractions

[hoary cave]

same

one day my kernel will be the best

[near tartan]

premature optimization is a curse

[hoary cave]

the 129381297th iteration of it

it's not really an optimization

what you're doing

it's a pretty fundamental design choice

[grave peak]

Yeah lol

[near tartan]

damn

i guess good that I'm getting to it now because C menix didnt have this at all

[grave peak]

Yeah

[near tartan]

i had a user_access() function which only disabled smap ☠️

that should tell you enough

[grave peak]

CTFix

[near tartan]

in my defense i had a TODO there

so if i get this right:

• write memory map to reclaimable region
• initialize page allocator with enough backing memory to store meta for x amount of pages
• initialize normal allocator
  -profit?

[grave peak]

Basically

You only want to write usable memory ranges tho

Reserved stuff you don't care about

[near tartan]

would it make sense to preallocate the whole range of memory?

[grave peak]

Hmm?

[hoary cave]

min_usable_phys..max_usable_phys

[near tartan]

as in, for 4gib of ram, allocate 64mib for metadata

[grave peak]

Yeah, you preallocate struct pages

[hoary cave]

let max_phys = align_up(entries.map(|e| e.base() + e.len()).max(), PAGE_SIZE);
let pages = max_phys / PAGE_SIZE;
let reserved_memory = size_of::<PageMeta>() * pages;

[grave peak]

That's not super robust but if you're lazy it works

[near tartan]

what's the robust way

[grave peak]

Ideally u want sparse per region struct pages

So virtually contiguous but physically sparse

[hoary cave]

true

thats why i said bonus points for that :^)

because it is a bit annoying to handle

[near tartan]

oh god this might be just a bit aids in rust

[grave peak]

It is

[near tartan]

okay another bootstrapping problem, how am i going to map virtual memory if I can't allocate pages at that point 💀

[hoary cave]

it's aids in any language

[hoary cave]

im glad you asked

[grave peak]

U can allocate pages

U literally have your memory map allocator

[hoary cave]

yeah

you basically need a bootstrap allocator

then you can just say "give me the unused ranges"

and you can use those as the usable memory

[grave peak]

You can draw inspiration from linuxes memblock

[hoary cave]

https://github.com/48cf/osdev/blob/7a656b03c17661f6f427bc834423dba3237a28c6/kernel/src/mm.c#L139-L195

this is my old shitty code

and then https://github.com/48cf/osdev/blob/7a656b03c17661f6f427bc834423dba3237a28c6/kernel/src/mmu.c#L222-L277

[grave peak]

This is what proxima does i think, aka the lazier simpler way

[hoary cave]

for mapping the pfndb

you just need a separate thing for building up the initial page tables

[grave peak]

Or abuse bss

[hoary cave]

because you can't really use your allocator that hands out page* to set up these page tables

so you need some temporary shit and later probably adopt these back into proper structures

you can go from pfn -> page in two operation

[near tartan]

well the issue with bss is that it'll be both virtually and physically contiguous

[hoary cave]

it's not an issue really

why do you think it's an issue?

[near tartan]

idk

[hoary cave]

it's not like the page struct array has to be physically sparse

to do that you can just do the early page table shit

with an early allocator

then just map the regions of memory you need for keeping track of usable memory's page structs

after you have set up your page allocator you can probably create proper page tables and then reclaim the memory that the shitty ones were allocated from lol

like it's really simple when i think about it

but for some reason i have trouble implementing shit like that

[idle flower]

I have may have solved your problem already (after roughtly reading through this convo, for the page struct Design atleast, mine combines Page struct and buddy allocator)

[idle flower]

i use a binary tree with the leaf nodes represent page structs and the higher nodes for higher order buddy allocation encoded as a ezynger layout in virt memory

one such allocator per continous phys mem area

[near tartan]

link pls?

[near tartan]

hm but to get back to the problem at hand, how does this help me with reading data from a foreign address space?

[idle flower]

It would tell you which address space and at least for my Design the virt address in the hh map (only when the page is only used in that one address space, so not for cross process cow)

[near tartan]

but i already know which address space the address is from

like

say i get an ioctl from user space

@idle flower do i understand correctly? i should get the phys address for the user address, then lookup the page in my struct page array, and then return what?

[idle flower]

What should the ioctl do?

What does the user want?

[near tartan]

i just meant as an example

ioctl can pass a char*

and lets say i want to handle the ioctl

so i somehow need to access this user memory

e.g. if it's a struct or something

[idle flower]

In my design look up the phys address in the vmm, go to the pmm ask it for the entry and either it's already mapped in the hhpm (higher half process mapping (region of virt mem for the kernel to access all swapable user process pages)) access it there or if it isn't mapped map it there and access it (also increments the ref counter in the vmm)

It's not really designed for a non shared memory ipc

[storm bobcat]

ezynger?

[idle flower]

https://algorithmica.org/en/eytzinger

[pine rock]

i smell analysis paralysis

have you considered writing the interface that you want now, implementing it sorta badly, and then going back and improving the implementation when the need arises

[near tartan]

yes

[near tartan]

i mean is there any point if i already know now that it is a bad idea?

[pine rock]

because you want to do it?

thats a perfectly good reason to implement something in a hobby project

[near tartan]

i guess true

i just want to get back to a working state but everything is depending on my interface design rn

[pine rock]

i've learned to not overdesign

get something simple first, and if you need something more complicated later you will know your requirements at that point

you cant predict what you might need in a years time

[near tartan]

true

[pine rock]

https://tenor.com/view/shrimp-as-that-clash-royale-hee-hee-hee-haw-gif-25054781

[near tartan]

took way too long to get working

but fbcon is back now

there may be some illegal stuff going on

[near tartan]

i improved the performance of fbcon

now it can print about 2000 lines/s

[somber solar]

how does it compare to flanterm?

[near tartan]

no idea honestly

it can only do ascii

so in terms of features it sucks

flanterm has escape sequence parsing and all that

[near tartan]

@fair lintel

[fair lintel]

Based

[grave peak]

Damn

[near tartan]

it has acpi as expected

i need to figure out how to boot into the shell tho

[grave peak]

Like UEFI shell?

[near tartan]

yes

[grave peak]

Why do you want it?

[near tartan]

im stuck in windows lol

they dont show any prompt

so ill have to press random buttons

[grave peak]

What prompt tho

[near tartan]

like what to press to enter setup

[grave peak]

Like to install Linux?

[near tartan]

yes

or do anything other than windows really

i found it

f1

[grave peak]

What does it look like

[near tartan]

pretty clean actually

like x86 lenovo bios

i can take pics later

[near tartan]

first step unboxing any new pc nowadays

[grave peak]

Not an ad ™️

[near tartan]

tumbleweed is the only stable rolling release distro that works well on !x86

[grave peak]

Manjaro

[near tartan]

manjaro does not work well on arm#

it doesnt even work well on x86

[grave peak]

Works well enough for me lol

[eternal wharf]

install gentoo

[uncut jackal]

wow that's cheaper than I imagined

[near tartan]

yes

[uncut jackal]

nixos!

[near tartan]

nixos is bleeding edge i thought

[uncut jackal]

nixos unstable is

nixos-24.11 or 25.05 when that releases

stable is fresh but not bleeding edge

and breaking changes don't happen except for when the older versions go EOL

e.g. since electron versions go EOL pretty fast, electron gets breaking changes in stable

and nixos-unstable has every nixos test run (not necessarily passing but usually enough time between master and nixos-unstable to get the regressions fixed

[hoary cave]

don't give in to the nixos propaganda

[near tartan]

once my arch install dies im going back to tumbleweed since the nvidia drivers work now

im trying out nix tho

[uncut jackal]

give in to the nixos propaganda

[hoary cave]

baaased

(not based)

[near tartan]

in a vm

[hoary cave]

semi based

[uncut jackal]

just use nix on your host system with no nixos

[hoary cave]

no that sucks lol

[near tartan]

whats the benefit

[uncut jackal]

btw don't give in to anti-home manager propaganda

home manager is good

[near tartan]

wtf is that

[uncut jackal]

being able to use nixpkgs

being able to use nixstrap

being able to use home manager

[near tartan]

when nixstrap menix distro

[uncut jackal]

it's like nixos but for your home

per-user nixos

and doesn't need nixos

even works on darwin

[hoary cave]

home manager has got to be one of the worst jokes ever

[uncut jackal]

nooo

[hoary cave]

i remember i had some issues with it

[near tartan]

sounds like a windows paid program with a subscription

[hoary cave]

and people used to shit on it pretty hard

[uncut jackal]

I used to shit on it too

I shit on the impermanence home manager module

[near tartan]

mfs got venv for a package manager

[uncut jackal]

the impermanence nixos module is much more stable

[hoary cave]

what's kinda cool with nixos is that you can have a tmpfs / :^)

[uncut jackal]

yet I use both

[hoary cave]

not very useful but it's a thing i guess

[uncut jackal]

I have a tmpfs as root

and impermanent btrfs on home

[near tartan]

i frankly don't see the point

in my use case

[hoary cave]

same

[uncut jackal]

forces you to be declarative

[hoary cave]

that's why i don't use it

[uncut jackal]

and stuff I don't persist manually are deleted automatically

which is cool

I have a very tidy home

[hoary cave]

also, why impermanent home? how do you store stuff like cookies and credentials for programs?

[uncut jackal]

home-manager

[hoary cave]

ah

[uncut jackal]

they're stored in the nix store and linked on boot

[hoary cave]

that's kinda cringe

[uncut jackal]

nope

cuz it makes me use declarative options instead of writing the config file manually

so I can nixos-rebuild switch --flake .#hostname to get the same configuration on every computer

[hoary cave]

yeah no i get that

[uncut jackal]

poor man's synchronised dotfiles

[hoary cave]

wait

eh whatever, i'm happy with debian/arch + an install script :^)

[near tartan]

i tried out rustrover

sucks horribly

[cyan nexus]

it works "good" for me

[near tartan]

it sucks

[cyan nexus]

why?

[near tartan]

lagging while scrolling

[cyan nexus]

huh

[near tartan]

ui feels super sluggish

millions of menus

[cyan nexus]

for me it works very good

idk why it lags for you

[near tartan]

only when scrolling

[cyan nexus]

yeah, i don't lag there either

[near tartan]

@idle flower did u make any progress yesterday?

[idle flower]

some but couldnt figure out your error yet

prob need to talk to infy about that

[near tartan]

lmk if you need assistance with anything

i really need the barebones mode to continue working

[idle flower]

ok then i will skip directly to table stuff and ignore the faulty/missing types stuff

for now

[near tartan]

as long as it compiles with table mode it's fine

[near tartan]

hm i wonder if i should give my modules a command line upon entry

actually, yes i probably should

[near tartan]

on my 17th gcc rebuild today

🫠

but i already have gcc working on x86_64, riscv64 and loongarch64

now i'm finishing up aarch64, then i can start fixing llvm

YESSS

gnu toolchain is working fully

hm

is it normal that everything is 64k page aligned on aarch64?

[pine rock]

is that the minimum guaranteed size that aarch64 pages will have?

[near tartan]

i think that's the constant MAXPAGESIZE

because arm supports 64k

[pine rock]

yeah but does the spec dictate that 64k pages must be supported

if so i guess thats why they picked that number

[near tartan]

no clue

[near tartan]

that's the only clue i have tbh

[near tartan]

@hoary cave where did you get these offsets from?

(or to avoid xy:) where do i get the offset for loongarch

[hoary cave]

limine-c-template

[near tartan]

hm i guess loongarch doesn't need that then

[little oasis]

Holy shit

[near tartan]

it was worth it

[little oasis]

Did you manage to get mlibc to build?

[near tartan]

yes

i managed to build everything on all architectures

[little oasis]

Hell yeah!!

I forked mlibc, but I may consider trying to get a cross compiler build for my OS today

[near tartan]

👍

my patches are very pragmatic

they're not based on anything

just whatever works

[little oasis]

Sounds good to me!!

[near tartan]

this is with the jinx pr applied

huh wtf

[little oasis]

Once I finish my slab allocator today I'll probably get started on getting a proper toolchain in place. I'll probably also want to get started on porting mlibc for said toolchain too...

But seeing that arm64 had some issues during the build I'm a little skeptical

[near tartan]

@spark surge i must retract my statement

i stashed my recipes and for some reason now it works?

idk what happened

but still, i think that the pr could be useful at some point

you never know...

[spark surge]

ah

sure but please update the variable name before i merge it like i said in the other server ty

[fiery marlin]

Afaik that's just a riscv/qemu quirk, requiring the disk to be a certain size.

[spark surge]

yeah

[near tartan]

@grave peak

[grave peak]

Letsgo

Ill take a look once I'm home

[near tartan]

[grave peak]

well thats a giant blob

DSDT is 70k loc

biggest aarch64 blob ive seen for sure

tons of debug statements

tons of i2c

this laptop doesnt support acpi shutdown or sleep tho

7 PCIe segments

all properly reflected in AML which is cool

[near tartan]

bruh

u sure?

[somber solar]

how else does it shutdown?

[near tartan]

probably windows driver aids

[grave peak]

^

proprietary crap probably

[fair lintel]

btw how did you pull those tables

uefi shell?

[near tartan]

windows acpidump.exe

[fair lintel]

ah

[near tartan]

i think i accidentally packed the exes in the tar as well 💀

[grave peak]

u did

[near tartan]

lol

[grave peak]

yeah, it doesnt have _PTS, or any _Sx objects

[near tartan]

🗿

[grave peak]

it does support acpi reboot tho

maybe this is how it shuts down

it has a lot of proprietary QCOM devices

[near tartan]

yea i saw that

they have a qcom smmu

which linux doesn't support

[grave peak]

smmu?

[near tartan]

arm iommu

system mmu

[grave peak]

ah

maybe it uses PSCI or whatever its called for power management

[near tartan]

@grave peak @spark surge help pls

it compiles on my host, but not with jinx

[grave peak]

no idea, it's a standard header

[near tartan]

mfw i had to build the entire llvm toolchain for it to work

[near tartan]

we are back

i haven't filled out the hpet stuff

but should be ez

[idle flower]

School blocked me
Will try to get the table system to a point where you only need to implement a trait for a new table + table specific stuff

Basicly a template

On my phone btw

Trait AcpiTable: Copy + Drop + Send + Sync {

Fn try_new(index)
Fn table_count()
Fn try_new_all()
Fn try_new_all_in()

}

Alloc feature will be a extra feature flag

Also next push may break your stuff, made the feature flags rust compliant

[near tartan]

@idle flower im probably not going to be able to use uacpi-rs :/ because my kernel needs Special compile flags

[idle flower]

What flags?

[near tartan]

like compiler flags

-mno-general-regs -mno-red-zone on x86

on riscv i need some target flags

[idle flower]

No Generalr regs, wut?

[near tartan]

aaaaah

mgeneralregs only

[idle flower]

No red zone and stuff could be added as a feature flags

That too as a kernel flag

[near tartan]

what about riscv?

[idle flower]

What does it need?

[near tartan]

i need -march=rv64gc_zicsr_zifencei_zihintpause

[idle flower]

Excuse me?

[near tartan]

idk how you can encode that with feature flags

[idle flower]

What kind of brain fuck is that flag?

[near tartan]

the isa string

g = general
c = compressed
zicsr = csr instruction
zifencei = memory fence instruction
zihintpause = pause instruction

[idle flower]

Looks like a very big riscv L

[near tartan]

yes

[idle flower]

Is that a standard string or just for one board you own?

Also does the string influence the call Abi?

[near tartan]

standard thing

it does influence the abi

it's some sort of riscv baseline

[idle flower]

Then we could add it as the default

Some sort?

Sounds more like that riscv should get it's shit together, no wonder nobody big ports stuff there

[near tartan]

no i don't think this can work, there must be a way of providing additional arguments to the crate

because this might also be conditional on kernel flags

like i could also build with -march= rv64gcv

for vector insn

[idle flower]

And I assume that this isn't encoded in the target triplet?

[near tartan]

yes

[idle flower]

Absolute shitshow

[near tartan]

this isn't riscv exclusive

loongarch and aarch isn't marginally better here

[idle flower]

And they wonder why they aren't really used in the mainstream (outside of embedded/special purpose/server)

If they would have encoded it into the triplet it would be workable but that is just a nightmare

Do the riscv/arm/loongarch Isa string stuff influence the abi on the llvm-ir level?

Or just in the backend?

[near tartan]

afaik ir

because of intrinsics

[idle flower]

Sounds like my os won't be supporting those anytime soon

[near tartan]

lol

[idle flower]

I don't want to ship a billion llvm-ir blobs per programm just because the arch devs took too much lsd

[near tartan]

[idle flower]

So either they need to get their shit together and take a look at x86 or llvm needs to encode abi and support conditional compilation in llvm-ir

You could create a fork with the flags you need

That's the sanest path I can think of for the foreseeable future

What does it look like for arm/loongarch?

[near tartan]

i think with loongarch i have to do march=la64d

haven't gotten around to it

[near tartan]

rn im just running my own bindgen

for the time being

[idle flower]

@near tartan it seems like rust passes the target features to build scripts so uacpi-rs will work on riscv/aarch/loongarch

[near tartan]

how does it work?

[idle flower]

CARGO_CFG_TARGET_FEATURE=mmx,sse — List of CPU target features enabled.

[near tartan]

how is that translated to cc?

[idle flower]

https://doc.rust-lang.org/cargo/reference/environment-variables.html#environment-variables-cargo-sets-for-crates

Giant switch

Also this is readable via env! from normal rust

Discord shits itself again, messages take ages to send

[near tartan]

bruh

[idle flower]

had to resent all of them

[near tartan]

bruh

but like

how do the environment variables get converted into cc flags?

do you need to specify a function in the build process?

because when i did it, it didn't care about flags whatsoever

[idle flower]

switch case that creates a -march= string

at least for llvm

[near tartan]

ill have to see

because the march string for riscv should be encoded in the target spec

check my kernel in toolchain/riscv64-kernel.json

[idle flower]

yes and that should be passed to the build script via CARGO_CFG_TARGET_FEATURE

[near tartan]

weird

maybe i can debug that

[near tartan]

:D

[little oasis]

That's badass!!

[near tartan]

LETS FUCKING GO FINALLY

native ELF dependency tracking fully within cargo

it does automatic dependency tracking

[hoary cave]

how can it load nvme if it depends on pci?

shouldn't it load pci first?

well done tho :^)

[near tartan]

it parses nvme first, then realizes it needs to postpone it until pci is loaded

[steady echo]

good !

[fiery marlin]

nice

[near tartan]

today i need to finish up cmdline parsing and module relocations

then i do lapic setup and vfs stuff

then we can finally go into userspace again

i always thought that interrupt controllers were super complicated but it's not even that hard to understand ngl

i just need a generic abstraction for it, no idea how

i think i can do rerouting by irqs

[near tartan]

also i stubbed out that part

it just does the parsing atm

[near tartan]

today on fucking stupid cargo bullshit:

[near tartan]

okay i got further with the driver interface

the pci bus is now its own subsystem and decoupled from the kernel

[hoary cave]

that is kinda cool

* building host package: gcc
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  9 88.0M    9 8804k    0     0   880k      0  0:01:42  0:00:10  0:01:32  560k

fastest ftp.gnu.org download

[near tartan]

fr

[hoary cave]

it somehow managed to slow down too

anyway i can finally continue with the build

[near tartan]

btw prepare for cpu death

it has to build llvm

[hoary cave]

eh its fine

[near tartan]

thanks libclang

[hoary cave]

with or without clang?

[near tartan]

with

[hoary cave]

that explains

[near tartan]

for bindgen

[hoary cave]

fair

[near tartan]

technically i could use the containers llvm but it's debian so it's probably llvm 5

[hoary cave]

it's llvm 19

but yeah

[near tartan]

really?

crazy

btw make sure you update your jinx too

[hoary cave]

bookworm (stable) (devel): Low-Level Virtual Machine (LLVM)
1:14.0-55.7~deb12u1: amd64 arm64 armel armhf i386 mips64el mipsel ppc64el s390x
trixie (testing) (devel): Modular compiler and toolchain technologies
1:19.0-63: amd64 arm64 armel armhf i386 mips64el ppc64el riscv64 s390x
sid (unstable) (devel): Modular compiler and toolchain technologies
1:19.0-63: alpha amd64 arm64 armel armhf hppa i386 loong64 m68k mips64el ppc64 ppc64el riscv64 s390x sh4 sparc64 x32
1:16.0-58.1 [debports]: ia64```

i think jinx uses unstable containers?

but i might be wrong

also i just cloned bootstrap so i'm good

[near tartan]

ye

[hoary cave]

i did make install-minimal image

[near tartan]

yea that should work

[cyan nexus]

i built it fine, just took 1h

lol

[near tartan]

i kinda want a makefile target that builds/rebuilds a package because cding into the build dir is fucking annoying

[cyan nexus]

on the laptop i have

on my main it took around 20 mins

[near tartan]

takes me around 12 minutes, but i also have to rebuild a lot of times during patch work

[cyan nexus]

oh

[hoary cave]

maybe someone should add -C support to jinx

[cyan nexus]

yeah, but incremental build is way better

[hoary cave]

./jinx -C build rebuild pkg

[cyan nexus]

and fast

[hoary cave]

that would be kinda neat

[cyan nexus]

why do you need to patch llvm tho?

[near tartan]

im working on limine today, but i could throw that in as well

[near tartan]

for target support

[cyan nexus]

oh, you don't add it via a target file?

[hoary cave]

llvm?

[cyan nexus]

ye

[near tartan]

the kernel does have a spec

[hoary cave]

since when can you do that?

[near tartan]

but this is for user programs

[cyan nexus]

i think you can specify for them too

[near tartan]

would love a link to that

[hoary cave]

but either way that sucks

built in target is much better

[cyan nexus]

the only patch would be to libc for syscalls

i think

[near tartan]

i already have upstream mlibc support

i have all the pieces to go back to userspace again, so I'm probably going to do that

so pic, lapic, vfs + tmpfs

[cyan nexus]

pic?

not apic?

[near tartan]

legacy pic

need to mask it

[cyan nexus]

ah

[hoary cave]

done by limine already

[near tartan]

I can't rely on that

im multiprotocol, dont forget

[hoary cave]

you can in the limine code path

[near tartan]

it's like 4 outb's

[hoary cave]

lol fair tbh

[near tartan]

also at some point i want to have my own ap spinup

[cyan nexus]

no support for x2apic?

[near tartan]

that too

[hoary cave]

is there anything you really want done btw

that isn't too complicated

[near tartan]

the biggest issue atm is mapping new memory

not talking about writing page tables

just allocating arbitrary virtual memory that can map to a physical address

because i need to stop using the hhdm for that

[hoary cave]

i see

[near tartan]

modules also aren't actually loaded yet, just parsed :))))

[cyan nexus]

isn't access mostly linear anyway?

[near tartan]

and that IoSpace struct would be very cool

[hoary cave]

how do you allocate virtual memory for those?

[cyan nexus]

else you can use a linked list allocator

[near tartan]

in C i just did a bump allocator

"allocator"

atomic pointer that got incremented on every alloc

[cyan nexus]

buddy allocator will help you a lot for pmm

[near tartan]

i already have an allocator that uses the hhdm to manage memory

[cyan nexus]

even if you have segmentation it will work good anyway

[near tartan]

but yea i also need help designing the vfs/file abstraction

I don't think my impl rn is good

[hoary cave]

the problem is allocating virtual memory

[cyan nexus]

?

[hoary cave]

without relying on a linear mapping of the entire physical memory

[near tartan]

mapping device memory in the kernel space

you can't use an hhdm for it

because the pyhs addrs may exceed the range

(i had this happen on my old pc)

[hoary cave]

not even that, you usually want to map it UC

[near tartan]

tru

[hoary cave]

hhdm is generally WB

[cyan nexus]

UC and WB?

[near tartan]

but yes if we can get that done it would solve a lot of issues

[hoary cave]

uncacheable, writeback

[cyan nexus]

ah

[near tartan]

@hoary cave are u in vc tonight?

[hoary cave]

i can try yeah

depends on what time

[near tartan]

anytime really

im off work now

[hoary cave]

i see

[near tartan]

omw home

[hoary cave]

yeah just lmk

[near tartan]

k

[hoary cave]

i'm watching yt while building menix

llvm done yoo

building menix now

[near tartan]

pog

oh shit yea the llvm patch is broken too

it doesn't generate a PT_INTERP

:)

[hoary cave]

bru

[near tartan]

idk probably misconfiguration

[hoary cave]

good thing you told me that after it's built

[near tartan]

nah it doesn't affect kernel builds anyways

[hoary cave]

ah fair

[near tartan]

and for userspace i just use gcc

that "works"

as in, it probably does

[hoary cave]

what's the deal with menix and menix-debug nowadays?

you can't depend on both menix and menix-debug, otherwise the module files collide

[near tartan]

ah yea that's an oversight on my end

they're supposed to install to different dirs

[hoary cave]

hmm i see

[near tartan]

preferably I'd like the kernel and modules be in the same dir

probably in /usr/share

[hoary cave]

we can figure it out when ur home

[near tartan]

ye

about 10 mins

[hoary cave]

np, just lmk

[near tartan]

do not download gcc worst mistake of my life

[hoary cave]

at least not 200k/s

[near tartan]

2 bytes per whenever

[pine rock]

i've been using github as a slightly ghetto mirror for alot of stuff and it works pretty well

you end up with some pretty crap urls

[near tartan]

today i finish up the LAPIC timer setup

that reminds me, i still have to do scheduling

fuuuuuuuck

[somber solar]

it's fineeeeeeee

[near tartan]

not in rust

[somber solar]

does rust make anything easier?

[near tartan]

the memory management

[somber solar]

you don't like this?

[near tartan]

the issue is that i need to keep track of the threads in the scheduler

[somber solar]

why is that a problem?

[near tartan]

rust doesn't make this particularly easy

[eternal wharf]

nice the non-nothrow variants are broken :^)

if malloc returns null

[somber solar]

malloc won't return null

[eternal wharf]

how so?

[somber solar]

it panics instead

[near tartan]

huh

[somber solar]

also I have this magical flag -fcheck-new

[somber solar]

when out of memory

[near tartan]

are you talking about your kernel?

[somber solar]

yes

[near tartan]

ah

i dont panic on oom

[somber solar]

what do you do?

[near tartan]

i have reserved memory that gets claimed to have some sort emergency memory

and in that state i can invoke some functions to kill pids

we will see how well this works as soon as i got the timer interrupt running

[somber solar]

this? https://github.com/menix-os/menix/blob/3c0da18f6f831b6c10f2c5cf069569dacae5afce/kernel/src/generic/memory/mod.rs#L47

[near tartan]

yes

[somber solar]

well that would be easy to implement, I just don't have anything to free in case of emergency yet lol

[near tartan]

lol

[pine rock]

i just start failing userspace requests when i run out of memory

at some point i'll prioritize processes to ensure some programs can get memory in low memory situtations

[near tartan]

it's safe to say my old lapic code is not good

phenomenal

💀 what was i smoking

[distant cypress]

now look at the implementation of mmio_write16(). it might be movl

[near tartan]

💀

[near tartan]

@hoary cave okay i got the lapic stuff done but for some fucking reason it only works in tcg and my framework laptop (which then causes a gpf and sometimes a page fault in the allocator crate ???)

it doesn't work in kvm and on my thinkpad t14s

i'm probably missing something but w/e

maybe you see something i don't

fbcon potentially fucked???

okay no fbcon is clean

only happens when i enable interrupts :(

[near tartan]

another thing i have to think about, uacpi needs pci functions, but if i put the pci stuff a module, i can't really do anything because then i have a cyclic dependency

pci needs uacpi for the MCFG
uacpi needs pci

maybe @grave peak or @idle flower

[grave peak]

How does Linux solve it

Tbh PCI being a module is rather strange

[near tartan]

how so

[grave peak]

You either support it or you don't, it's a very core bus

Controller support may be loadable via modules

But the bus itself I see no reason not to always support

[near tartan]

do you thjnk i should do that for all buses?

[grave peak]

Some buses need special drivers, like the vmbus thing

But for something core like PCI I would have a CONFIG_PCI Y/N

[near tartan]

my kernel isn't configurable really, but i get it

i heavily dislike the linux way of builtin/mod/off configuration

[grave peak]

How so

[near tartan]

imo either everything should be a module, or nothing

[grave peak]

Some drivers are more important than others and are needed more often, those can be compiled in. Others barely exist and are only needed on esoteric hardware. I think this system makes flawless sense

[near tartan]

not talking about code changing configs, just entire modules

i have had multiple issues where some option was disabled in a distros config and i had to build my own kernel with that enabled

im probably exaggerating

[grave peak]

That seems tangential to y/n/m tho?

Or are you advocating for configless kernels?

[near tartan]

i believe that there is just too much that can be configured

[grave peak]

I think for that you should blame the hw not Linux

It just supports a lot of mutually exclusive scenarios

[near tartan]

fait

r

[grave peak]

But I understand your frustration

[near tartan]

(i may also be salty that I can't do builtin modules in rust)

[grave peak]

You cant? Isn't it just link object files vs just produce them etc

[near tartan]

my modules are .so's with an entry point and special PHDRs

and cargo doesn't make it easy to integrate

let alone have any form of configuration mechanism

sure there's the feature flags, but those are only on/off

[grave peak]

Ooh, maybe it would be easier if you made them objects

[near tartan]

maybe, but i refuse to do that

[grave peak]

Lol why

[near tartan]

.so's are simpler to implement

[grave peak]

Yes

[near tartan]

and they're actually meant to support this exact usecase

[grave peak]

Yes but plt got and all that disgusting stuff

[near tartan]

linux doesn't use them because the tooling back then was too bad

[grave peak]

Objects are better for runtime speed as well no?

Because no call indirection etc

[near tartan]

if you're doing pic anyways the difference isn't big

[grave peak]

Idk how pic works

[near tartan]

especially on !x86 relocations are a huge pain

[ionic lava]

Portable Executable doesn't have all these issues. And it handles circular dependency perfectly well. Just make your acpi and pci drivers boot time drivers and your loader will load them both.

[near tartan]

how does it not have these issues

you still need to patch instructions somehow

not to mention that PE tooling is absolute trash

[ionic lava]

You don't need to patch anything. It's really easy. Documentation on msdn explains this good. Writing from the phone, can't give the link. As of "trash" tooling, well, it's definitely about some specifical compiler, not the PE mechanism overall.

[near tartan]

how do i not have to patch it

that's literally how pic works

[ionic lava]

ELF's pic is really "trash", imo, of course. It's a pseudo pic with all that horrid plt got nonsense. PE is always position dependent. And it handles import/export easily. Via special easy to understand tables (IDT, ILT, IAT, EAT). they are documented and e.g. with msvc you solve circular dependency with no issues. .exp files and import libraries.

[near tartan]

msvc does not help with this

not to mention there isn't a msvc for riscv64/loongarch64

afaik

[ionic lava]

Clang should do for them. It follows msvc when asked. At least I know about arm64.

[near tartan]

clang has no support for it

also this is Rust

[ionic lava]

They added mips pe recently. And no loongarch?

[near tartan]

no riscv64 either

even EDK2 builds with GenFW instead of native toolchain

[ionic lava]

can't rust compiler/linker fow windows be used?

[near tartan]

no

[ionic lava]

That's probably as the common denominator to make all developers happy and depends more on what machines they use rather than anything. Edk doesn't use PE import/export capabilities anyway.

[near tartan]

the problem is that gnu-compatible tooling has no target for anything but x86_64 and arm64

[ionic lava]

Well, that's pity, because for the issue and needs you mentioned, PE is the best option. It solves what you need and want seemlessly. I use this mechanism, I like it.

[near tartan]

also, looking through some articles, PEs literally have relocations

idk what you're talking about

[ionic lava]

It's base relocations. You'd be surprised how easy they are to handle. For pc/ip relative real position independency archs like rv64, they basically boil down to a single DIR64 type. Object relocations are not present in executables like exe dll and sys.

[near tartan]

... but they aren't present either in ELFs

[ionic lava]

They are if your elf "drivers" are object files. Plus with elf you need to pretend to be pic by dealing with got, plt and sometimes got.plt. 😄

[near tartan]

my drivers are shared objects

i don't actually have to deal with that much

[ionic lava]

Then if you want to keep using it (.so), you must provide so loader, that will handle the latter. Couldn't elf handle circular dependency? So you configure your setup (not compile time, but via runtime, like Windows through registry) to load both pci.so and acpi.so then init them and use, avoiding lock?

[near tartan]

it could load them both, but my module loading is an atomic operation

partial loading is not allowed

[ionic lava]

So the issue is not with loading, but with the way the drivers initialize themsleves? Say, acpi during it wants something, that pci must have provided and the latter needs something else from acpi during providing that thing? Then it looks like a driver init cycle design flaw.

[near tartan]

it's more a security thing. driver's can't have unresolved symbols after being loaded, and they have an entry point that gets called as soon as loading is done

no partial dependencies allowed

modules should be seen as extensions anyways

but yes, tldr I'm moving pci into the kernel

[ionic lava]

Some platforms don't have it at all or have it as "just another peripheral" instead of like a big boss bus. rv64 SBCs might well be among such examples, so yay, you just decided to make your kernel filled with an absolutely unneeded stuff. like linux. 😁

[near tartan]

almost all boards have pci

like, I don't know ANY modern rv64 sbc that doesn't have pcie

the vf2 has it, the mars, meles, bpf f3, jupiter

[ionic lava]

in the x86 realm yes, in arm and rv totally not. eg there are boards with SATA/AHCI and pci, but the former doesn't sit on the latter, instead it sits on APB/AHB. Or even mutually exclusive PCI/XHCI.

[near tartan]

i only support uefi boot anyways so if there's uefiy there's high chances that there's pci

or at least i don't own any boards that don't have pcie

[fiery marlin]

I have pci as a module, I do it by having some acpi table stuff in the kernel (its needed for finding interrupt controllers). So the kernel also creates device endpoints in mcfg, so one for the port to access on x86.

[near tartan]

it's more about the uacpi pci callbacks

[ionic lava]

rv architecture/platform maintainers seem to do everything to not embrace uefi. I've never been able to find anything rv having uefi support even on vm.

[fiery marlin]

Do you have a way for modules to communicate they provide access to a bus?

[near tartan]

nope

[fiery marlin]

Ah

[near tartan]

qemu has riscv edk2

also u-boot efi exists

[ionic lava]

Never could start it. Just hangs. The only thing worked was uboot virt. But it's too limited.

[near tartan]

works for me

[ionic lava]

Honestly, I didn't want to compile it. And prebuilt things never worked.

[fiery marlin]

Its a bit jank, Ive had trouble if the version of ovmf isn't from around the same time as the qemu release.

[hoary cave]

i don't see anything immediately obvious

[near tartan]

oh yea also it only fires once

[hoary cave]

[near tartan]

[idle flower]

wont help you probably, my sytem manager pokes uacpi and enumerates the device tree each time it finds a bus controller it looks it up in the initramfs if present, it loads it and asks the driver for downstream devices/busses, if after that the boot source isnt availible it simply panics (initramfs error), once the boot source is availible it loads all missing drivers if possible.The system manager doesnt care about pci(e), its just another bus

[hoary cave]

@near tartan
https://docs.rs/num-traits/0.2.19/num_traits/int/trait.PrimInt.html
https://docs.rs/num-traits/0.2.19/num_traits/ops/bytes/trait.FromBytes.html
https://docs.rs/num-traits/0.2.19/num_traits/ops/bytes/trait.ToBytes.html

fun stuff, good to know we reinvented the wheel with the Primitive trait :^)

i think you said you knew there was a crate for that already lol

[near tartan]

i think i said i didnt want num traits

but that's braindead

[hoary cave]

i dont remember at that point

but PrimInt + FromByte + ToBytes is perfect

[near tartan]

yea if you can make use of it, feel free to put that in

[near tartan]

my honest reaction

yea i think num-traits is good

[near tartan]

@hoary cave are you going to do something with it or do i do it?

[hoary cave]

sorry i am doing managarm stuff right now

you can do it

[near tartan]

ight

just wanted to know so we don't do duplicate work

[near tartan]

@hoary cave what kind of type should the PerCpu thread field have?

this looks slightly cursed

idk if there's a better way

[hoary cave]

that's normal

[near tartan]

idk if it's a good idea to store a reference to the current thread

[hoary cave]

why not lol

if not then store a Weak

not an Arc

[near tartan]

whats that

[hoary cave]

core::sync::Weak

it's a weak reference

if Arc strong ref count goes to 0 you can't use the Weak to create an Arc anymore

but it's mostly used for cycle refrences

or like child holding a reference to a parent

i'm not sure if it's applicable here