#Zag

1 messages ยท Page 2 of 1

fallen bobcat
#

yes

heavy sandal
#

the endgame plan for mine is to only attempt a trylock-and-flush if moving to dispatch is a raise

#

if its already above dispatch it just skips the flush

fallen bobcat
#

huh

heavy sandal
#

and then ill just make the idle thread call flush KEKW

fallen bobcat
#

well having threads do it is what linux does iirc

heavy sandal
# fallen bobcat huh

so raise to dispatch in the trylock but if already above dispatch dont bother flushing

fallen bobcat
#

I guess I can have a periodic flush or something

heavy sandal
#

i might make it schedule a dpc if its above dispatch when it goes to flush

fallen bobcat
#

that's not a bad idea

heavy sandal
#

tbh i think i might make a helper soon for stuff like this

#

takes a function pointer and if its below dispatch it raises to dispatch and calls the function and if its at or above dispatch it queues a dpc that calls the function

fallen bobcat
#

what's neat is that if its already locked it means your thing will get output(ted?) anyway

fallen bobcat
heavy sandal
heavy sandal
fallen bobcat
#

why would you do a self-test

#

if dpcs dont work youre fucked anyway lol

heavy sandal
#

its not a true self-test so much as me just printing a test message from a dpc because im not confident enough in my code yet to trust em lmao

#

i do a lot of things like that, quickly using a thing early in init so if i break it it breaks early

fallen bobcat
#

I use DPCs a lot so I think they're not broken

#

the fireworks test ironed out a few bugs

fallen bobcat
#

because enqueuing a dpc that will do essentially nothing when theres little contention is kinda icky

heavy sandal
#

yeah

#

linux does a thing where a context can steal the flushing process

#

idk how it works

#

it locks in a way that makes the other thread break out of the loop when it starts waiting idk how

fallen bobcat
heavy sandal
#

yeah

#

do you do broadcast DPCs btw?

fallen bobcat
#

meaning?

heavy sandal
#

send a dpc to all processors, or all except self

fallen bobcat
#

no why would i do that

heavy sandal
#

instead of a single target processor

#

idk why you would lol, i have em but they make things so messy and i dont really have any uses for em so i might remove em

fallen bobcat
#

I have cool lockfree cross core calls tho

heavy sandal
#

damn nice, ill have to take a look at how you do that

fallen bobcat
#

not yet in zig

#

tho

heavy sandal
#

rip

#

i could make my DPCs lockfree if i was ok with making the queue a stack instead (aka prepend the DPCs)

fallen bobcat
#

you can make them lockfree if you dont need to dequeue them

#

but dequeuing is needed for e.g unloading drivers

heavy sandal
#

wdym dequeuing?

#

because im dequeuing them when i go to run them lol

fallen bobcat
#

cancelling a dpc before it fires

#

on an arbitrary CPU

heavy sandal
#

oh i dont really plan to support that at this point

fallen bobcat
#

otherwise you dont need locks as they are cpu-local

heavy sandal
#

oh lol true

#

also its still fairly easy to cancel a dpc on another cpu with a single atomic bool

#

just set a canceled flag in it that makes it get skipped

fallen bobcat
#

well yeah but thats clumsy when you have tons you need to skip over

heavy sandal
#

yeah

fallen bobcat
#

also you might wanna free those dpcs

#

so

#

use after free

heavy sandal
#

way easier than trying to make a lockfree removal from the middle of a linked list tho

fallen bobcat
#

just do it with a lock

heavy sandal
#

yeah ig

#

that is what i do now lol

#

my main problem rn is my wait code is a fuckin train wreck of edge cases and race conditions

#

and deadlocks actually i ran into a deadlock when trying to release a parked thread from an interrupt handler on the same cpu in the middle of queuing it to wait

fallen bobcat
#

at which point do I have too many files in the same folder

#

cuz i kinda wanna have log.zig and console.zig separate meme

heavy sandal
#

that is entirely up to you tbh

#

i made em separate lol

#

i tend to prefer more files over big files personally

fallen bobcat
#

yeah nah fuck it im keeping it in the same file

heavy sandal
#

does the fireworks thing require a framebuffer btw?

#

cause i might be interested in trying that once i get my scheduler going more but i dont have a framebuffer yet

fallen bobcat
#

probably need to describe the implementation of the ring in more detail tho

#

oh also need to include kconfig with it

heavy sandal
#

oh if you type up good comments for the log ring thatll be great

#

that shit is so hard to understand without comments if you arent an atomics knower

fallen bobcat
#

i tried explaining the orderings at least

#

but the wrapping arithmetic is pretty weird too

heavy sandal
#

ill read thru it when its not 1am lol

#

i dont think i could explain it or remember it offhand but the wrapping logic i found pretty understandable, but ig thats just compensation for how i look at any atomic ordering other than whatever x86 atomics are equivalent to and my brain just short circuits about it

fallen bobcat
#

I will try writing a module comment like the scheduler one

#

well not now cuz it is, in fact, 1 am

heavy sandal
#

top level doc comments slap tbh

#

as a feature

#

and yeah 100% fair lol

weary jetty
heavy sandal
weary jetty
fallen bobcat
#

lockfree queue is not worth it in this case

heavy sandal
#

but yeah also not worth the effort in this case anyway

weary jetty
#

The thought is more that non-blocking queues are sort of a solved problem.

fallen bobcat
#

mhm wondering if it's sane to put the console stuff in Ke

#

Doesn't really make sense imo

languid canyon
#

or the seq num thing

fallen bobcat
languid canyon
#

.

fallen bobcat
#

Well I made this with plain ops and it works so

#

Only the state transition needs to be ordered which make sense

languid canyon
#

wait so the issue u had was with relaxing something else?

fallen bobcat
#

Yeah

#

The first head load was relaxed

#

I should've made it acquire

languid canyon
#

where

fallen bobcat
#

In desc alloc

#

You already do it I think

#

I thought I could be smart and make the first load relaxed

languid canyon
#

ah

fallen bobcat
#

I'll explain why it's wrong in more detail later am on phone rn

languid canyon
#

sure

fallen bobcat
#

Also what do you think about flushing

#

Right now what I do is try lock the console lock and if it succeeds it flushes it

languid canyon
#

bad idea

fallen bobcat
#

But that might not be good for stuff like nmi or whatever

languid canyon
#

you can just starve a random core that happened to be unlucky

#

if other cores keep feeding logs

fallen bobcat
#

Ah so I can still lose logs

#

hmm

languid canyon
#

no

#

not lose

#

just have a core that hangs because it keeps flushing messages that keep appearing

#

thats why a takeover mechanism is important

