in managarm-infrastructure i assume?
#Zinnia
near tartan
near tartan
dead os
grave peak
real
near tartan
i might be stupid
[ 23.019718] [ 1] thread: Forked thread 1, new ID 2, IP at 0x000000004101319F
[ 23.020710] [ 1] process: Forked process "/bin/ash", new pid 2
[ 23.021368] [ 1] syscall: User program is calling "waitpid" (42)
[ 23.022052] [ 1] syscall: User program is calling "sigsuspend" (43)
[ 23.022793] [ 1] sigsuspend: Waiting...
[ 23.023470] [ 2] vm: Page fault:
[ 23.023896] [ 2] vm: Attempted to access 0xFFFFFFFFFFFFFFFF (ip: 0xFFFFFFFFFFFFFFFF)!
[ 23.024790] [ 2] vm: - Page was not present
[ 23.025278] [ 2] vm: - Fault was caused by a read access
[ 23.025899] [ 2] vm: - Fault was caused by the user
[ 23.026458] [ 2] vm: - Fault was caused by an instruction fetch
[ 23.027136] [ 2] process: Killing PID 2
why would it jump to 0xFFFFFFFFFFFFFFFF
near tartan
maybe this is an mlibc thing?
near tartan
or abort()
wouldn't it print a message then?
near tartan
♫ 99 little bugs in the code ♫
♫ 99 little bugs ♫
♫ take one down, patch it around ♫
♫ 137 little bugs in the code ♫
i WILL be losing it
when i get back i'm going to finish the port to xbstrap
no more cursed rust builder
near tartan
we are so back
i've finally fixed the toolchain issues (partially skill issues on my end)
i'm currently moving everything over to xbstrap
near tartan
i might need some help with image building support (loopback etc)
but otherwise it's lookin good
near tartan
okay fuck it i'm already using linux abi headers might as well use the linux option
near tartan
yoooo okay everything finally builds
i also have image building set up now
so the xbstrap changes cango into main branch as soon as the xbstrap PRs are merged
uncut jackal
udrm!!
near tartan
oh yea
hoary cave
loading module at 0x0000000000000000
near tartan
loading module at 0x0000000000000000
yea that's correct
those are built in modules
so base address is 0
near tartan
more optimizations :DDD
near tartan
💔 clang-format
near tartan
jovial crypt
https://media.discordapp.net/attachments/594925688914706462/890948499380797460/m...
lmao
btw where can one make this
near tartan
search for locket gif generator
near tartan
my sanity has deteriorated even further
building rust with meson is another level of autism i didn't think was possible
fair lintel
why do you even build rust with meson lmfao
near tartan
why do you even build rust with meson lmfao
cargo crates are ultrakanker to integrate with C/C++ projects
also you need a bunch of extra flags that a makefile would do otherwise
even redox can't use cargo lol
uncut jackal
cargo crates are ultrakanker to integrate with C/C++ projects
depends on whether if you're doing a little rust with your c or a little c with your rust
and c++ is worse than c for this
a little C with your rust is wayy easier than a little rust with your C
adding rust to an existing codebase is quite hard
uncut jackal
ok cool i just wanted to put this out here to clear any confusions
uncut jackal
as a learning experience
if you want you can take over flanterm-rs
i want to maintain it later but i can't rn
and it's build script is borked as hell
it thinks it needs to rebuild every single build which is not good for reproducability
it would be a good learning experience with bindgen and stuff
near tartan
it thinks it needs to rebuild every single build which is not good for reproduca...
oof
uncut jackal
that's a me skill issue tho
and since there is no user other than me
I didn't fix it
you could make it good enough to upload to crates.io
if u want
full topaz
Didnt even know __FILE__ and such existed
storm bobcat
it's like macros but cooler
near tartan
autism
eternal wharf
are you rewriting menix in rust?
hoary cave
iirc it's a microkernel now™️
eternal wharf
minix
hoary cave
holy
near tartan
are you rewriting menix in rust?
yes
uncut jackal
wasn't menix already in rust?
uncut jackal
autism
macros ftw?
why do you need an internal module?
can't you just re-export everything and not export stuff you don't want re-exported?
near tartan
can't you just re-export everything and not export stuff you don't want re-expor...
that's the point
i reexport it so i don't have to duplicate the code lol
uncut jackal
just don't make them pub and make them pub(...)
uncut jackal
pub(crate), pub(super) etc.
i don't actually remember if it was super or something else
near tartan
let me try
uncut jackal
yea it was super
near tartan
i might have overthought it
uncut jackal
yea there's some advantage of what you overengineered but
I doubt you actually need that
near tartan
i probably dont
uncut jackal
and non-pub can be accessed by child modules iirc
near tartan
well, i want to make sure that the structs explicitly reexported are available under that name
uncut jackal
i haven't written rust in a few months tho
near tartan
basically, i want a trait or header-ish thing for architectures
for common behavior
in C i did this through a header and static_asserts
but in rust this makes little sense
uncut jackal
rust does have static asserts
near tartan
not that part
uncut jackal
so you can e.g. make sure PAGE_SIZE isn't bogus if that's what you need
near tartan
i mean, having a declaration of common behavior
like this
it's a bit cursed here because while this works, i need to always import both the impl and the trait
i'd like not to
uncut jackal
i doubt you actually need this, if init() and stuff weren't implemented it wouldn't compile
when something used init() it would be an error
near tartan
true
near tartan
it is yes
uncut jackal
are you gonna have arch singletons lmao
near tartan
no lol
they're static fns after all
i guess i wanted to make sure the functions are there and have common documentation? not sure what my motivation was
this is from my old old rust attempt from 2023
uncut jackal
what I do is just make them normal functions (not associated functions)
hmmm for documentation
near tartan
because it shows up nicely in rustdoc
uncut jackal
you could import a common markdown file with #[doc = whatever]
near tartan
real?
near tartan
interesting
uncut jackal
idk if you can like
create an doc/arch.md or whatever then import only a piece of it
if that's possible that's what you want
otherwise you would need to have separate files for each
e.g. doc/arch/early_init.md
near tartan
create an doc/arch.md or whatever then import only a piece of it
oh shit that's a thing?
literally what i need
uncut jackal
e.g. doc/arch/early_init.md
this definitely is
uncut jackal
oh shit that's a thing?
and if it's not a thing you can make a thing
proc macros ftw
just make a proc macro similar to include!() but parses markdown headers and allows you to include a section
then you can #[doc = include_section!("path/to/arch.md", "early_init")]
or you could make an attribute macro
near tartan
okay maybe a little overkill
uncut jackal
okay maybe a little overkill
yea maybe
but this is a good crate idea tbh
maybe a full blown preprocessor
uncut jackal
you know how some documentation stuff let you do SECTION:whatever ENDSECTION:whatever in comments for hiding or showing parts of the code block
we could preprocess similarly
near tartan
???? what was i thinking here
this is literally what CommonPageMap was for
why was this a different struct
near tartan
okay all that stuff is gone now
@uncut jackal would you know how i best do TLS?
in C i had a fixed size array
uncut jackal
thread local storage or transport layer security?
near tartan
the former
this might not be the smartest way
i have a box which i leak and convert to a pointer during init
uncut jackal
tbh idk lol
uncut jackal
redox isn't the best place to check how stuff is done
not because it's bad, but in my experience it isn't really easy to navigate
uncut jackal
hmm
near tartan
i mean
i could also do a per cpu allocation
as in, instead of using the id as an index, i'll just store a pointer to the struct
so i can reference it
near tartan
yea i'll do that
near tartan
brisk totem
info() is insanely UB btw
brisk totem
this, except without mut
near tartan
but then i can't modify it :(
brisk totem
you have to raise the IRQL to mess with per-cpu data correctly anyway
so you can make "raise irql" give you an "irql raised token" valid only for the lifetime of the scope which has a raised irql
and then you can define a "percpucell" which is !Send and also can be turned from &T into &mut T if you have that special token
near tartan
so you can make "raise irql" give you an "irql raised token" valid only for the ...
huh
and why do i need that
brisk totem
you need it for correctness anyway?
like you cant mess with per-cpu state unless preemption is off
near tartan
i can tho?
brisk totem
define can
near tartan
or do you mean i shouldnt
brisk totem
you cant do it in a way that preserves correctness
brisk totem
you cant touch per-cpu state with preemption on
if you do, rustc reserves the right to make your code rm -rf /
near tartan
all this needs to store is callback functions, active thread and stack pointers
brisk totem
because its a data race
this is a thing in C too i dont know why you are so surprised lol
near tartan
i've never used irqls :P
it just worked
dunno what they are
the only thing that actually wrote to the per cpu block was the scheduler
brisk totem
okay but you read from it outside of the scheduler?
near tartan
yes
brisk totem
well that is invalid
and a data race
because you could be preempted in the middle of the read
near tartan
huh
brisk totem
and then the scheduler messes with the state
brisk totem
huh
??? crazy surprising osdev knowledge: data races are a thing! and you need to turn off preemption before reading stuff that preemption writes!
near tartan
oh that's what you mean
brisk totem
yes
near tartan
u have an example?
brisk totem
uh
brisk totem
u have an example?
struct PreemptionOffToken<'a> { _p: PhantomData<&'a ()> }
struct CPUCell<T> { data: UnsafeCell<T> }
fn without_preemption<F, R>(f: F) -> R where for<'a> F: FnOnce(PreemptionOffToken<'a>) -> R {
assert!(preemption_is_on());
disable_preemption();
let v = f(PreemptionOffToken { _p: PhantomData });
enable_preemption();
v
}
impl<T> CPUCell<T> {
fn get<'a>(&'a self, tok: &'a PreemptionOffToken<'a>) -> &'a T { /* SAFETY: somoene on discord told me this is fine */ unsafe { &*self.data.get() } }
fn get_mut<'a>(&'a self, tok: &'a mut PreemptionOffToken<'a>) -> &'a mut T { unsafe { /* SAFETY: see above */ &*self.data.get() } }
}
something like this
near tartan
ah with phantomdata
near tartan
okay i think (?) i'm ready to start booting again
after trying to reconstruct my early kernel from years ago
we are so back
near tartan
getting further
near tartan
```rs
struct PreemptionOffToken<'a> { _p: PhantomData<&'a ()> }
struct CPUCell<T...
i think im starting to understand what this does? where is without_preemption supposed to come in?
is it similar to what the spin crate Mutex does?
where you do a lock() and as long as it doesn't get dropped you don't get preempted
brisk totem
the spin crate mutex doesnt do that tho?
near tartan
ah sorry i put two sentences into one
I meant you do a lock and get a context
not the preemption part
brisk totem
i think im starting to understand what this does? where is without_preemption su...
without_preemption is how you'd turn off preemption if you want to access CPUCells
near tartan
so for example I'd do
without_preemption(|x| x.get().runtime += 1);
did i get that right?
hoary cave
you'd do without_preemption(|token| cpu_cell.get_mut(token).runtime += 1); according to the code
or x for short
near tartan
that's actually a really cool thing to do
hoary cave
i did the same thing and now i can verify the ipl in PerCpu::get
but i might write this shi in c++
i dont like rust
my code is 95% ub rn lol
near tartan
my code is 95% ub rn lol
lol
magic charm
In some cases per cpu counter manipulation could be done without ipl modification
It depends on the counter and whether the arch has appropriate atomic op
near tartan
In some cases per cpu counter manipulation could be done without ipl modificatio...
yea in that specific example
i use the cpu struct to store the currently running thread, so i assume I'd have to disable preemption for the entire time i do anything with the thread
brisk totem
i did the same thing and now i can verify the ipl in PerCpu::get
that is UB
if you give out a &mut at least
that is only okay if you give out &T
brisk totem
that's actually a really cool thing to do
yeah, it's inspired by ghostcell
hoary cave
how is it ub to give out a &mut T
near tartan
isnt it ub to give out a &mut T twice
brisk totem
how is it ub to give out a &mut T
consider ```rs
raiseipl();
let a = PerCpu::get();
let b = PerCpu::get();
*a = 123; // welcome to rust UB land!
actually the UB might only be if you write to BOTH at least once
brisk totem
my code is 95% ub rn lol
yeah this is the problem with rust
the rules make it really hard to write ub-free code in a lot of cases
without putting expensive locks around everything
magic charm
i use the cpu struct to store the currently running thread, so i assume I'd have...
if you can atomically load "current cpu's thread pointer" then you needn't disable preemption
brisk totem
oh btw i have seen a new interesting way of implementing something like RCU
but not really
magic charm
on amd64 e.g. a %gs-relative mov with offsetof(struct cpu, thread); on aarch64, an x18 relative load; on risc-v, a tp relative load
brisk totem
oh btw i have seen a new interesting way of implementing something like RCU
struct GlobalState {
value: AtomicPtr<T>,
lock: Mutex,
}
struct State {
last_known: Ref<T>,
}
fn load(s: &mut State, p: &GlobalState) {
if p.value.load_relaxed() != s.last_known.ptr() {
p.lock.lock();
s.last_known = Ref::from_ptr(p.value.load_relaxed());
p.lock.unlock();
}
s.last_known.clone()
}
roughly
hoary cave
the rules make it really hard to write ub-free code in a lot of cases
yeah which is the reason why i realized i should give up and use c++ instead
lets me write cool stuff like that but with less implicit ub
near tartan
would something like this work too?
//Pseudo
struct Cpu { ... }
trait Preemptible<T> where T: Drop { ... }
impl Drop for Cpu { ... }
static FOO: Preemptible<Cpu>;
fn do_stuff() {
let cpu = FOO.get();
cpu.thread = next_thread;
}
so now i give you one shot to guess why im rewriting shkwve in C++
hoary cave
brisk totem
would something like this work too?
```rust
//Pseudo
struct Cpu { ... }
trait P...
T: Drop is a meaningless bound
brisk totem
do you want to express "has nontrivial drop glue"?
near tartan
i guess
hoary cave
wtf is Preemptible
near tartan
hm
hoary cave
would Preemptible::get make sure u can access it without being preempted or what
near tartan
i'd prefer the way mutex acquiring is done
hoary cave
in which case just have a without_preemption
near tartan
as in, the preemption is disabled until the thing is dropped
brisk totem
yeah that works too i think?
near tartan
because otherwise i'd be writing functions that consist of only lambdas
brisk totem
also thats not a huge problem
near tartan
i dont like it 
brisk totem
struct PreemptionOffToken { _p: () }
impl Drop for PreemptionOffToken {
fn drop(&mut self) { enable_preemption(); }
}
impl PreemptionOffToken {
pub fn get() -> PreemptionOffToken { assert!(preemption_is_on()); disable_preemption(); PreemptionOffToken { _p: () } }
}
cpucell remains as before
note that that assert is required for UB-free operation
near tartan
thank you
brisk totem
on amd64 e.g. a %gs-relative mov with offsetof(struct cpu, thread); on aarch64, ...
you could also just put the current thread pointer in fs/gs (x86), x18/tpidr_el1 (arm), tp (riscv)
near tartan
on risc-v, isn't that what sscratch is for?
brisk totem
saving stuff after exceptions
because you need at least one spare GPR
the x86 solution is TSS
the arm solution is letting you switch stacks
the riscv solution is to give you a special csr
near tartan
speaking of, is R/W on a CSR slower than a normal register access?
same question with MSRs
hoary cave
yesn't
on x86 some MSRs are serializing some aren't
similar story on RISC-V probably
brisk totem
on x86 some MSRs are serializing some aren't
i think all MSRs are serializing?
hoary cave
i'm 99% sure that TSC deadline isn't
brisk totem
thats an msr?
hoary cave
yeah?
brisk totem
wtf
hoary cave
isnt it?
brisk totem
i thought its mmio
hoary cave
you write some value to the APIC LVT register
but i am pretty sure you poke an MSR to reconfigure it
brisk totem
ah yeah but you dont reconfigure that often
hoary cave
you do poke an MSR to reconfigure it
reconfigure = change the deadline
and i'm pretty sure that MSR does not serialize
fiery marlin
relevant material from the intel spec if you're interested
near tartan
the rules make it really hard to write ub-free code in a lot of cases
im feeling this so much right now
it's a huge pain
oh shit
i also have to port the standard library for userspace, don't i
i hate everything
maybe i need to overthink my system architecture
hm
what about a microkernel with one big userspace component
hoary cave
i also have to port the standard library for userspace, don't i
you can if you really want to
or you can write your own wrappers
but if you want to use all the cool crates and already built tools then yeah, you need std
good thing is that if you plan to be posix/have posix server then your life is significantly easier
near tartan
good thing is that if you plan to be posix/have posix server then your life is s...
yes that's the idea
near tartan
but if you want to use all the cool crates and already built tools then yeah, yo...
exactly
kinda defeats the point
i think this is a sign to just stick to C
i already have that ported and with userspace
indecisiveness is a curse
i don't want to pour in infinite amounts of time and effort
i just want to get it working :P
hoary cave
good mindset
near tartan
it's just a hobby project after all
good thing i didn't commit anything yet
i will switch from cmake to meson though
working with other projects made me like it more
hoary cave
yea meson is based af
near tartan
i love it
meanwhile cmake makes you modify internal variables
i also managed to make some projects unable to build with Unix Makefiles
brisk totem
lmao
brisk totem
lol
but on the other hand
meson only accepts their author's ideas of how a build system should work
brisk totem
everything lol
brisk totem
cmake lets you mess with internal variables at least
in meson, there is the author's opinions, and there are your opinions which are definitely exactly the same as the author's
like for example
you dont need functions
right?
the meson authors think you dont so you will not have them
hoary cave
you can get away without functions just fine
is it annoying? yes
but is it a dealbreaker? absolutely no
brisk totem
the point is, the same pattern extends to all of meson
the authors decided you don't need to do something
so you don't
near tartan
my scuffed ass go-based build system is great
brisk totem
<:chad:815144781842743334>
its now in its second generation!
hoary cave
cmake is the thing you want for cursed setups
hoary cave
literally
brisk totem
the most cursed part of my builds is -T linker.ld
you use -T linker.ld
i use -T obj/link1-nhkru934bvi7va5rgg2g1dusjju52rfe3kme0quv53lha.lds
we are not the same
near tartan
i mean before in cmake i had a whole ass option/dependency tracking function
brisk totem
best linker script ever!
dont mind all of the spaces that's a side effect of go's templating engine
brisk totem
<:KEKW:913708372329644042> <:KEKW:913708372329644042> <:KEKW:913708372329644042>...
are you laughing at my use of a template engine to make my linker script????
hoary cave
why would u do that even
brisk totem
why would u do that even
so i can generate the linker script programatically?
brisk totem
because a bunch of it depends on config options lol
hoary cave
cursed
brisk totem
nah
hoary cave
yuh
brisk totem
for example the load base
hoary cave
but whatever floats ur boat
brisk totem
is a config option
brisk totem
no thats cringe
hoary cave
i mean it is
brisk totem
config option is better
hoary cave
but whatever floats ur boat
.
brisk totem
i do
near tartan
are you laughing at my use of a template engine to make my linker script????
you do what
server side linker script rendering
brisk totem
you do what
brisk totem
thats a thing in linker scripts?
brisk totem
mold doesnt have linker scripts tho
near tartan
it does
near tartan
just very rudimentary support
brisk totem
ah i see
near tartan
it doesn't support most features
near tartan
anyway i hardcode ld.lld
based
brisk totem
it works
near tartan
why is that a dealbreaker lol
near tartan
fair
uncut jackal
the authors decided you don't need to do something
the authors decided I can't control environment variables that meson passes to tests
the authors decided I replace a shared library's runpath, I can only append
uncut jackal
the authors decided I can't control environment variables that meson passes to t...
I don't want it to pass LD_LIBRARY_PATH
if i set it myself, it prepends it's own entries
if I use environment() and unset() it, meson errors and says it can't be unset
they literally made it impossible to unset i don't get it
ig they don't want dynamic linker tests
hoary cave
i think its just programs that meson executes for u
if it exists with non-zero it means the test failed
and it prints stderr when it fails
i think that's it at least
vast lotus
for example the load base
you don't need to generate your linker script to be able to set this from a config option:
// config.S
.globl __load_base
.set __load_base, CONFIG_LOAD_BASE```
```ld
. = __load_base;
yeah, a symbol defined with .set doesn't belong to a section either so you don't have to worry about relocation etc
or ofc you can just run your compiler's preprocessor on the linker script
brisk totem
you don't need to generate your linker script to be able to set this from a conf...
ok that is cursed lmao
brisk totem
or ofc you can just run your compiler's preprocessor on the linker script
yeah, or i can run it through go text/template
grave peak
why did it time out entering acpi mode
also i guess u dont call uacpi_namespace_initialize?
grave peak
u should
near tartan
when
grave peak
after load
and also finalize_gpe_initialization
btw is it expected that it times out?
near tartan
not really
grave peak
is you impl for io in/out correct
near tartan
it doesn't in qemu
near tartan
is you impl for io in/out correct
probably not lol
grave peak
we could take a look at the fadt dump but yeah
near tartan
grave peak
lol
distant cypress
tbh it's non-obvious
grave peak
yeah
distant cypress
like it's possible to approach this and think that the author of uACPI got lazy and decided to write io instead of mmio
grave peak
there should be a comment
distant cypress
is this for uDRM development?
near tartan
it's more or less a prerequisite
i'll be able to focus on udrm until at least the start of march
distant cypress
grave peak
nice
near tartan
near tartan
POV: you're getting fucking destroyed
near tartan
I actually pulled through and got somewhat far with the microkernel rewrite
tomorrow is ELF loading time
then i should already be in user space
grave peak
Nice
near tartan
@grave peak is there already a rust kernel with uacpi support?
hoary cave
i am not aware of any, but maybe i missed something cool :^)
grave peak
@idle flower's WIP kernel i think
idle flower
Soon TM
near tartan
Soon TM
how far is it
because menix might be the first one to run uacpi-rs then
i'm in user space now and my servers can communicate
idk if i want to put uacpi in user mode
idle flower
Still writing code for the kernel
With my current progress it might take a few months
idle flower
because menix might be the first one to run uacpi-rs then <:meme:575445094589661...
Likely
storm bobcat
idk if i want to put uacpi in user mode
I don't see why you wouldn't
near tartan
I don't see why you wouldn't
i may need firmware configuration before user mode
like madt, hpet, etc
near tartan
still
i need the tables before user mode
sure, i can delegate power management and so on to user space, but there are some parts that i need in the kernel
idle flower
I will have one in kernel and one in userspace, the kernel one will only supply tables for Numa stuff, ioapic, hpet and the userspace one will actually run aml and be part of bus/device enumeration
near tartan
are you going to implement the bare bones mode as a feature?
grave peak
i need the tables before user mode
UACPI_BAREBONES_MODE in kernel, and the full thing in userspace
idle flower
are you going to implement the bare bones mode as a feature?
Yes as a feature flag
grave peak
it's not even a thing in master yet
near tartan
merge when
grave peak
this week
near tartan
based
grave peak
but your kernel is rust as well right
near tartan
yes
grave peak
so for you it's soon ™️
near tartan
i mean i can probably PR some changes in if @idle flower doesn't have the time
grave peak
idle flower
I am still a bit stuck on type.h, once that's cleared the most stuff should be easy
Except handlers
near tartan
what exactly?
idle flower
Object stuff like create, assign
near tartan
ah
idle flower
And if I should make certain conversions infallible either with ub or panic
For enums
near tartan
pls no ub
idle flower
That's what I thought
It would then panic if uacpi supplies invalid enum values
Like ones that aren't defined
I can push my wip to dev1.0 in a few hours
near tartan
thx
storm bobcat
UACPI_BAREBONES_MODE in kernel, and the full thing in userspace
i sitll wouldnt do that tho
importing 30k lines of code for something that can be done in 500
grave peak
it compiles out all other code
so its really 500 lines
if u have it in userspace anyway u can reuse the same submodule
near tartan
importing 30k lines of code for something that can be done in 500
wdym
hoary cave
importing 30k lines of uacpi instead of doing table enum in 500 lines urself
but as infy said
incremental compilation + lto + its all ifndef’d away
near tartan
well the crate is already there, so might as well use it lol
hoary cave
actually incremental compilation wont do shit its a different set of flags
but lto + barebones mode still
grave peak
i dont think it needs lto, literally every .c file is completely ifndef'ed
and most of table.c as well
well barring e.g. vsnprintf
hoary cave
yep that makes perfect sense
grave peak
i know i wouldnt handroll table parsing because im lazy
hoary cave
its like 50 lines of c++ with templates
not that bad
but table type definitions bleh
i hate writing struct definitions from specs
grave peak
yeah at the very least u could #include <acpi.h>
near tartan
i know i wouldnt handroll table parsing because im lazy <:trl:829316641191886888...
same
idle flower
grave peak
<@173337436989030401> https://github.com/uACPI/uacpi-rs/commit/43562dc8635672409...
Undefinded reference
idle flower
?
grave peak
AmlUndefindedReference
idle flower
where?
near tartan
<@173337436989030401> https://github.com/uACPI/uacpi-rs/commit/43562dc8635672409...
cool
@idle flower wyd in vc
idle flower
in case you have questions
near tartan
lol
idle flower
im now at version 3 on how to write pageing code
i can show you version 1, it was the reason why i needed bigger monitors
near tartan
Menix
idle flower
in a positive way?
idle flower
i can give you my pageing code if you need more confusion
near tartan
lol
i have done paging in C already
i just need to translate it to a generic interface
hoary cave
there was this one templated c++ version by fadanoid which looks cool
but im too lazy to look fo0r it
from:fadanoid gist.github.com
just earch that ig
near tartan
okay i'm puzzled
i think my linker script is correct
it's the same one from the C version
but printing them in order yields this trash
nvm i'm a brainlet
hoary cave
i know exactly what mistake you made and i dont blame you lmao
coral cliff
i know exactly what mistake you made and i dont blame you lmao
enlighten us lol
hoary cave
he was using the linker symbols as values?
i thought it was obvious enough with them being of type VirtAddr lol
modern hamlet
but printing them in order yields this trash
"called `"
yeah for those symbols you need to get their address, they aren't addresses already
hoary cave
i think he figured it out when he said “i’m a brainlet”
lmao
but i dont blame him, it may feel intuitive this way :^)
near tartan
i know exactly what mistake you made and i dont blame you lmao
xd
i had this already figured out but happily ignored it for some reason
near tartan
"called `"
yes i did exactly this and then it hit me
hoary cave
v=03 is a breakpoint
near tartan
huh
hoary cave
yeah i can see now
near tartan
what could it be triggered by
near tartan
let me try the debug build
brother what
...
😭 howwwww
also, why does this shit not call my IDT handler?
AAAAAAAAAAAAAAAAAAA
wait no
okay yea
i can ask it to do a software interrupt and it handles it
but it doesn't handle the exceptions
is this a TSS meme?
near tartan
i don't think i'm doing anything really different than my old C version
it's really weird
modern hamlet
cr2 says fffffff8002c600
maybe you're trying to write to that region
it shows it's mapped as read only
near tartan
it's part of rodata
modern hamlet
whats the instruction at that rip
near tartan
hold on i did a rebuild, let me update the rip
uh
it jumped to the stack it seems 🫠
okay let me just save some stuff
this is the mapping that limine establishes
oh there are actually some differences
i gotta cross reference with the c version
what's the A in info tlb
rain oasis
i think accessed
eternal wharf
brother what
the humble 0xCC opcode
modern hamlet
the humble 0xCC opcode
where do you see that
near tartan
int 3
eternal wharf
my mind
near tartan
but uh
modern hamlet
oh i thought you meant that that thread ran the 0xcc opcode
near tartan
what the shit is happening
eternal wharf
oh i thought you meant that that thread ran the 0xcc opcode
i mean that'd be the source of the breakpoint exception
eternal wharf
what the shit is happening
instruction fetch from present page
near tartan
but tlb says it can :(
maybe i fucked up the previous levels
i probably did
actually, how do you have to map the previous levels
like, what flags do they get
eternal wharf
usually just present + write
near tartan
i do present + write + (user)
eternal wharf
oh yeah also works
eternal wharf
this is what you get for rewriting
near tartan
eternal wharf
can you show the code mayhaps?
near tartan
which part do you wanna see?
eternal wharf
the page table stuff
brisk totem
whats the addr2line of that fault rip
near tartan
this
eternal wharf
hmm off by 4k? comparing the limine mappings to your mappings you start mapping stuff at VA 0x...1000 and limine starts at 0x...0000
brisk totem
ah lol
near tartan
broooooo
mfwww
yea i think that's the problem
fml
my mapping calc is just broken
ah that's also why it can't call the isr
eternal wharf
calc is slang for calculator for those just joining the stream
eternal wharf
my mapping calc is just broken
oh offset does not count in the phdr segment
since it's after + SIZEOF_HEADERS
somber solar
Is menix being rewritten in rust now
near tartan
yes
somber solar
near tartan
i'm having a mental breakdown rn trying to figure out what the correct logic for the calc is
eternal wharf
offset = 0xffffffff80000000 then it's correct?
eternal wharf
me when i said that it's due to the headers
eternal wharf
progress
near tartan
riveting
okay so it first faults exactly after writing to cr3
ah yes obviously
that's the second fault address
qemu faults so hard that it resets everything to limine tables???
this is probably an actual qemu bug
near tartan
that's funny tho
eternal wharf
that's probably uefi's doing?
near tartan
idk
ah yea you're right
limine has a 0 idt
i am going to push this now, but i have 0 clue why it's page faulting
the address it tries to access is regular code and is mapped according to qemu
NOOOOOOOOOOO OMFG
my generic code does if !Exec { flags |= NX }
okay we are back
it works again
hoary cave
my generic code does `if !Exec { flags |= NX }`
that sounds ok tho
near tartan
that sounds ok tho
it does until it maps all higher levels as NX 
near tartan
okay we're in user mode again
so about the same state minus all the drivers and uacpi
i should start working on the posix server
idle flower
About that...
near tartan
grave peak
not printing addresses as 0x, upper hex, and padded with zeroes to 8 chars is punishable by law
grave peak
those are literally physical 💀
near tartan
yes? that's what i said
grave peak
lol
near tartan
especially since it's padded
near tartan
i prefer lower hex because i can see where the letters are :3
warm mortar
so you don't see where the letters are in upper hex?
so you're half blind?
/s
near tartan
Is there a more elegant way of storing percpu storage than this shit
modern hamlet
what is this
somber solar
yes please give me Mutex<Vec<Box<>>> of something
they have played us for absolute fools
somber solar
Is there a more elegant way of storing percpu storage than this shit
why do you need a mutex on percpu data?
near tartan
why do you need a mutex on percpu data?
static mutable data
@pine rock this is what i'm doing atm
pine rock
ough
let me check what i do
well i also enable OXFXSR and OSXMMEXCPT
i check my feature mask against cpuid 0xd ecx 0 and 0xd ecx 1 as well, although idk if you're doing that somewhere else
pine rock
heres my entire implementation near enough
actually just take the link instead lol https://github.com/apache-hb/BezOS/blob/master/sources/kernel/src/xsave.cpp
linux does some extra stuff with ecx > 2 leafs in cpuid but i think that can be skipped unless you want to use compacted xsave
oh yeah the xsave bit in cpuid isnt set before you set osxsave in cr4
so your cpuid query is stale afaict
pine rock
oh yeah the xsave bit in cpuid isnt set before you set osxsave in cr4
actually scratch that
near tartan
linux does some extra stuff with ecx > 2 leafs in cpuid but i think that can be ...
yea i dont care about that tbh
i just get the total size and use that
pine rock
yeah i'd guess that you're just not setting all the cr4 flags then
pine rock
your cpuid macro is fucked i guess
pine rock
pine rock
incredible
near tartan
Is there a more elegant way of storing percpu storage than this shit
coming back to this
how does everyone else do per cpu storage
pine rock
i have a PT_NOLOAD section that i put percpu stuff into at link time then use that to fill a per cpu structure and put it into %gs
near tartan
so you have a fixed amout of cpus?
pine rock
no i allocate one per cpu area per cpu core lazily during smp startup
pine rock
probably yes
pine rock
you can use tls if you want but then you're stuck with fsbase because thats the abi
near tartan
oh no i don't want to use elf tls
i just don't know how to store it properly in code
as in, i probably want a way to access the data globally, right?
while at the same time being accessible by individual cores
pine rock
inline asm to do gs relative loads is the normal way
i dont have global access and havent found that to be an issue yet
pine rock
just have a vec of pointers to percpu storage if you really need it
near tartan
but how would i do e.g. thread migration
pine rock
abusing queues probably
near tartan
i could make a submission queue that idle cpus can check and if it's viable to migrate then it will do it that way
idle flower
Is there a more elegant way of storing percpu storage than this shit
Zst struct with deref impl that uses gs as a ptr
Then instantiate that struct as const and deref it when needing to access it
Can send you my code after work
near tartan
fiery marlin
as in, i probably want a way to access the data globally, right?
imo most of it doesnt need to be globally accessible, an exception being a way to run a particular function on another cpu (with an argument or two).
near tartan
imo most of it doesnt need to be globally accessible, an exception being a way t...
true, i don't actually think i have a use for globally accessible data
near tartan
i hate my brain
every time i'm "rewriting" this shit i just want to go back to C 😭
just one more rewrite bro
@brisk totem opinion
i do have to rewrite my arch stuff to be more generic
like vmm
idle flower
i feel like i've royally fucked up the base design of the C code base
Then it's a good thing you use rust now
near tartan
same thing with rust
why can't rust be more like C in terms of stability 😭
one of the goals is to make something that's small in binary size
and modular
but rust kinda forces me to have neither
fucking hell
idle flower
Rust without std has large binaries?
idle flower
Do you do release build?
near tartan
yes
idle flower
What symbols?
idle flower
What's their purpose?
idle flower
But a kernel should be executable not dylib
idle flower
Just don't have kernel modules
idle flower
Microkernel ftw
near tartan
i mean, my only real goal is to have openrc + weston running
then i can die happy
openrc already half works
but that's mostly because my vfs impl is trash
somber solar
rewrite menix in c++
brisk totem
because it lets you write a much nicer print function, and also gives you namespaces
near tartan
hm
near tartan
are you doing rust?
i was trying to do rust
brisk totem
lol
brisk totem
is it currently C?
somber solar
C is just too good
near tartan
yes
brisk totem
ah
near tartan
C23
somber solar
even better
brisk totem
personally i prefer clang23 :^)
near tartan
brisk totem
(i.e. c23 + [[clang::overloadable]])
near tartan
loll
somber solar
(i.e. c23 + [[clang::overloadable]])
that's just c+
brisk totem
overloadable is just too good
near tartan
hm
i never really thought about using c++
i would ignore the entirety of the STL anyways
brisk totem
yeah
somber solar
i never really thought about using c++
nice thing is that you can choose what you want to use from c++
brisk totem
yeah
somber solar
and write c code with some c++ features
fickle elbow
because it lets you write a much nicer print function, and also gives you namesp...
Doesn't rust have namespaces via mod
brisk totem
Doesn't rust have namespaces via mod
yes that was vs C not vs rust
near tartan
my goals with menix are
- modular
- compact (both source/binary)
- easily portable
- async IO
brisk totem
C async is somewhat scuffed
near tartan
it is
brisk totem
but its doable