spec says
#Nyaux
surreal path
13th bit
Size:
• This bit is a 0 to indicate that the main counter is 32 bits wide (and
cannot operate in 64-bit mode).
• This bit is a 1 to indicate that the main counter is 64 bits wide (although
kind root
Rust crate skill issue
surreal path
Probably your bug
how
kind root
I mean idk how u get that field
surreal path
fn init_lapic(&mut self, e: &mut ACPIMANAGER) {
let addr = rdmsr(0x1b);
self.lapic_addr = addr & 0xfffff000;
println!("addr of lapic for cpu: {:#x}", self.lapic_addr);
unsafe {
core::arch::asm!(
"mov rax, {0}",
"mov cr8, rax",
const 0,
out("rax") _,
);
let q = HpetInfo::new(&e.0).unwrap();
let mut it = (q.base_address + HDDM_OFFSET.get_response().unwrap().offset() as usize) as u64;
if it & (1 << 13) != 0
{
println!("Capable");
}
else {
println!("nope");
println!("{:#b}", it);
}
};
}
bro
the config register
is at offset 0
kind root
Wtf is APICMANAGER
surreal path
lets not talk about that
tawdry mirage
the acpi manager
kind root
I mean idk what it has at index 0
finite summit
nyaux acpi interpreter
*aml
kind root
Id love to see that
surreal path
I mean idk what it has at index 0
this is what the register looks like
COUNT_SIZE_CAP
is what im looking for
to be 1
which it isnt???
kind root
Yes
surreal path
thats not supposed to happen
it means the hpet is 32 bit
and qemu has a 64 bit hpet
so wtf
000-007h General Capabilities and ID Register
surreal path
using the acpi crate
which gives me the address to the hpet
and there is data there
kind root
Maybe the way you're using the crate is wrong
surreal path
i read the documentation
surreal path
kk
bro come on
they want me to use hpetinfo
not
the actual fucking table
wt
wtf
rust devs omg
kind root
Yeah no idea
tawdry mirage
what address do you get for the hpet itself
surreal path
what address do you get for the hpet itself
with hpetinfo
sec
this one @tawdry mirage
physical address of course
molten grotto
that's correct at least
surreal path
yea
so wtf
ill push the changes so you can also take a look
pushed
please someone hlep
😭
surreal path
:(
surreal path
@molten grotto can i at least use your uacpi rs thing if you can implment scanning tables for me pretty please
cause currently you cannot scan tables
im kinda desperate
molten grotto
please someone hlep
you are and'ing the hpet base address
surreal path
yep
buts its okay
we learn through this
we all started as idiots
lets be honest
@kind root we learn through this
andddd a page fault
guessing cause mmio isnt mapped in the hhdm right qwinci?
kind root
yes
surreal path
how do i map it
kind root
<@353593948523986945> we learn through this
I was saying yes to this
I dont actually know
It should be under 4g
surreal path
It should be under 4g
yea so wtf
molten grotto
guessing cause mmio isnt mapped in the hhdm right qwinci?
didn't you do that
surreal path
didn't you do that
yea
molten grotto
it looks like the memory map doesn't contain all the regions so if you want to map everything just find the highest address in there
surreal path
it looks like the memory map doesn't contain all the regions so if you want to m...
wha
i dont understand
flat nymph
It should be under 4g
Not always (?)
kind root
On qemu
molten grotto
yes because its likely not contained within the memory map
surreal path
so how do i map it
molten grotto
either you get the highest base + length from the memory map and then map that much to the hhdm or alternatively you map the devices separately
flat nymph
Doesn't uACPI request memory maps?
molten grotto
either you get the highest base + length from the memory map and then map that m...
and for the first option doing it with 4kb pages is bad, its going to take ages to do and take a ton of memory
surreal path
how to map the devices separately
surreal path
how to map the devices separately
im unsure how to do that
molten grotto
you just map them before the first time you access them to somewhere
flat nymph
I have vmem in my kernel for everything
kind root
qemu with ovmf has put the nvme bar above 4gb
Were talking about hpet but yes
molten grotto
you just map them before the first time you access them to somewhere
either to the hhdm or to a separate virtual memory allocated specifically for the device
surreal path
either to the hhdm or to a separate virtual memory allocated specifically for th...
okay ill just map it to the hhdm
simple
done
surreal path
it works now yayyyy
QWINCI I WILL MAKE YOU A SHRINE IN MY OS
REAL
FOR THE HELP YOU HAVE PROVIDED ME
YOU ARE SO KIND
OMG
enabled the hpet
😎
now i need to figure out calibration math
uhhhhh
fuck
molten grotto
at least there is the speed readable from the registers which is nice
just that its in femtoseconds or whatever
surreal path
i feel like this is wrong
guys is this wrong
or is this accurate
im unsure
stupid fucking timer
// unmasked, periodic, interrupt 34
// (1 << 17) sets to periodic
// read sdm for more info
self.write_lapic_register(0x320, 34 | (0 << 16) | (1 << 17));
i literarly
wrote to it
bro
BRO
DUMB AH
FUCKING
LAPIC
I HATE THIS LAPIC AH
RAHHH
// 0x100 enables the interrupt, 33 is the interrupt number for a surprious interrupt
self.write_lapic_register(0xf0, 0x100 | 33);
// divide by 4
self.write_lapic_register(0x3e0, 1);
// one shot timer, unmasked on interrupt 34
// 1 << 16 masks the timer
self.write_lapic_register(0x320, 34 | (1 << 16));
// calibrate the lapic, set the inital count
self.write_lapic_register(0x380, 0xffffffff);
self.ksleep(10);
let mut lapic_ticks_per_10ms = self.read_lapic_register(0x390);
lapic_ticks_per_10ms = 0xffffffff - lapic_ticks_per_10ms;
println!("lapic ticks per 10 ms {}", lapic_ticks_per_10ms);
self.write_lapic_register(0x380, lapic_ticks_per_10ms);
// unmasked, periodic, interrupt 34
// (1 << 17) sets to periodic
// read sdm for more info
self.write_lapic_register(0x320, 34 | (0 << 16) | (1 << 17));
this is literarly all i fucking do
and yet
it doesnt work
IT DOESNT WRITE TO THE REGISTERS WHY TF
desert haven
what does write_lapic_register look like?
surreal path
what does `write_lapic_register` look like?
fn write_lapic_register(&self, reg: u64, val: u64)
{
unsafe {
*((self.lapic_addr + reg) as *mut u64) = val;
}
}
me when rust doesnt listen to me for the billionth time
thorn bramble
where volatile
surreal path
where volatile
bru
using volatile doesnt solve it
ITS STILL NOT WRITING TO THE REGISTERS RAHHHHH
kind root
No idea
surreal path
😔
tardy hull
Meow meow meow :3
surreal path
btw qwinci are you still working on those uacpi-rs bindings, if so could you put scanning for tables on top of the priority list. this acpi crate is really fucking weird and i dont want to keep using it
i really want to use uacpi
but the lack of functionality of the bindings atm stops me from using it
surreal path
its not writing to the registers
debugging further
still cannot find the source of the issue atm*
im unsure why
i will step through the lapic init function and see
debugging more
thorn bramble
ITS STILL NOT WRITING TO THE REGISTERS RAHHHHH
-trace
i wonder if you can trace (l)apic
-trace apic_mem*
that will print all memory accesses to any apic in the system
surreal path
that will print all memory accesses to any apic in the system
its not writing
at all
apic_mem_readl 0xf0 = 0x000000ff
apic_mem_writel 0xf0 = 0x000001ff
apic_mem_writel 0x350 = 0x00008700
apic_mem_writel 0x360 = 0x00008400
apic_mem_writel 0x300 = 0x000c4500
apic_mem_writel 0x300 = 0x000c4610
apic_mem_readl 0x30 = 0x00050014
these only show up with limine boot
not when in the kernel
thorn bramble
well then u did something wrong
lol
whats your "lapic base"
sorry lapic_addr
print that bitch
surreal path
print that bitch
thats the virtual address of the lapic base
in the hhdm
i manually mapped it
thorn bramble
it looks ok
surreal path
let addr = rdmsr(0x1b);
self.lapic_addr = (addr & 0xfffff000) + HDDM_OFFSET.get_response().unwrap().offset();
what i do
thorn bramble
assuming hhdm offset is 0xffff800000000000
surreal path
yea
unsafe {cur_pagemap.as_mut().unwrap().map(self.lapic_addr, addr & 0xffff000, VMMFlags::KTWRITEALLOWED.bits() | VMMFlags::KTPRESENT.bits()).unwrap()};
this is how i manually map it
surreal path
BRO
ONE F
still didnt solve it tho even after readding the one f
still not writing 😭
surreal path
cause
thorn bramble
just map first 4GB
surreal path
its not in the memory map
thorn bramble
- any additional usable entries
above 4GB
literally what limine does for you already
so just follow that
its good
surreal path
how do i do that even
thorn bramble
you... map all the memory from 0...4GB
surreal path
okay sce
thorn bramble
and then you loop over your memory map
and if any usable entries are above 4GB
you map them too
surreal path
4gib or 4gb
thorn bramble
in the hhdm
1024*1024*1024*1024*4
wait i think i might be dumb
yeah 1 1024 too many
basically 0x100000000
desert haven
its just 3
surreal path
basically 0x100000000
0x100000000
okay
lets divide that by 4096 so i go over each page
0x100000
okay
surreal path
lmao
thorn bramble
bro was about to whip out the let mut i = 0; while i < 0x100000000 { ... }
if you wanted to you could probably use 2MB/1GB pages so mapping it all isnt dogshit slow
but first get that working
surreal path
for i in (0..0x100000000).step_by(4096)
{
q.map(
HDDM_OFFSET.get_response().unwrap().offset() + i as u64,
i as u64,
VMMFlags::KTPRESENT.bits() | VMMFlags::KTWRITEALLOWED.bits()
).unwrap()
hhdm_pages += 1;
}
it didnt solve it
lol
STILL
no write
thorn bramble
well something is Properly Fucked
kind root
Nyaux try not to get stuck on random shit every day impossible challenge
surreal path
Nyaux try not to get stuck on random shit every day impossible challenge
💀
god just hates me
to be fair
molten grotto
btw qwinci are you still working on those uacpi-rs bindings, if so could you put...
fair, I can add that and ig re-export the tables from uacpi-sys
surreal path
fair, I can add that and ig re-export the tables from uacpi-sys
thank you
WHY WONT IT WRITE TO THE LAPIC
RAHHHHH
flat nymph
Don't you need to do writes as 32 bit ints? (May be not)
surreal path
Don't you need to do writes as 32 bit ints? (May be not)
no?
surreal path
the registers are 32-bit wide
oh
flat nymph
Don't you need to do writes as 32 bit ints? (May be not)
That's what I'm doing in my kernel at least
surreal path
the registers are 32-bit wide
its still a *mut u64 tho right?
molten grotto
no
flat nymph
It's the same as with hpet
surreal path
wait no
molten grotto
it would be *mut u32
molten grotto
thank you
now its there, it might be slightly inconvenient to use because of the re-exported tables and whatever but I don't want to spend the whole day writing nice accessor functions for the fields within the tables
surreal path
LOL
01a2
lmao
loooool
yea i dont know rust macros
help
i cannot figure out this
macro_rules! exception_function_no_error {
($code:expr, $handler:ident, $meow:tt) => {
#[naked]
extern "C" fn $handler() {
unsafe {
core::arch::asm!(
"push 0x0",
"push rax",
"push rbx",
"push rcx",
"push rdx",
"push rsi",
"push rdi",
"push rbp",
"push r8",
"push r9",
"push r10",
"push r11",
"push r12",
"push r13",
"push r14",
"push r15",
"push {0}",
"mov rdi, rsp",
"call {1}",
"add rsp, 8",
"mov rsp, rdi",
"pop r15",
"pop r14",
"pop r13",
"pop r12",
"pop r11",
"pop r10",
"pop r9",
"pop r8",
"pop rbp",
"pop rdi",
"pop rsi",
"pop rdx",
"pop rcx",
"pop rbx",
"pop rax",
"iretq",
const $code,
sym $meow,
options(noreturn)
);
};
}
};
}
im trying to take in
the function
and get the symbol
but it doesnt work
:c
molten grotto
```rs
macro_rules! exception_function_no_error {
($code:expr, $handler:ident...
because tt is a token? you want ident
surreal path
because tt is a token? you want ident
still having a 0xd general protection fault
e=01a2
?????
wtf
i dont know whats going on
help why isnt it working
molten grotto
debugger
surreal path
right
kind root
now its there, it might be slightly inconvenient to use because of the re-export...
What do you mean by re exported tables?
And thanks for your work btw
molten grotto
as in re-export bindgen generated tables
kind root
Ah
molten grotto
Ah
though ig you could also just add uacpi-sys to your project along with uacpi rs so then you could use them directly from there (the enum names and whatever are annoying though because they are very long, I re-created some of them as constants but not all)
because it prefixes the c enum value name with the enum name itself so its eg. acpi_madt_entry_type_ACPI_MADT_ENTRY_TYPE_LAPIC
surreal path
how can i look at the idt with gdb
is there a way
i cant breakpoint at the idt stub for some reason
molten grotto
did you try to breakpoint at the function by name
kind root
because it prefixes the c enum value name with the enum name itself so its eg. `...
Ooh thats very annoying
kind root
though ig you could also just add uacpi-sys to your project along with uacpi rs ...
What is uacpi sys?
molten grotto
now that I searched for that apparently there is a bindgen option to disable that lol
kind root
now that I searched for that apparently there is a bindgen option to disable tha...
Nice
molten grotto
What is uacpi sys?
a crate that contains the raw bindgen generates bindings for uacpi, its in the same repo
surreal path
did you try to breakpoint at the function by name
yep
kind root
a crate that contains the raw bindgen generates bindings for uacpi, its in the s...
Ah I see
surreal path
keeps saying its not defined
molten grotto
add #[no_mangle] to the handler
surreal path
right
surreal path
add #[no_mangle] to the handler
still keeps saying not defined
rahhh
File src/idt/mod.rs:
269: fn NyauxKT::idt::InterruptManager::start_idt();
196: fn NyauxKT::idt::div_error();
139: fn NyauxKT::idt::double_fault();
139: fn NyauxKT::idt::general_protection_fault();
117: fn NyauxKT::idt::idt_set_gate(u8, usize);
196: fn NyauxKT::idt::invalid_opcode();
139: fn NyauxKT::idt::page_fault();
101: static fn NyauxKT::idt::exception_handler(u64);
@molten grotto look at this
wtf
it isnt
in the symbols at all...
nyaux try not have something go wrong for billionth time moment
kind root
Nyaux when gdt loaded 
surreal path
:(
still cant figure it out
i think i know the issue
rust is omitting
the stub
for it
how do i stop that
:(
wide nexus
how do i stop that
scream at the compiler
molten grotto
how do i stop that
use it somewhere?
surreal path
use it somewhere?
i did
molten grotto
or maybe marking it as pub would solve it
surreal path
or maybe marking it as pub would solve it
didnt solve it
im pushing everything to github if u wanna take a look at the code
done
molten grotto
didnt solve it
you don't ever set 0x34 to anything in the idt
surreal path
you don't ever set 0x34 to anything in the idt
oh im fucking stupid
molten grotto
also in your exception stub ```x86asm
push {0}
mov rdi, rsp
call {1}
add rsp, 8
mov rsp, rdi
how?
wait
molten grotto
the function that you call is allowed to use it for whatever
and there is no reason to move anything into rsp anyway
molten grotto
ah yeah I forgot that too, you pass a physical address there
surreal path
i fixed that but
wha
#[no_mangle]
pub extern "C" fn scheduler(registers: u64)
{
let got_registers = unsafe {*(registers as *mut Registers_Exception)};
println!("tick");
let mut addr = rdmsr(0x1b);
addr = addr & 0xfffff000;
addr = addr + HDDM_OFFSET.get_response().unwrap().offset();
CPU::send_lapic_eoi(addr);
}
this is all i do
molten grotto
you don't ever discard the error code you push to the stack in the stub either
you do have a lot of bugs lol
surreal path
you don't ever discard the error code you push to the stack in the stub either
wdym
i do
add rsp, 8
oh wait
NVM
SORRY 😭
molten grotto
you discard the number but you don't discard the error at the end before iretq
the other stub likely has the same problem, you need to take it into account even when its pushed by the cpu
surreal path
okay i solved it
but
it only ticks once
:(
righg
cause i call it manually
but
why isnt the lapic firing the vector
i unmasked it?
bro???
its unmasked
molten grotto
I'd bet you aren't installing the handler for the same vector
surreal path
no its 34
molten grotto
because you are using 34 as the vector for the lapic and maybe you install 0x34
surreal path
because you are using 34 as the vector for the lapic and maybe you install 0x34
okay i fixed that but still dont work
no interrupt still
pushed on github
sti instruction does nothing
molten grotto
because your hcf disables them
surreal path
because your hcf disables them
oh
IT WORKS
OMG THANKS QWINCI AGAIN
THANKS FOR HELPING ME FIND THESE BUGS UGHHHH
kind root
istg naux is written by qwinci at this point
kind root
molten grotto
you can implement vfs on top of tar
not that its the greatest idea ever but like its an option
kind root
size
molten grotto
I actually do vfs ops on top of the literal tar file without unpacking it into anything better
cinder plinth
I actually do vfs ops on top of the literal tar file without unpacking it into a...
fun
I guess that reduces boot time?
but then file access is slower
molten grotto
yeah and finding files
surreal path
okay time to learn about vnodes again and implment vfs for nyaux once again!!!!
elder shoal
ext2 backed by ram 
surreal path
molten grotto
wouldn't probably be a terrible idea tbh
surreal path
right wheres that sun paper on vfs
molten grotto
unkempt relic
right wheres that sun paper on vfs
surreal path
thank you
molten grotto
wait the one that I posted was the vmem one 
surreal path
it was the slab
😭
i think i can do vnodes with traits
rust traits
the operations at least
every directory/file has a vnode right
yea i see
molten grotto
every open file/directory, they aren't something that's always there for all files
surreal path
every open file/directory, they aren't something that's always there for all fil...
wha???
molten grotto
it would take a ton of memory if all files on the disk would have an in-memory vnode at all times
the way that I understood that they work (and how I have implemented them) is that each vnode has a lookup function that can be used to create a vnode for the next component of the path on-demand
surreal path
the way that I understood that they work (and how I have implemented them) is th...
how would that work
molten grotto
VNode* root = root_vfs.get_root_node();
VNode* usr = root.lookup("usr");
VNode* bin = usr.lookup("bin");
VNode* bash = bin.lookup("bash");
and what would the lookup function look like
green elbow
depends on the mounted filesystem
green elbow
tmpfs is completely in RAM
surreal path
i knwo
cinder plinth
the way that I understood that they work (and how I have implemented them) is th...
yeah that's what I do too
surreal path
im looking at my old code
would ptr_to_vnode be an Option<*VNode>
if its None you create the VNODE based on the information?
or smthin
green elbow
ptr_to_vnode would still be a pointer no?
surreal path
ptr_to_vnode would still be a pointer no?
ptr to vnode sorry
But encased in an option type
surreal path
oh
cinder plinth
a tree + hashmap would work fine
hashmap for dents?
green elbow
hashmap for dents?
if it's in memory, why not?
surreal path
Option<*mut VNODE>
cinder plinth
if it's in memory, why not?
I was just wondering
maybe I should do that
would speed up lookups
molten grotto
also you likely want to allow multiple vnodes to reference the same in disk (or in ram) file/directory so the actual file/directory entry shouldn't care about what vnodes are pointing to it
cinder plinth
rn I do a linear search
green elbow
yh
unkempt relic
also you likely want to allow multiple vnodes to reference the same in disk (or ...
the vnodes have a 1:1 correspondence with e.g. UFS or ext2 inodes
cinder plinth
which is not that bad, but I guess it could be bad for large directories
surreal path
also you likely want to allow multiple vnodes to reference the same in disk (or ...
oh i see
okay how would a lookup function work
say
i had
a directory
lets call it usr
and i called .lookup
on it
what would that look like
green elbow
think about what your vnode actually stores
it'll become clear how to construct it as well
unkempt relic
and i called .lookup
scan for directory entries with the name being looked up
surreal path
think about what your vnode actually stores
stores flags and operations
cinder plinth
yeah
green elbow
right
surreal path
its just a abstraction over the overlying fs
cinder plinth
keep an opaque pointer to some fs-specific structure
green elbow
right
unkempt relic
or i should say (hopefully) the directory entry with that name (or none)
surreal path
what if a vnode doesnt exist
molten grotto
the vnodes have a 1:1 correspondence with e.g. UFS or ext2 inodes
as in there is only one vnode at a time for one disk inode? though I don't see why you couldn't have multiple vnodes pointing to the same disk inode
cinder plinth
that just sounds like a namecache?
kinda I guess
surreal path
create it?
green elbow
that just sounds like a namecache?
yes but point is lil bro here is implementing tmpfs
unkempt relic
that just sounds like a namecache?
this would be for a tmpfs, extent at the vfs layer rather than above it
surreal path
using the information of the fs node right?
green elbow
so it's all in ram
green elbow
using the information of the fs node right?
a vnode is just an abstraction, you're not really creating anything
unkempt relic
as in there is only one vnode at a time for one disk inode? though I don't see w...
the vnode is the virtual counterpart of inode, maybe there are multiple open file structures which point to it
surreal path
a vnode is just an abstraction, you're not really creating anything
right so "create" the structure if it doesnt exist
its really just an abstraction yea i get you
green elbow
you're not creating anything
surreal path
wdym?
i thought you cannot keep vnodes in ram all the time
cause of perfomance issues
cinder plinth
cause of perfomance issues
not a performance issue, more like ram issue
ideally you put as many files in ram as possible
unkempt relic
https://github.com/NetBSD/src/blob/trunk/sys/fs/tmpfs/tmpfs_vnops.c#L129 here is an example of how an actually existing fs does a lookup op
cinder plinth
this is why on macOS when you have 16gb of ram you have like 8gb ram usage idle, but on a 8gb system you don't
molten grotto
the vnode is the virtual counterpart of inode, maybe there are multiple open fil...
ah, ig I have been doing it differently then as I have just been basically using vnode as open file
cinder plinth
<https://github.com/NetBSD/src/blob/trunk/sys/fs/tmpfs/tmpfs_vnops.c#L129> here ...
ok so it does a linear search or use the namecache directly
I guess you could also have a hashmap per directory
tho idk how good that is space-wise
surreal path
ah, ig I have been doing it differently then as I have just been basically using...
okay so i wont have a vnode like an open file
there will be a vnode in ram that the tmpfs node points to
i think thats fine
green elbow
tho idk how good that is space-wise
depends on your hashmap load factor limits
unkempt relic
ok so it does a linear search or use the namecache directly
yeah, it is the old fashioned approach where the namecache is basically a library that filesystems call, instead of a superior layer in the stack so to speak
surreal path
thats how the paper says it tho
so im gonna follow the paper
i dont think it has ram issues
cinder plinth
yeah, it is the old fashioned approach where the namecache is basically a librar...
makes sense
a namecache is always good to have no matter what
also sounds simple enough to implement
surreal path
afterall the vnode structure is lit a few bytes
💀
@molten grotto please dont treat your vnodes like open files
elder shoal
there will be a vnode in ram that the tmpfs node points to
my tmpfs node just has a vnode as the first struct member so that you can do a pointer cast
surreal path
my tmpfs node just has a vnode as the first struct member so that you can do a p...
i will just have a ptr to the vnode
as the paper does it
cause it makes me feel all scientific
😎
unkempt relic
i will just have a ptr to the vnode
there's no tmpfs in the paper
molten grotto
<@379250891838193667> please dont treat your vnodes like open files
idk what issue is there with that tho
unkempt relic
in the solaris tmpfs it does implement a tmpfs tmpnode as a struct containing a vnode, like what astarl does
surreal path
think abt it
surreal path
in the solaris tmpfs it does implement a tmpfs tmpnode as a struct containing a ...
ooo
thats smart
molten grotto
a few kb
I don't really care about that, but if there are actual good reasons then ig Ill switch it
surreal path
i will do that then
cinder plinth
my tmpnodes have a pointer to a vnode and vnodes have an opaque pointer to fs-specific data
(in this case a tmpnode)
surreal path
ill just have the tmpfs node store the vnode
unkempt relic
actually never mind, at some point it became a pointer, but it's not a great deal of different
it's allocated for every tmpnode anyway and dosen't go away https://github.com/illumos/illumos-gate/blob/master/usr/src/uts/common/fs/tmpfs/tmp_tnode.c#L195
cinder plinth
yeah that's what I do
surreal path
nyaux is getting a vfs boys
after like a week of shanggains
nyaux is finally getting the vfs
😎
molten grotto
actually maybe there is at least one benefit, eg. if you write to a file that could have multiple vnodes referencing the inode then the inode would have to have an in-file structure having eg. a lock to synchronize the writes
so then you would basically end up having an unique in-memory structure per inode anyway just that the vnode ops would be in the layer above using more space being duplicated for each open file
elder shoal
it's allocated for every tmpnode anyway and dosen't go away <https://github.com/...
what are the advantages of doing it with an extra pointer
surreal path
heres what i thought of
ill have the vnode ops be a function pointer
that when defined for tmpfs
there will be a closure
that calls the tmpfs op
right
unkempt relic
what are the advantages of doing it with an extra pointer
i have no idea, i would've said maybe some lifetime issue, i don't totally rule that out, it doesn't sound too believable to me though
or rather i can't immediately think of a lifetime issue
surreal path
but multiple ops tho
yep ik
elder shoal
ill have the vnode ops be a function pointer
I have it as a structure of function pointers that you can then define
elder shoal
i have no idea, i would've said maybe some lifetime issue, i don't totally rule ...
hmmm
surreal path
that you can have as traits btw
oh rlly?
surreal path
so i can just have it as a trait
vnode operations
that i can impl for a tmpfs node or smthin?
how do i store flags for a vnode
molten grotto
that i can impl for a tmpfs node or smthin?
yeah, you can put the ops trait object inside a box and then store that in vnode
surreal path
yeah, you can put the ops trait object inside a box and then store that in vnode
ah i see
trait VNodeOPS
{
fn blahblah() -> i32;
}
struct vnode
{
ops: Box<dyn VNodeOPS>
}
somethin like this
cinder plinth
yea
surreal path
yea
haughty kite
```rs
trait VNodeOPS
{
fn blahblah() -> i32;
}
struct vnode
{
ops: Box<dyn VNode...
please for the love of god run rustfmt on your code
surreal path
please for the love of god run rustfmt on your code
lol
haughty kite
yes
surreal path
okay so
with the vfs
do i need a get next component function
or smthin?
i feel the urge to add a NT subsystem
to the kernel
that would be cool
surreal path
but are u confident u can pull that off
we'll see
just
lets focus on getting bash running
with proper ps2 drivers and whatever
rn lets focus on the vfs
surreal path
do i need a get next component function
anyone know?
cinder plinth
anyone know?
well what do you mean by that
molten grotto
<@379250891838193667> THANK YOU FOR THE NEW UACPI RS BINDGIGSSSS
if you do switch to them do let me know whether they work 
though I am pretty sure that they should work, I only tried to compile them on the host
surreal path
if you do switch to them do let me know whether they work <:trolol:8367304730611...
im switching to them
rn
ill let you know how they work
molten grotto
also for the functions that take in &CStr (like table_find_by_signature) you can use literals of the form c""
though the signatures for the common tables like hpet are also exported as constants
surreal path
also for the functions that take in &CStr (like table_find_by_signature) you can...
??
@molten grotto
molten grotto
what is the code where it fails
surreal path
what is the code where it fails
uacpi::init
i know my allocator isnt the problem
gives the address just fine
same with my vmm region allocator
memory is mapped and all no page fault occured
why is mr uacpi thinkings its out of memory
molten grotto
hmm
do you have the log level as trace?
or debug
because that could provide some info
surreal path
because that could provide some info
no info provided even with log level as trace
my slab allocator was requested ONE time for memory
to which it gave
thats all that happened
molten grotto
that's weird
surreal path
and that wasnt nessorilary for uacpi
that was for the kernel
Arc::new()
the kernel api
that worked fine
i checked
an arc object was created
so theres smthin funky goin on
molten grotto
can you push it to eg. a new branch or something? because I'd like to check, though I suspect that its not a problem with the bindings but its not impossible because I didn't test them
surreal path
can you push it to eg. a new branch or something? because I'd like to check, tho...
i can push it to the main branch
done
molten grotto
ah right, 0 is an invalid value for uacpi::Handle
Ill add an assert to make sure that new() isn't passed that and then a separate function to create an invalid handle
but in any case you shouldn't return invalid handle from any of the kernel api functions that return handle in a success case
surreal path
lol
so close
:c
SO CLOSE
RAHHHH
here
its page faulting
fuck
@kind root memory hell :>
kind root
oberrow curse
molten grotto
I pushed a check for the handle case, now it will fail with an assert if you try to do that
surreal path
CR3=000000007ff39000
surreal path
oh
molten grotto
it looks like its a null deref
kind root
idk
green elbow
wasn't rust memory safe??
surreal path
for i in 0..amou {
let mut e = PMM.alloc().unwrap();
e = (e as u64 + HDDM_OFFSET.get_response().unwrap().offset()) as *mut u8;
e.write_bytes(0, 4096 / 8);
e = (e as u64 - HDDM_OFFSET.get_response().unwrap().offset()) as *mut u8;
self.map((*new_guy).base + (i * 0x1000) as u64, e as u64, flags)
.unwrap();
}
only time i memset
surreal path
wasn't rust memory safe?? <:meme:575445094589661215> <:meme:575445094589661215> ...
yea 
kind root
wasn't rust memory safe?? <:meme:575445094589661215> <:meme:575445094589661215> ...
not if u spam unsafe everywhere like nauxmaster
alpine mulch
green elbow
not if u spam unsafe everywhere like nauxmaster <:meme:575445094589661215>
the based approach
surreal path
wtf is that alignment
wha
kind root
why are ur heap allocations 1-byte aligned
surreal path
no idea
thorn bramble
safe rust btw
surreal path
very
thorn bramble
need to make my own rust kernel
molten grotto
its also partially a skill issue
surreal path
😠
thorn bramble
it is a giant skill issue
rust would make ur life easy
but u just refuse to write rust
molten grotto
well some parts are annoying
thorn bramble
ur code is literally like if it was made by one of those C to rust transpilers
kind root
maybe figure out why your virtual address is byte aligned and physical is page aligned
how did u even map it like that
molten grotto
but in general if you don't spam unsafe everywhere and do things a bit more ideomatically then its at least a lot better
surreal path
maybe figure out why your virtual address is byte aligned and physical is page a...
it shouldnt even cause a problem
kind root
well it is if u assume that [virtual, virtual+4095] is valid
thorn bramble
its not C where you can dereference any pointer as long as the CPU is happy
kind root
because its not in your case
thorn bramble
in rust unaligned pointers are UB, no matter if you dereference them or not
at least iirc
surreal path
right
thorn bramble
oh, then i might be wrong, you CAN have unaligned pointer, just can't dereference them
that makes sense
can't create an unaligned reference
molten grotto
yeah that would be ub
thorn bramble
my bad on misinformation then
surreal path
both the hhdm and kernel region are 4096 byte aligned tho
yea they are aligned wtf
what the actual fuckers
cinder plinth
it looks like its a null deref
I thought rust was safe!!
Ah Geert already did the joke
cinder plinth
wasn't rust memory safe?? <:meme:575445094589661215> <:meme:575445094589661215> ...
Here
haughty kite
in rust unaligned pointers are UB, no matter if you dereference them or not
in C an unaligned pointer is also UB lol
*(int*)(((void*)x)+2) can be UB
especially with strict aliasing
thorn bramble
ok well but rust actually checks ub at runtime by default
haughty kite
true
elder shoal
Boring, real programming needs to have a luck factor
surreal path
God damn it
why god damn it
i fixed the alignement issue
we got as far as here
yea wtf is that address @kind root 😭
0xffff80007d685028
thats an issue with the slab allocator chat?
alignement issue AGIAN
this time with the slab?
am ii correcgt
wait no
wtf is going on
😭
????
CR2=0000000000000005
????
sorry
wha
molten grotto
again null deref from the looks of it
surreal path
again null deref from the looks of it
happening here
molten grotto
some heap corruption ig
surreal path
some heap corruption ig
ill try to get a backtrace for u
molten grotto
it probably doesn't really help with this kind of issue
surreal path
it probably doesn't really help with this kind of issue
right
surreal path
it probably doesn't really help with this kind of issue
does the address at least look valid?
molten grotto
what address
surreal path
prev address
i will print every address returned to see if its an issue with the allocator
sec
molten grotto
that can be normal but I am not sure if it should happen on qemu
surreal path
does the returned address look valid @molten grotto ?
the last thing my slab allocator returns
molten grotto
yes it looks valid
surreal path
yes it looks valid
qwinci does it look aligned
kind root
that can be normal but I am not sure if it should happen on qemu
Definitely not
molten grotto
just one guess, have you made sure that the minimum size that you pass to slab_header::init is 40?
because if its any less than that you are going to be corrupting the slab nodes themself
molten grotto
I think you already had a bug like that
surreal path
I think you already had a bug like that
yea but i put the minnium cache at 16
to fix it
not 40
molten grotto
I am not sure if you had that many fields in the slab header back then tho, likely not
surreal path
I am not sure if you had that many fields in the slab header back then tho, like...
i dont have much
struct slab_header {
size: usize,
next_slab: Option<*mut slab_header>,
freelist: Option<*mut KTNode>,
}
3 fields
8 + 8 + 8
24 bytes
...
yea
molten grotto
oh wait its KTNode that's used as the freelist node, nvm
surreal path
oh wait its KTNode that's used as the freelist node, nvm
its 8 bytes
yes but slab header
molten grotto
well KTNode 16 because of the option
but yeah if you already made sure that the min size is 16 then that's not a problem
surreal path
molten grotto
ig you could just make your alloc return whole separate pages for all sizes under page size to test whether its an issue with the slab stuff
(and adjust dealloc appropriately or just don't do anything there)
surreal path
its the slab
surreal path
ig you could just make your alloc return whole separate pages for all sizes unde...
ITS THE SLAB QWINCI
ITS THE FUCKING SLAB
KAKZMKCLXM MVNKLDKG:POSF@{lpDO'K,;OLMX.,JKN CAVKD\SLJ;GOP[]aof#D
S
@molten grotto I AM IN MISERY
also page fault here lol
@kind root what does it mean !!!!!
wtf is a gpe block
your the uacpi guy
surreal path
litearlly doesnt matter
i wanna fix this issue before
i fix the other issue
cause it seems to me
theres 2 issues
with my allocator?
am i correct?
elder shoal
Oberrow curse strikes again
surreal path
RAHHHHHHHHHH
ko[] m,. l;k'cp[pd';,mc. ./l';#c'dl,./m ,/@:c#
d[sa];cl',./m •c./@~:
s[]D[#'M./B, ,/'#S
]
#L';VKL;L'#
XW
kind root
i wanna fix this issue before
its the same thing
surreal path
in my VMM region allocator???
kind root
its uninstalling a gpe block because of some fatal init error
kind root
aka your mapping function is borked
surreal path
the vmm region alloc function right?
kind root
i mean idk what u call it
molten grotto
also do you make sure that the alloc size doesn't exceed a page now that you are returning straight up pages for each allocation?
idk how much allocations like that uacpi makes if any but that could be a possible issue
surreal path
also do you make sure that the alloc size doesn't exceed a page now that you are...
i just did
if layout.size < 4096
do one page
thats it
all i did
molten grotto
ah
surreal path
if layout.size < 4096:
return one_singular_page()
and do you zero the memory in that page?
molten grotto
try doing that first as its also used for the uacpi calloc function
surreal path
CR2=0000000000000009
surreal path
try doing that first as its also used for the uacpi calloc function
i zero the pages
still getting that issue
molten grotto
then its something different ig
surreal path
then its something different ig
i think its with the VMM
region thing
@molten grotto
does the vmm region base look valid
i feel like theres something wrong
block=0xffff80007daac00c
@kind root
kind root
and
orchid dawn
from a glance they all look aligned
surreal path
from a glance they all look aligned
yea idfk whats going on
i even wrote some tests
they all pass
@orchid dawn could u check it out
im desperate
orchid dawn
I still have like 20 other things I'm working on lol
even if I didn't, I likely would also have no idea
surreal path
😔
its not the deallocation
i checked
i cant figure this out 😭 😭
back to oberrow hell
surreal path
COME ON BRAIN THINk
WHAT THE FUCK IS WRONG WITH ME UGHHHH WHY CANT I FIGURE THIS STUPID
FUCKING ERROR
UNSUPPORTED GAS
SIZE
UR MOM
UGH
so annoying
@kind root my brain is dying
kind root
all this means is
whatever mapping u returned for FADT
is likely bogus
how does your map fn look like
surreal path
how big is the FADT table
surreal path
okay sec
unsafe fn map(&self, phys: uacpi::PhysAddr, len: usize) -> *mut core::ffi::c_void {
(phys.as_u64() + HDDM_OFFSET.get_response().unwrap().offset()) as *mut _
}
taht should work unless your hhdm is mapped incorrectly ig
surreal path
whichhh it isnt
cause i copy the above 4gb
for i in (0..0x100000000 as u64).step_by(4096) {
q.map(
HDDM_OFFSET.get_response().unwrap().offset() + i as u64,
i as u64,
VMMFlags::KTPRESENT.bits() | VMMFlags::KTWRITEALLOWED.bits(),
)
.unwrap();
hhdm_pages += 1;
}
i mean idk, something related to memory is bugged
surreal path
yea and i have no fucking idea how im gonna debug this
kind root
well u can just printf
surreal path
literarly what i did
kind root
also put a breakpoint in gdb