fallen bobcat
#

ah

languid canyon
#

so if u have multiple cores that keep spamming messages they all steal each others flushing work

#

the last core to log does the flushing

fallen bobcat
#

The stealing

languid canyon
#

i dont even have smp

#

so i dont do it

fallen bobcat
#

It wasn't pointed at you but like in general

languid canyon
#

as for how linux does it just check the code

fallen bobcat
#

ah ok

languid canyon
#

lemme send a link

fallen bobcat
#

also do you think the logging stuff belongs in the core kernel or outside of it? Like the console registration and stuff doesn't really make sense to be there idk

#

I suppose I could figure out a better way to layer them nicely

languid canyon
#

basically check everything that uses handover here

languid canyon
#

but its hard to say

fallen bobcat
#

Gotta love their printk file being bigger than my entire kernel

languid canyon
#

since even the core kernel logs it probably belongs to the core kernel

fallen bobcat
#

The ringbuffer is in the kernel for sure

#

The rest I'm not sure about yet

languid canyon
fallen bobcat
#

I think what I can do to sensibly flush logs is:
on early boot, when no consoles are set up and threading and whatever is not initialized: flush synchronously messages in the ringbuffer up to an upper bound (to avoid starvation)
when fully booted, simply set an event when there is a new message and a worker thread waiting on that event will flush the logs

fallen bobcat
#

and all the console stuff can be put somewhere else

fallen bobcat
#

the temptation to add new features instead of porting to amd64

pastel citrus
#

what new features are you thinking of

#

i would try to port it to amd64 but sadly i can't be bothered to install a separate zig version for this project

fallen bobcat
#

I use zvm

#

I just do zvm i master --zls

#

then zvm use master

#

then zig build meme

pastel citrus
#

i just installed zig from arch repos lol

#

ill look at zvm

#

why master btw

fallen bobcat
#

I think

#

I wanted to reimplement the allocator and stuff

#

but the amd64 early init doesnt need it

#

I think I can get up to early init at least for now

fallen bobcat
#

so I do it incrementally

pastel citrus
#

ok cool it builds with master, thanks

heavy sandal
fallen bobcat
#

idk just to be sure

pastel citrus
#

oh yeah i didn't have to do the use part :^)

fallen bobcat
languid canyon
pastel citrus
#

fireworks

fallen bobcat
#

yes

#

it shouldnt hang

#

if it hangs tell me and I will cry for 3 hours then try to fix it

pastel citrus
#

it does not hang

pastel citrus
languid canyon
#

Cool

pastel citrus
#

and then i'll see maybe i'll work on my own kernel

fallen bobcat
#

I can do the early init work honestly if u dont want to

pastel citrus
#

idk up to you, i can try but idk what i'm getting myself into

fallen bobcat
#

it's annoying boilerplate

#

one thing I wanna try in the future tho is boot using hyper and maybe an efistub

#

that would be cool

languid canyon
fallen bobcat
#

sdl

#

-g sets up the bootloader parameters so it has a framebuffer created by sdl

languid canyon
#

Interesting

#

Do u emulate limine or smth

fallen bobcat
#

no I abstract over it

languid canyon
#

Ah

fallen bobcat
#

um also does this which is funny

languid canyon
#

Sounds like what you would expect

fallen bobcat
#

also @pastel citrus you might wanna pull and rerun the config thing because I changed kconfig

#

now the log buffer size is set using it

pastel citrus
#

cool, thanks

fallen bobcat
#

but it's really up to you, if you know other architectures id like that more than amd64 I think

#

because I already have amd64 code that I can rewrite so you dont have to think about it

#

aarch64 would be very cool if you know it

languid canyon
#

Naaah dawg

fallen bobcat
#

what ๐Ÿ’€

heavy sandal
#

smh

#

aarch64 hater infy

languid canyon
#

Real

fallen bobcat
#

I say aarch64 because I have a mac so running it virtualized would be cool

languid canyon
#

no committed state in the ring buffer

heavy sandal
#

infy just hates arm in general iirc

languid canyon
fallen bobcat
pastel citrus
#
[iretq@raptor zag]$ zig build iso
iso
โ””โ”€ install generated to myos.iso
   โ””โ”€ run xorriso (myos.iso) w
xorriso 1.5.6 : RockRidge filesystem manipulator, libburnia project.

Drive current: -outdev 'stdio:/home/iretq/sources/zag/.zig-cache/o/a9bd2e42e4b51123d6fa024dbf022427/myos.iso'
Media current: stdio file, overwriteable
Media status : is blank
Media summary: 0 sessions, 0 data blocks, 0 data,  948g free
Added to ISO image: directory '/'='/home/iretq/sources/zag/.zig-cache/tmp/0340e873cb132937'
xorriso : UPDATE :      11 files added in 1 seconds
xorriso : UPDATE :      11 files added in 1 seconds
ISO image produced: 2101 sectors
Written to medium : 2101 sectors at LBA 0
Writing to 'stdio:/home/iretq/sources/zag/.zig-cache/o/a9bd2e42e4b51123d6fa024dbf022427/myos.iso' completed successfully.

failed command: xorriso -as mkisofs -R -r -J -b boot/limine/limine-bios-cd.bin -no-emul-boot -boot-load-size 4 -boot-info-table -hfsplus -apm-block-size 2048 --efi-boot boot/limine/limine-uefi-cd.bin -efi-boot-part --efi-boot-image --protective-msdos-label ./.zig-cache/tmp/0340e873cb132937 -o /home/iretq/sources/zag/.zig-cache/o/a9bd2e42e4b51123d6fa024dbf022427/myos.iso```
#

๐Ÿค”

languid canyon
#

Not as an arch

fallen bobcat
pastel citrus
#

wow

#

wtf

fallen bobcat
#

zig build run should do it all

#

I dnt think it actually builds tho

languid canyon
fallen bobcat
#

main.zig is a stub dont use that, the entry code should be in platform/amd64/entry.zig or smth

pastel citrus
#

makes sense, gotta adjust build.zig then

#

i saw that it picks between platforms/um/entry.zig and src/main.zig meme

fallen bobcat
#

actually ideally theres something like platform/boot/limine.zig with a limine_entry() or limine_main() that sets up the boot info and passes it to the platform entry

#

thats probably better

#

thats what i did with my old code

heavy sandal
#

one thing i always like is having the arch declare a const with the calling convention

#

and then the limine main or whatever can pull that to set the callconv on it

pastel citrus
#

in amd64/entry.zig

fallen bobcat
#

what does that do

pastel citrus
#

just references the symbol

heavy sandal
#

forces it to be included in the compilation

#

and not be culled by lazy eval

pastel citrus
#

limine being the shared module that does the setup

heavy sandal
#

i use it to force include the arch init stuff on mine but leave my krnl.zig as always the module root

fallen bobcat
#

I think it should be something like:

if config bootloader is limine:
  entry = platform/boot/limine.zig

then in limine.zig y ou do something like:

fn limine_main():
 convert limine to boot info
 pl.impl.entry(boot_info)
pastel citrus
#

actually that's not too stupid

#

seems easier than my thing

fallen bobcat
#

that's what I did in my old code

#

acutally I can send you a tarball if youd like to take a look

#

most things are structured similarly

#

it's in C

pastel citrus
#

i'm too lazy ngl

fallen bobcat
#

alright meme

pastel citrus
#

looks like i need to add some more code to config.zig

#

to extract shit like bootloader from the config

fallen bobcat
#

no

#

yes

#

you can

#

if you want

#

like getPlatform

pastel citrus
#

hm, i added it as a field to platform

#

optional field ofc

#

i can change it later

#

i'm gonna eat now, dinner came up

#

if you want it done relatively quick then you can do it tbh, i usually work pretty slow meme

#

i'm mainly doing it for fun so don't feel bad

fallen bobcat
pastel citrus
#

that's good, i'll see how far i can get with this after i'm done

fallen bobcat
#

but like if u can get up to first_init() working that would be great

#

I can do the rest

pastel citrus
#

sure sounds good

fallen bobcat
#

oh fuck you might need to remove the stuff in kern/init.zig for it to build

#

I just assume std.heap.page_allocator exists

#

so remove all the thread stuff (or put it behind a if (false))

pastel citrus
#

i saw some errors earlier related to that lol

fallen bobcat
#

moslty just comment out the function and the related code

pastel citrus
#

should be easy, thanks

pastel citrus
#

error: ld.lld: undefined symbol: memcpy

#

now Why the fuck would that ever happen

heavy sandal
#

never seen that one before

fallen bobcat
heavy sandal
#

no you dont

#

not in zig

fallen bobcat
#

yes you do

pastel citrus
#

i just copied them from main.zig to root.zig and it works

heavy sandal
#

well

#

memcpy the symbol you do

#

but @memcpy exists and __builtin_memcpy exists and is defined in compiler_rt

#

even on freestanding

fallen bobcat
#

dunno

heavy sandal
#

why arent you using @memcpy

pastel citrus
#

also, xorriso doesn't return 1 on success

fallen bobcat
#

im not even using memcpy!

pastel citrus
#

it just prints to stderr

heavy sandal
#

and its siblings @memmove and @memset

pastel citrus
#

and in zig terms that means it "failed"

#

for some reason

fallen bobcat
#

I dont use memcpy anywhere

#

I dont think so

pastel citrus
#

zig does

heavy sandal
fallen bobcat
#

zig

heavy sandal
#

zig defines it!

fallen bobcat
#

the runtime does im sure

#

bruh then idk

heavy sandal
#

in compiler_rt!

pastel citrus
#

clearly not ๐Ÿ˜ญ

fallen bobcat
#

llvm might rely on it

pastel citrus
#

something is wrong then

heavy sandal
fallen bobcat
#

its probably an llvm thing, but like I stole that from the zig template and it also defined its own stuff

heavy sandal
#

im literally linking c code and didnt need to define memcpy/memmove/memset

#

whats your target triple?

#

and your build script for that matter

pastel citrus
#
fn targetQueryForPlatform(plat: config.Platform) std.Target.Query {
    var q: std.Target.Query = .{
        .cpu_arch = plat.arch,
        .os_tag = plat.os,
        .abi = if (plat.os == .freestanding) .none else .gnu,
        .cpu_model = .baseline,
    };```
#

.cpu_arch = .x86_64 and .os_tag = .freestanding

heavy sandal
#

wait does baseline work for x86_64? ive had problems there

pastel citrus
#

yeah it should

#

otherwise it'll do native

#

because you aren't cross compiling

#

that's the logic in the build machinery

#
if (plat.os == .freestanding) {
        kernel.linkage = .static;
        kernel.pie = false;
        kernel.bundle_compiler_rt = false;```
#

bruh

heavy sandal
#

theres your issue

#

compiler_rt is what provides memcpy/memset/memmove and all that

fallen bobcat
#

this is from the zig template

#

dont blame me

pastel citrus
#

idk what kind of a shit template you found that does that

heavy sandal
#

well then i blame whoever made that template being stupid

fallen bobcat
#

i took that and removed everything apart from the target stuff

pastel citrus
#

well there you go

#

should've been using my template

#

(outdated but oh well :^))

fallen bobcat
#

yours uses make

heavy sandal
#

lmao

pastel citrus
#

at least it gets the kernel building right

#

unlike this abomination

fallen bobcat
#

hey my build system is really nice

#

i think

pastel citrus
#

except for the part where xorriso seemingly fails

#

but it doesnt

fallen bobcat
#

xorriso issue

pastel citrus
#

it's because it prints to stderr

heavy sandal
#

yup

pastel citrus
#

but it's really annoying ngl

heavy sandal
#

thatll do it

fallen bobcat
#

doesnt matter it still works

pastel citrus
#

๐Ÿ˜ญ

heavy sandal
#

๐Ÿ˜ญ

pastel citrus
#

one _ = mkiso.captureStdErr(); later:

#

we ball

fallen bobcat
#

very cool

heavy sandal
#

nice

pastel citrus
#
/// Panics!
pub fn panic(comptime fmt: []const u8, args: anytype) noreturn {
    // FIXME: this is probably broken.
    std.log.err("KERNEL PANIC: " ++ fmt, args);

    while (true) {}
}```
#

beautiful

heavy sandal
#

nice lol

weary jetty
fallen bobcat
#

its a fairly standard bonwick slab allocator

#

with magazines and stuff

#

I'm leaning towards making something more freebsd-esque though, their allocator is quite nice

heavy sandal
#

one of these days im gonna have to get my head around magazines tbh

weary jetty
fallen bobcat
#

one thing that is cool is they integrate it with their safe memory reclamation mechanism

#

they also claim it is faster than linux's SLUB

heavy sandal
#

slub is what ive got on my end

weary jetty
fallen bobcat
#

he's a very cool guy

#

he's also the one who wrote their scheduler

weary jetty
#

He was always a better programmer than I by far.

fallen bobcat
#

do you mean jeff?

#

he's also a farmer or something

weary jetty
fallen bobcat
#

ahh

#

I thought you meant jeff

#

the guy whos doing the talk

weary jetty
#

I haven't heard from him in 15 years either.

fallen bobcat
weary jetty
#

Ah, so Samy is just randomly putting up the video of Jeff's talk on his channel? Well, he always did have good taste in algorithms, too.

fallen bobcat
#

about freebsd's memory allocator and safe memory reclamation

weary jetty
#

I'm making it cargo fmt and warning clean, will just make sure I can log in on all 3 architectures & then do the initial push to GitHub even without the documentation written yet.

fallen bobcat
#

curious to see what you came up with

#

is it all in rust? I know you mentioned sel4 but I'm unsure how it relates

weary jetty
# fallen bobcat curious to see what you came up with

I appear to have accidentally backed out my own pagetable sharing bits, but the critical VM idea is page clustering for a software-configured allocation unit larger than the MMU/TLB mapping size to do 2 things with superpages:

  • guarantee superpage allocations will not fail due to external fragmentation for superpage sizes less than or equal to the allocation unit
  • bridge wide gaps between the MMU/TLB base page size and the first superpage size by choosing allocation units to make it easier, thereby trading internal fragmentation to reduce external fragmentation
pastel citrus
#

time for some smp ig

#

actually, i'm not even sure if i can do that considering there isn't an allocator

#

fireworks also need an allocator :(

weary jetty
fallen bobcat
#

the allocator thing

pastel citrus
#

yeah that is fair

fallen bobcat
#

for smp I think it will be bootloader dependent idk

#

like in limine.zig I can probably boot up other cpus

#

and for other bootloaders do it manually

pastel citrus
#

yeah, that's kind of where i put ke.ncpus = 1; and ke.cpus = ...;

#

not ideal but whatever

fallen bobcat
#

in the future I'll do away with cpus[] entirely

#

I think I'll do the linux thing and only work with ids

weary jetty
fallen bobcat
#

linux uses ids to access cpu-local variables

#

what I did before having cpu-local sections is I had a global array of cpu structs and used that instead

#

but now I'm transitioning towards ids

weary jetty
#

I've not done too much thinking about per-CPU affairs. I don't even remember how my magazines find their CPU-local data.

fallen bobcat
#

what I do for magazines is store an array of ncpus magazines per kmem cache

#

which is also what solaris does

fallen bobcat
#

based

pastel citrus
#

yeah

#

there are some hacks to get it to work tho

weary jetty
#

I wonder why not to have a virtual range dedicated to per-CPU data.

fallen bobcat
#

that also works

#

I pretty much have that actually

fallen bobcat
#

nvm it is

#

im stupid

#

yeah no i need to adjust a bunch of stuff (like the per-cpu stuff is just plain wrong) but this should be a nice start

#

thanks

pastel citrus
#

it works!!! (in the one-cpu case meme)

fallen bobcat
#

it should use the gs offset trick

#

sec

pastel citrus
#

you mean where gs is the percpu_offset?

#

and you just end up doing gs:variable

fallen bobcat
#

this

#

I guess for now its fine since smp stuff isnt done

weary jetty
#

There's no way legacy features like segment registers can't have huge legacy emulation overheads.

pastel citrus
#

why lol

#

that's literally how memory works on x86

heavy sandal
#

yeah

pastel citrus
#

memory addressing in general

heavy sandal
#

even on long mode its all segments still

pastel citrus
#

although segments dont affect virtual->linear address translation in long mode

#

fs/gsbase still does

heavy sandal
#

iirc fs/gsbase is actuaslly the segment base register just extended and only directly accessible through the msrs

weary jetty
#

I think there's a default segment register. I don't know that other segment registers suffer large legacy emulation overheads.

heavy sandal
#

thats why i keep separate gdts percpu

#

because the fsgsbase is tied to it somehow

weary jetty
fallen bobcat
#

also minor nitpick: thread context can be kept fully on the stack

weary jetty
fallen bobcat
#

no

#

I'm talking about context switching

weary jetty
#

Oh, x86 context handling is insane enough that I have to do it straight out of the book every time.

#

The tech debt exists, but squashing it doesn't have to be done by hand, so in some respects the rate-limiting factor is my tech debt assessment & spotting speed.

fallen bobcat
#

so is it a microkernel still?

weary jetty
fallen bobcat
#

@pastel citrus do you plan on continuing the port or not? if so idt and gdt setup would be cool otherwise I think this is enough for now for me to go clean up and implement the allocator and stuff before we move on to a full port

#

mhm well i guess setting up the boot info for real would be good too

heavy sandal
#

i assume yall already know this since i think ive mentioned before but if you use export for the limine protocol stuff dont forget to call std.mem.doNotOptimizeAway so the compiler doesnt constant-fold the null default response pointer

pastel citrus
fallen bobcat
#

yeah that would work

pastel citrus
#

do you want me to make a pr?

fallen bobcat
#

yeah

pastel citrus
#

alright

fallen bobcat
#

Ill merge it directly and clean it up

pastel citrus
#

sounds good

fallen bobcat
#

or I can do like you did with my limine PR meme

pastel citrus
#

but yeah, i can always work on some other stuff later

weary jetty
#

Just a quick interactive login touch test on all 3 architectures now supported needs to get passed & the initial git push is imminent.

fallen bobcat
#

aaa you broke um

pastel citrus
#

wait how

#

oh it's probably me commenting out fireworks

#

and the make_thread thing

fallen bobcat
#

no

#

the build system

pastel citrus
#

wait really?

fallen bobcat
#

its ok I fixed it

pastel citrus
#

is it the platform entry file thing

fallen bobcat
#

like it shouldnt return error.noBootloader if on linux

#

and shouldnt use platform/x86_64

pastel citrus
#

oh โ˜ ๏ธ

#

ah i see how that works

weary jetty
pastel citrus
#

what

fallen bobcat
#

idk if having it be boot/limine.zig is a good idea (that's not what you did though)

#

because like if i end up on an architecture where theres only one bootloader isnt it weird to have boot/weirdbootloader.zig

#

idk

fallen bobcat
#

ok this is fine

weary jetty
#

The pool_cache(9) manpage doesn't describe the implementation in too much detail.

fallen bobcat
#

anyways this is really cool thanks a lot @pastel citrus

#

now I have to do homework

pastel citrus
#

im glad i could be of some help

#

even tho it was broken KEKW

pastel citrus
#

but in that case you can just have a function that decides the entry file path based on arch+bootloader

fallen bobcat
#

ok time for more amd64 stuff

#

also its crazy how discord hides my own thread after like 1 day of inactivity

#

I have to go search for MY OWN thread ๐Ÿ˜ญ

heavy sandal
#

it does that for all threads

fallen bobcat
#

but cant I set it so that it doesnt disappear for me

heavy sandal
#

i have a discord server that only im in and i just made a link to my thread and put it there lmao

#

yeah itd be nice to keep your own threads there longer

pastel citrus
#

you might be able to easily search for it if you press ctrl+t in the desktop app

#

i dont think there is a shortcut for that on the web version tho

fallen bobcat
#

there's hide after inactivity thing

#

but I think there was something in #announcements not to do that

weary jetty
# fallen bobcat ok time for more amd64 stuff

I've been porting to LoongArch64 and MIPS64, generalising things so it's not merely assumed that there's only one superpage size, I dropped in some easy cases for pagetable sharing & will probably let things spin doing fixes for LTP (Linux Test Project) overnight. I wonder if there are things like that for other kernels so I can get some other personalities going. *BSD? Solaris? Windows NT? OpenVMS? NFI.
I cooked up a data structure BTW: https://github.com/NadiaYvette/hybrid-radix-btree-adaptive
I also pushed telix upstream to my GitHub just in case you didn't catch it.

GitHub

Hybrid adaptive radix/B+ tree: ART for dense regions, sorted pages for sparse, bitmap leaves at depth 3. Outperforms ART 1.4-12.9x across all workloads. - NadiaYvette/hybrid-radix-btree-adaptive

fallen bobcat
#

oh didnt see you pushed it, nice

weary jetty
#

I never finished the docs but I got a first cut of the abstract & am going over revisions I need to make.

fallen bobcat
#

I'm gonna be interested for that more than the code since I'm not much of a rust guy

weary jetty
#

The Adaptive Radix Tree apparently has some relatively simple techniques to address its performance breakdown in sparse datasets, provided you're not shy about plugging B+ tree code for the sparse case.

#

I might bring it over to telix b/c it basically wins against B+ trees and ARTs by being the best of both by switching between them.

fallen bobcat
#

@heavy sandal do you use the limine header directly or did you write your own bindings

weary jetty
#

BTW the data structure code is in C.

fallen bobcat
#

bruh I can name fields type

#

I thought I couldnt so I named everything kind

heavy sandal
fallen bobcat
#

i ended up writing my own thing

heavy sandal
weary jetty
#

For what architecture(s) does it do bootloading?

heavy sandal
#

limine? a bunch, idk the list offhand

languid canyon
pastel citrus
#

i found myself needing limine bindings for my new wip project trl

weary jetty
#

From looking at EFI docs, I can't piece together quite enough details to figure out how to get from end to end, but it looks like the environment it drops things e.g. bootloaders into is easily rich enough to not be difficult to operate in.

heavy sandal
#

yeah efi aint bad at all

fallen bobcat
fallen bobcat
pastel citrus
#

trying to, yeah, but i am not gonna stick to that project for very long

fallen bobcat
#

Bruh don't be so hard on yourself

pastel citrus
#

nah i'm not, i just have no motivation to work on it

#

wanting to do something cool isn't enough

weary jetty
pastel citrus
#

i tried to read your and infy's log rings and i just realised i have no clue what the hell i'm doing tf

fallen bobcat
#

it's not like either of us could've implemented it without the Linux code lol

#

I did just write more comments tho if you wanna check that out

languid canyon
#

Log ring

weary jetty
#

I'm not sure I know what that is offhand.

pastel citrus
#

a lockless ring buffer for kernel logs

pastel citrus
languid canyon
#

Work on it for 3 days so u can surpass ultra in features

pastel citrus
#

eh i'm not really interested in having more features

#

i want quality

languid canyon
#

Damn

pastel citrus
#

and i just don't have the ability to put in these hours researching stuff and learning everything like you do

fallen bobcat
#

infy

#

uLog when

languid canyon
#

Never lol

pastel citrus
#

:(

languid canyon
#

U should make one

fallen bobcat
#

lol no

languid canyon
#

Your ring is more general purpose since its 32 bit

pastel citrus
#

i'd be the first to put together a kernel made out of all these uXXX libraries

fallen bobcat
#

It's pointless to make that an embeddable library

languid canyon
fallen bobcat
#

idk the thought of not NIHing stuff scares me

pastel citrus
#

idk, adhd maybe (diagnosis pending)

languid canyon
#

A lot of people want one

fallen bobcat
#

To me it seems lazy

#

uACPI is where I draw the line

#

cuz I ain't writing that shit

languid canyon
#

Maybe

fallen bobcat
#

but like flanterm and stuff ehh

languid canyon
fallen bobcat
#

If I reuse a bunch of libraries I don't learn anything

languid canyon
#

Yeah but you already made the code

#

U can now make it a library

fallen bobcat
#

Yes but the philosophy of reusing code others wrote in general annoys me

#

idk

languid canyon
#

Ig

fallen bobcat
pastel citrus
#

i hate reading

#

probably part of why im bad at this ;D

fallen bobcat
#

paging time soon nooo

#

oh wait no i need gdt init.. ok

#

first

weary jetty
#

MIPS is misbehaving here.

fallen bobcat
#

ffs i hate doing architecture stuff

#

its so boring

weary jetty
#

Usually MIPS has been the best-behaved of all architectures for me. I can't spot what's off about things that's making the first context switch to userspace fail.

weary jetty
fallen bobcat
#

yeah true

#

I've only really done x86

weary jetty
languid canyon
#

Lucky for you qemu emulates a ton of arches

weary jetty
languid canyon
#

@fallen bobcat in your UM target you do context switching right? Since it's just one target how do u handle different host arches?

fallen bobcat
#

I use ucontext

pastel citrus
#

ucontext

#

oops

languid canyon
#

how does that work?

#

is that posix or linux

fallen bobcat
#

ucontext does have overhead though, so I'm considering just emitting different assembly stubs for every arch

#

its posix

languid canyon
#

tbh who cares about overhead for debugging

fallen bobcat
#

yeah true

#

ideally posix would introduce a new generic way though since ucontext is deprecated

weary jetty
#

qemu doesn't have the access to the systems to verify the accuracy of their emulation or simulation either, and so often doesn't even attempt to emulate the systems. It just emulates the most common ones that people don't have trouble getting to begin with.

languid canyon
#

i wanna make a um target as well, ill probably get inspired by your code

fallen bobcat
#

please solve memory for me meme

#

so I dont have to think

languid canyon
#

thats a lost cause

#

maybe iretq solves it for us

fallen bobcat
#

lol

#

I do have an idea but not sure yet, I think I'll just ignore the vma limit lol

weary jetty
languid canyon
#

how do u solve it atm

#

just random bullsiht go?

fallen bobcat
#

well atm there is no memory at all, but in the old code I just mmaped it

#

i didnt handle switching address spaces tho which is what's actually tricky

languid canyon
#

how do u do fireworks and stuff without memory management?

fallen bobcat
#

well for now it uses mmap directly

#

to allocate memory

languid canyon
#

its basically kernel mode threads now right

fallen bobcat
languid canyon
#

oh ok

fallen bobcat
#

its just a stress test

fallen bobcat
languid canyon
#

do u have a slub?

fallen bobcat
#

no I have a bonwick-style slab

languid canyon
#

whats there to switch if its just kernel threads?

fallen bobcat
#

I also have cool ideas for that

fallen bobcat
languid canyon
#

i wonder how u would even do that

#

without it being incredibly slow

fallen bobcat
#

the naive solution is mapping and unmapping everything

languid canyon
#

yeah

fallen bobcat
#

korona pointed out there was a VMA limit issue too

#

but apparently linux doesnt care

languid canyon
#

yeah but like

#

unmap everything would be slow af

fallen bobcat
#

what linux does iirc is mmap only as a TLB of some sort

languid canyon
#

on every ctx switch

fallen bobcat
#

yeah idk

#

which is why its tricky

languid canyon
#

does it rely on userfaultfd?

fallen bobcat
#

well I would rely on it anyway

#

for CoW

#

and demand paging

languid canyon
#

um sounds like pain tbh

pastel citrus
#

it is

fallen bobcat
#

it's not

#

just dont do user apps if you dont feel the need to

#

I dont plan to have them rn but eventually it'd be very cool

languid canyon
#

basically the only thing you gain is asan

fallen bobcat
#

this is literally the only tricky part

languid canyon
#

which kasan would be cheaper to do

fallen bobcat
#

and full gdb

#

and tsan

#

and valgrind

#

and perf

languid canyon
#

tsan doesnt work

#

for barriers

fallen bobcat
#

ok true

languid canyon
#

valgrind probably would struggle but maybe

fallen bobcat
#

idk its like 200 lines of code so far and its really useful

languid canyon
#

maybe if u omit the usermode part

fallen bobcat
#

to me at least

languid canyon
#

its good

fallen bobcat
#

yeah you don't have to support user apps

#

you can also run unit tests/integration tests

languid canyon
#

someone here literally implemented ioapic etc emulation

#

to verify correctness

#

thats a bit too far imo

fallen bobcat
#

apache?

languid canyon
#

probably

fallen bobcat
#

personally I think it's a bit stupid to do that

languid canyon
#

like for stuff like that u can just boot qemu and get stdout

fallen bobcat
#

because you dont know if your emulation is correct, and if it is then you probably already know that your other code is correct

languid canyon
#

yeah

fallen bobcat
#

like you just end up writing tests you know will pass

#

so it's pointless

languid canyon
#

regression testing is still important but yes

fallen bobcat
#

well it's up to you if you implement it, but personally i have found it very useful

#

and I will keep shilling it

#

like if you consider most people here already move their code to userspace to test it first, I just go further and run the whole thing

languid canyon
#

probably

weary jetty
#

I've been running on qemu, so it's all debuggable anyway.

languid canyon
#

id say its not phenomenal value to run it in usermode but still useful

weary jetty
#

The ART-B+ tree hybrid seems like it should be deployable.

fallen bobcat
#

I have come up with a nice cpuid abstraction

#
    const feature_info = CpuidRequest.execute(.feature_info);
    const extended_features = CpuidRequest.execute(.{ .extended_features = .first });
    const extended_processor_info = CpuidRequest.execute(.extended_info);
    const power_management_info = CpuidRequest.execute(.power_management_info);
heavy sandal
#

nice

languid canyon
#

Why is it needed since cpuid is arch specific features anyway?

fallen bobcat
languid canyon
#

Hm

fallen bobcat
#

bruh my cpu doesnt support pcid

heavy sandal
#

@fallen bobcat btw do you trigger DPCs using an interrupt or do you just handle them as part of returning from interrupts/lowering ipl?

fallen bobcat
#

I do it all in software

#

You can do it all in hardware (using cr8) and use self-IPIs though

heavy sandal
#

self-ipis is what i do but im running into race condition hell about it atm

fallen bobcat
#

On windows the irql functions are basically inlined to a mov cr8

heavy sandal
#

(though i dont think its actually because of the route i took i think its just bad code i wrote)

heavy sandal
heavy sandal
# fallen bobcat What is it

ive got a function that queues DPCs if youre at or above dispatch and just runs the passed function if you arent. my event sync primitive uses that to defer signalling to dispatch irql to prevent race conditions in the yield function, but im running into use-after free on that event signalling dpc if the event never gets waited on

#

which is weird because the place where it isnt being waited on is running at a level where it should use the immediate callback and be fine

fallen bobcat
#

Why are you dynamically allocating your DPCs in the first place

heavy sandal
#

the use-after-free isnt the dpc, its the event object being passed

#

its just that i dont understand why the dpc is being delayed so much

fallen bobcat
#

bruh I got mails from the Linux mailing list but the mail client on my phone is ass

#

And they're all European so I'm fucked until tomorrow

languid canyon
#

oh cool u got 2 reviewed-bys

fallen bobcat
#

Wanna tell them maybe we should merge this and do another patch for other fixups

weary jetty
#

What's a DPC?

heavy sandal
#

basically just something you can queue up from inside an interrupt handler that then runs at a lower interrupt priority level

weary jetty
#

Ah, C can be painful to do continuation-passing style within.

heavy sandal
#

i think DPCs are a windows-ism originally?

#

idk maybe someone else did it before NT

#

and it isnt really continuation passing

#

its more like starting a thread or queuing something in a thread pool

fallen bobcat
#

DPCs

heavy sandal
#

yeah

#

except someone realised you can use the softirqs for other things that arent irqs too

weary jetty
fallen bobcat
#

No

heavy sandal
#

not afaik? and in any case the nt kernel's dpcs are still being used to this day

#

(well the executive's dpcs. nt things calling it separately KEKW)

weary jetty
# fallen bobcat No

I seriously remember everything getting moved off softirqs and onto kernel work queues or similar.

#

I think it was even part of the Big Kernel Lock removal.

heavy sandal
#

windows actually has something similar to that difference too

#

normal DPCs (similar to softirq) vs Threaded DPCs (similar to work queues)

weary jetty
#

The sweep was total IIRC. There should be no softirqs left in Linux.

fallen bobcat
#

too

#

which are built on softirqs

weary jetty
crimson sand
weary jetty
#

My (micro)kernel never had a Big Kernel Lock & whatever was wrong with softirqs to begin with. The message-passing -based IO/VFS layers also make asynchronous IO work & M:N threading via scheduler activations makes threading facilities for various programming languages actually work, too (tested with Haskell/ghc, though I should add more languages' runtimes).

fallen bobcat
heavy sandal
#

i should probably implement threaded DPCs tbh (which are more like workqueues)

fallen bobcat
#

I will just have a generic workpool thing

heavy sandal
#

thats also an option

#

ive been waffling back and forth between whether to implement a kernel thread pool or threaded DPCs

#

(threaded DPCs effectively act as a percpu thread pool with one worker iirc)

weary jetty
#

I'm not sure if it's exactly applicable to telix. Things run in microkernels' version of โ€žuserspaceโ€ so a lot of things could be written in Haskell or Mercury or Idris2 or F# or F* or Scala3 or whatever.

heavy sandal
#

yeah dpcs are only really applicable to stuff running in-kernel imo

#

so if youre doing microkernel stuff then it probably isnt as applicable

weary jetty
#

I'm kicking off a feature completeness kick with a bunch of filesystems and fancy network things and additional architectures.

#

I can probably push Xwayland + GNOME + Firefox up a fair amount. It would probably be good to have that to demo fairly early.

fallen bobcat
#

I literally just sent a 1 character patch and didnt say anything else chad

fallen bobcat
#

my project structure is so weird zls instantly crashes now

fallen bobcat
#

zig language server

weary jetty
#

Oh yeah, LSP servers have trouble with projects that do funny things when they build.

fallen bobcat
#

i switched to zed like a week ago because it seemed to handle it better than emacs but now both dont like it

fallen bobcat
#

omfg I shouldve designed everything with cpu ids from the start ๐Ÿ˜ญ

heavy sandal
#

your own ids or the hardware ones?

fallen bobcat
#

well instead of passing around a *ke.Cpu is pass around an id now

#

so the big struct has been shattered

heavy sandal
#

oh yeah no passing around an id is way better

fallen bobcat
#

well at least it builds now, so I can get back to amd64 stuff

fallen bobcat
#

mhm moving the directory structure around a bit:
arch/ -> ISA primitives (like cpuid, table formats etc)
platform/ -> platform-specific stuff (board etc)

#

then each subsystem has its own architecture subdirectory

fallen bobcat
#

bruh gdt init not ok

heavy sandal
fallen bobcat
#

no I fixed it

heavy sandal
#

oh pog

fallen bobcat
#

i forgot to pack the struct

#

I dont get the difference between packed and extern tho

heavy sandal
#

packed is bitfields

#

extern is c abi

#

theres an open proposal to rename packed to bitpacked because that would actually make sense

fallen bobcat
#

what is attribute((packed))

#

but in zig

heavy sandal
#

align(1) after every field

fallen bobcat
#

bruh what

heavy sandal
#

theres no keyword or simple option for it

fallen bobcat
#

I think packed works tho

heavy sandal
#

packed requires it to be backed by an int

fallen bobcat
#

bruhburhbruhbruhbrub

heavy sandal
#

so if its too big or the abi cant handle the int it dies

#

what you want here is extern + manually set field alignment

fallen bobcat
#

that's ass

heavy sandal
#

for the gdt pointer anyway

#

bro its two fields

#

its fine

fallen bobcat
#

ugh

#

ok

#

gdt init... ok works now

heavy sandal
#

nice

#

byte-packed structs are def on my wishlist for zig

#

esp once they rename the current packed to bitpacked (which was accepted at some point) so the term wont be as overloaded

fallen bobcat
#

mhm do I do zig comptime magic to generate the interrupt handlers

heavy sandal
#

i used to do that

#

swapped to doing it with asm macros in an asm file just because it was a bit more readable

fallen bobcat
#

idk GAS macros

heavy sandal
#

i do still generate my isr_common with comptime tho

fallen bobcat
#

like in nasm i can just do:

%assign i 32
%rep 224
    INTERRUPT_NOERR i
%assign i i+1
%endrep
#

idk if gas lets me do that

heavy sandal
#

it does but its a bit more fiddly

#

so before i learned how to do that i used comptimePrint etc to generate asm for the handlers at comptime

fallen bobcat
#
.rept 224
INTERRUPT_NOERR %32+\+
.endr

.global __interrupt_vectors
__interrupt_vectors:
.rept 256
.quad isr\()\+
.endr

``` lmao
#

amazing syntax as always

heavy sandal
#

yeah

fallen bobcat
#

lesgo we have interrupts now

heavy sandal
#

pog

fallen bobcat
#

tfw i have fucking 600 lines log ring but no interrupts nooo

heavy sandal
#

lmao

#

oh btw idk if you plan to do aarch64 but if you are, what interrupt controller(s) are you planning on supporting?

fallen bobcat
#

I have no idea

#

I know nothing about arm

#

I know there's a thing called the GIC tho

heavy sandal
#

yeah

#

but theres five different versions and for the most part they all behave very different

fallen bobcat
#

i do have a raspi, could be cool to target it even tho it's not well documented

#

or I could get one of those open source boards

heavy sandal
#

apart from 4 which is back-compatible with 3

#

and i think 3 is sorta back-compatible with 2?

fallen bobcat
heavy sandal
#

but afaik 5 doesnt have any back compat and noone talks about 1 lmao

heavy sandal
#

i think mine is one of if not the only hobby os to have support for MSIs on the gic v3/4

#

so i got you covered there for the knowledge lmao

fallen bobcat
#

most driver stuff goes completely over my head tbh

#

im not a big hardware guy

heavy sandal
#

mhm

#

normally i like driver stuff tbh

#

but that interrupt controller is ass

fallen bobcat
#

no ascii art

#

worst kernel ever

heavy sandal
#

i dont have ascii art either

fallen bobcat
#

i think this is enough info for now but eventually it'll call into the generic panic thing

#

which shows current thread, ipl, etc

heavy sandal
#

mhm

heavy sandal
fallen bobcat
#

I just realized I cant do the addrspace(.gs) trick

#

very sad

#

since for zig *T != *addrspace(.gs) T so things like self functions dont work

fallen bobcat
#

ugh I think I need a self pointer or rdgsbase

slate vessel
#

printk_ringbuffer documentation was an interesting read

fallen bobcat
#

it's not up to date tho

#

which is why i sent a patch

fallen bobcat
slate vessel
#

yes

fallen bobcat
#

where

slate vessel
#

I don't have it pushed yet

#

it's basically your code but c++ified

fallen bobcat
# fallen bobcat ugh I think I need a self pointer or rdgsbase

bruh ok I had to do this:

pub inline fn percpu_ptr(variable: anytype) @TypeOf(variable) {
    const offset = asm volatile ("mov %%gs:(%%rax), %[out]"
        : [out] "=r" (-> u64),
        : [self_off] "{rax}" (&cpu_self_offset),
    );

    return @ptrFromInt(offset +% @intFromPtr(variable));
}
#

no performance gain at all for using percpu stuff like that since I cant do gs loads/stores directly

#

I guess I could use rdgsbase if the machine supports it but it might just be faster to do that ^

languid canyon
#

Or did u want his one specifically

slate vessel
#

tbh I forgot you had it as well meme

languid canyon
#

๐Ÿ’€

#

Mine supports pr_cont but doesn't support 32 bit, his is the opposite

heavy sandal
#

and mine supports neither KEKW

languid canyon
#

Didn't you copy mine

#

So it should support cont if you did

heavy sandal
#

mine internally would support cont but i dont have the exposed api for it

languid canyon
#

The api is the easy part

heavy sandal
#

yeah i just never wrote it lmao

languid canyon
#

pr_cont?

slate vessel
#

yeah

heavy sandal
#

lets you extend a message

slate vessel
#

ah

heavy sandal
#

as long as its the latest written message

languid canyon
#

Print continued

slate vessel
#

yeah

#

reopen a committed reserve

#

I don't think I need that

languid canyon
#

Yeah

slate vessel
fallen bobcat
languid canyon
#

Not in zig

heavy sandal
#

which is to make the self-parameter to methods on percpu stuff anytype

#

and then itll use generics to instantiate for both gs and normal pointers

fallen bobcat
#

I literally just thought of that

#

I can make every self anytype

heavy sandal
#

the problem with that is you lose literally all lsp type hints which makes the development side a pita

#

but it does work

fallen bobcat
#

The only structure I need is spinlock

#

I think

#

Yeah no ok it's not feasible

heavy sandal
#

F

fallen bobcat
#

Linux patch merged

heavy sandal
#

๐ŸŽ‰

#

oh btw @fallen bobcat zig merged llvm backend incremental support

#

they dont have state saving yet so it only applies to if you use the --watch flag on the build process to have it watch for changes on the filesystem but it is there

languid canyon
#

is this your first linux contribution?

fallen bobcat
#

First real major project contribution

languid canyon
#

mention in your CV meme

fallen bobcat
#

lol

#

At least the patch looks bigger because another guy contributed to it

languid canyon
#

did they co-author it?

fallen bobcat
#

I asked on the netbsd IRC and they gave me stuff that was already done

weary jetty
fallen bobcat
fallen bobcat
#

Like does it make linking faster

heavy sandal
#

im not sure about linking, this was mostly the llvm emit side, but i think it will might do incremental linking too

fallen bobcat
#

Idk I think what's slow for me is linking

heavy sandal
#

mhm

#

for me its def the emit so itll help there (albeit itll help more once they get state saving)

fallen bobcat
#

Idk I'm not sure

#

The freestanding build is fast the UM one is not

heavy sandal
#

mhm

fallen bobcat
#

๐Ÿฅ€ @slate vessel

#

1:1 code rewrite for that nooo

slate vessel
#

should I add a license header thingy?

fallen bobcat
#

idk you do you but I just think it's kinda crazy you 1:1 rewrite a piece of code and add a small "based on XXX" lol

slate vessel
#

oh sorry

fallen bobcat
#

you do what you want, I know you and youre not using for commercial purposes or something

#

I dont think this counts as licensed code since its rewritten tho

slate vessel
#

I don't really know licenses

fallen bobcat
#

I just find it funny meme

slate vessel
#

I'll include a permalink

fallen bobcat
#

yeah just a link is fine

slate vessel
#

done

fallen bobcat
#

ok pmm time I think nooo

#

well not nooo, at least this gets me away from architecture stuff

slate vessel
#

what kind are you planning to make?

fallen bobcat
#

for now I will do a simple freelist but I had a plan in mind to add per-cpu lists on top of that

#

it involved having one global "bucket" freelist which is a list of lists of 64 pages each

slate vessel
#

what about a buddy :P

fallen bobcat
#

you allocate and free from buckets[0]

#

when you need to drain you shift all buckets down

#

it's basically magazines

fallen bobcat
#

and a buddy allocator sucks anyway

slate vessel
#

I like it quite a bit

heavy sandal
#

buddy is great imo

#

i use it as a vmm tho

#

not for the pmm

fallen bobcat
#

the buddy allocator in linux infamously sucks

#

if I need higher than one page i can do an llfree-like thing

slate vessel
#

don't you need to allocate more than one page frequently if the mmu doesn't support 4k pages

fallen bobcat
#

what kinda architecture doesnt support 4k pages

heavy sandal
#

yeah really

slate vessel
#

I'm not sure

#

I guessed some arm boards

heavy sandal
#

then dont worry about til you find one imo

#

i think arm requires 4k page support

fallen bobcat
heavy sandal
#

id have to double check

fallen bobcat
#

not a platform thing

heavy sandal
#

arm supports a couple different granule sizes tbf

#

as the base level

#

but i think 4k is required to be supported

slate vessel
#

good to know

heavy sandal
#

id have to double check

#

havent looked at that section of the manual in a bit

fallen bobcat
#

4kb is pretty much the standard for all archs nowadays

heavy sandal
#

yeah

fallen bobcat
#

you could argue 16k would make sense nowadays

heavy sandal
#

i would be unsurprised if windows used the 64k granule size if supported since like everything in windows's vmm uses 64k units if possible but idk

slate vessel
#

I think I've written my vmm in a way that it doesn't care if the page size is 4k or not

#

of course I haven't tested it in such a way :P

fallen bobcat
#

mhm well I need to implement my architecture abstraction first

#

I think I'm not gonna do anything fancy for now and just copy what I already ahve

fallen bobcat
#

but eventually I will move to a cursor-like API over ptes

heavy sandal
#

mines kinda meh abstraction wise but it works

#

requires the arch pte type to have an init function with a certain signature for setting up a valid pte and requires the page number to be accessible as the page field of a packed union in the addr field of the pte

fallen bobcat
#

oh fuck im gonna have to rewrite kmem

#

fun

#

I'm kinda tempted to move to a lock-free thing like mimalloc tho

#

lmao I found my old OS and it straight up gdt init... fail

pastel citrus
#

limine v2.x was beautiful

wet kernel
#

[ FATAL] GDT init... FAIL

fallen bobcat
#

when limine was actually good ๐Ÿ˜”

#

ugh I feel like the "bump alloc from largest entry" thing is so hacky

#

what if it's a bunch of small memory entries

fallen bobcat
#

idk why actually

#

it should work