ah rust actually describes how it's encoded
#Zinnia
grave peak
C++ does too, but you need a full compiler to decode it
near tartan
why
grave peak
Because it can get very very complex
With nested templates etc
Its easier to decode at compile time and feed that to your kernel
near tartan
rust has that as part of the stdlib
or well, a component of it
you have to explicitly link it in
😃
grave peak
Does it do hidden allocations to demangle?
grave peak
Maybe If it's a super complex symbol idk
near tartan
nope
the demangle crate does not have a reference to alloc
it cannot make any allocations
grave peak
Well that's nice
marble salmon
C++ does too, but you need a full compiler to decode it
Nah you don't need a full compiler
It is somewhat annoying to decode because it allows back references but nothing that requires knowing about the actual type system etc
grave peak
Yeah like u still can't just handroll it, its quite a lot of code
marble salmon
at least you don't want to do that, yeah
eternal wharf
just do some macro and template magic to generate demangled names at compile time :^)
#define DEMANGLED(sym) \
[[gnu::section(".demangled")]] constinit const demangle_entry entry_##__COUNTER__ = {&sym, detail::make_demangled<sym>()};
template <auto V>
constexpr std::string_view detail::make_demangled() {
std::source_location loc = std::source_location::current();
return compiler_specific_extract_tpl_param_from(loc.function_name());
}
``` Is that actually a thing
eternal wharf
wdym? yes you can stringify stuff you can feed into a template param via std::source_location
modern hamlet
fun!
near tartan
```cpp
#define DEMANGLED(sym) \
[[gnu::section(".demangled")]] constinit con...
that's awesome
grave peak
I mean tpl param
modern hamlet
```cpp
#define DEMANGLED(sym) \
[[gnu::section(".demangled")]] constinit con...
wtf bro
eternal wharf
the function name would be in form detail::make_demangled() [with V = ...]
just extract the ...
marble salmon
there's also a __cxa_demangle function but idk which lib implements it / how hard it is to get it into the kernel
modern hamlet
how does THIS navigate every single symbol to generate at compile time
eternal wharf
how does THIS navigate every single symbol to generate at compile time
you add it manually
grave peak
there's also a `__cxa_demangle` function but idk which lib implements it / how h...
Isn't that part of the c++ runtime
eternal wharf
there's also a `__cxa_demangle` function but idk which lib implements it / how h...
i think libsupc++ in gcc
or libstdc++ but i think it's the former
modern hamlet
you add it manually
but why would you do that when you can do it at runtime
or... not because the itanium abi names are actually kinda readable
not like m*crosoft symbol names
marble salmon
i didn't find the actual definition with a quick grep so it's probably behind some alias or macro
eternal wharf
i think the worst part about __cxa_demangle is that it mallocs the output string iirc
grave peak
Lmao
eternal wharf
not even operator new :^)
modern hamlet
i think the worst part about `__cxa_demangle` is that it mallocs the output stri...
wtf just return the size if you fail to fill the provided buffer
grave peak
Worse than rust
marble salmon
what does rust do?
eternal wharf
The demangler interface is described in the source documentation linked to above. It is actually written in C, so you don't need to be writing C++ in order to demangle C++. (That also means we have to use crummy memory management facilities, so don't forget to free() the returned char array.)
near tartan
it just converts the symbol name during print
you give it a buffer to the mangled symbol and it impls Display
so whenever you print it, it gets demangled
marble salmon
ah
distant cypress
```cpp
#define DEMANGLED(sym) \
[[gnu::section(".demangled")]] constinit con...
don't you need to invoke source_location::current as a template argument?
template<auto V, auto L=std::source_location::current()>
constexpr std::string_view make_demangled() { // ...
i don't think so
the call in the body is still dependent on the template param and will include it in the string
eternal wharf
yeah i was too lazy to check the specific format of the string (and i think it differs between clang/gcc)
and msvc obviously
pine rock
C++ does too, but you need a full compiler to decode it
llvm-demangle isnt too heavy
it can do everything iirc
even rust demangling by the looks of it
somber solar
all c++ demanglers I've seen allocate though
welp I use the llvm one in my kernel for panics (if available)
pine rock
llvms ManglingParser takes an allocator as a template parameter, so you can give it a fixed buffer
it doesnt do nullptr checks though so you need exceptions for it to not crash on oom
somber solar
llvms `ManglingParser` takes an allocator as a template parameter, so you can gi...
good to know
I do have an entry in my todo list to not allocate during demangling
but my todo list is quite large and nothing is being done currently
marble salmon
why exactly is allocation a problem?
if rust uses Display to format in a non-allocating way, the actual output stream still needs some memory buffer to emit a contiguous line etc
hoary cave
it’s core::io::Write all the way through, no temporary buffers
normally, to prevent mangled logs, a lock is used on stdout
marble salmon
well yes but it'll go into a buffered writer at some point
otherwise, it'd do one syscall per char or similar which would obviously be worse than allocating
and if you want to store the output somewhere you obviously also need an allocation
somber solar
why exactly is allocation a problem?
what if the panic is caused by a memory allocation problem?
marble salmon
that's true, in that case it's better to preallocate
near tartan
Display only operates on the stack and a static immutable buffer
that makes it really nice
somber solar
that's true, in that case it's better to preallocate
allocation is used not only for the buffer (which can be easily bypassed) but during parsing as well
I guess I could have a fixed buffer and a separate allocator for it
somber solar
I'm talking about llvm demangler
near tartan
oh
idle flower
@near tartan i found a way for native rust tls, but you are forced to use fs
near tartan
fs?
idle flower
fs segment register instead of gs
idle flower
what abi?
idle flower
you have to work around that, for interrupt handlers you would need to push fs do swap gs and move gs into fs
for syscall handler you would need to declare one register as a scratch register to store user fs in it
near tartan
so how does one use the tls stuff then
fair lintel
there's also a `__cxa_demangle` function but idk which lib implements it / how h...
libgcc iirc?
idle flower
with #[thread_local]
also you need to pass tls-model=local-exec to rustc to ensure that it directly emitts fs relative accesses
idle flower
maybe, the problem is the resolve tls address function for dynamic tls will break interrupt/syscall handlers, so you would have to make sure that llvm still emits fs relative accesses for those, for example by using a different tls model that uses the direct accesses for all modules that are known at compile/link time
then the tls sensitive code has to be in those modules only
near tartan
eh
oh wait this is actually very useless
because then you can't access the data from other cores
my tls allows stuff like CpuData::get_from(4)
idle flower
well you would need a helper function that swaps fs before the access
idle flower
but also why do you need to access other threads thread local data?
near tartan
load balancing?
like if you have local run queues you need to move tasks somehow, right?
idle flower
those are on the heap? Then you could also store a reference to them in a global/core local struct
vast lotus
because then you can't access the data from other cores
you can, you just can't do so with just a cpu id. taking a pointer and accessing from another cpu still works fine
near tartan
those are on the heap? Then you could also store a reference to them in a global...
they are owned by the runqueue
maybe not the best design
the runqueue stores an arc
eternal wharf
well you can't swapgs obviously
swapgs then swap fs base using some gs-relative variables
marble salmon
accessing cpu locals of other cpus in rust sounds like a lot of pain
since you can't hold refs to them unless they use interior mutability
near tartan
accessing cpu locals of other cpus in rust sounds like a lot of pain
wdym
this is already handled by the fact that local variables are static
so they have interior mutability by design
marble salmon
like, let foo : &u32 = get_other_cpus_u32(); is instant UB
marble salmon
so they have interior mutability by design
well yeah but for thread locals you can use RefCells or similar
if you want to access the CPU local of other CPUs, you'd have to wrap them in Mutex or AtomicU32 or whatever
near tartan
like, `let foo : &u32 = get_other_cpus_u32();` is instant UB
really?
what makes it ub?
marble salmon
the fact that the owning CPU could take a &mut to it
near tartan
it could not
you can't have mutable references to a thread local variable in my code
near tartan
or atomics
marble salmon
yeah
near tartan
static mut is only allowed if the underlying type implements sync + send
near tartan
but then you need to wrap everything in `Mutex`, don't you?
this is what i ended up doing
marble salmon
my point is basically: with std rust thread_local's you can use single threaded data structures like RefCell but you can't do that if you allow access from other CPUs
so you get higher overhead
since you need to use thread-safe data structures even for CPU locals
near tartan
i would use it if it didn't complicate dealing with fs and gs
marble salmon
you can patch llvm to use gs as the thread local register :^)
but yeah probably not a good idea
we briefly considered doing that in managarm
somber solar
needing to compile llvm to build your kernel though 
marble salmon
we do that anyway
grave peak
smh my head just be binary compatible with linux and cp it
marble salmon
just get a good build machine
just download binaries from a build server :^)
magic charm
we do that anyway
is this still on account of that gcc bug?
near tartan
that would require actual infra 
magic charm
it had some problem or other with coroutines that arsen told me about
eternal wharf
is this still on account of that gcc bug?
coros in statement expressions still haven't been fixed no
some time ago i rebased our patches onto gcc 15 master when it was still unreleased to check and it still ICEd
marble salmon
it's hard to call this a bug because it makes use of a gcc extension
eternal wharf
well clang supports it, and there is a comment on the bug report saying that the intention is to support it
plus at least it should print a nice error and not ICE in the frontend
marble salmon
true
yeah it's not unreasonable to expect it to work
there should be no interaction between statement exprs and coroutines
fiery marlin
i think the worst part about `__cxa_demangle` is that it mallocs the output stri...
there is a no-alloc (and otherwise freestanding) version floating around somewhere - libiberty iirc?
fiery marlin
maybe I'm making shit up, one sec
I'm looking at __glibcxx_demangle_callback() in cp-demangle.c.
looks like it only really needs stddef, snprintf, some malloc/realloc/free (that was for my code ) and string.h functions.
I should clean this up and publish it, maybe that'd be easier lol
hoary cave
because jinx' llvm is old
fym "jinx's llvm" 😭
just imagedep experimental:llvm if u want llvm 20
i think debian unstable is like llvm 19
that isnt old
near tartan
fym "jinx's llvm" 😭
whatever the debian thing uses
near tartan
it was old at least
idk if it still is
but either way i use a patched llvm anyways
near tartan
really
hoary cave
maybe not a million but still, i did tell you that at some point
hoary cave
yes
near tartan
@somber solar why what's the difference between instance::create and instance::mknod?
they do the same thing
somber solar
because I don't actually have mknod
somber solar
they're supposed to set it up and stuff
I think
I don't really remember my thinking
near tartan
bruh
somber solar
bruh
ah I think it should use dev to get the appropriate ops for the file
from some sort of device registry
near tartan
ah I think it should use dev to get the appropriate ops for the file
just store the ops per file
smh
near tartan
but why do you need dev for that
somber solar
but why do you need dev for that
dev is a value created from major and minor number combination
I don't think mknod should be implemented for each filesystem though, because it just calls create but with different ops
just code duplication
near tartan
should file systems even interact with nodes?
i thought they only touch inodes
the vfs stuff doesn't need to be handled by a fs
that's why i don't get your abstraction
iiuc it should use backing
somber solar
iiuc it should use `backing`
that's in my todo list now
somber solar
uhh create inode should probably take type and mode as arguments?
other than that, it looks fine
near tartan
i guess
somber solar
ah true
near tartan
yea it should
delete should also use INode instead of a shared ptr
because i assume delete will be called when no other references exist
hm
somber solar
it can just fail if there are other references, no?
near tartan
ideally
near tartan
it can just fail if there are other references, no?
i have this
somber solar
ah
near tartan
that way i can force an invariant by just asking the caller to do that
if i don't then every implementing fs has to do this check
which is a bit meh
near tartan
uhh create inode should probably take type and mode as arguments?
?
unless type is part of mode
somber solar
well yes it generally is
near tartan
do i bother writing a high level concept around mode_t
i already have FileType
i could make mode into bitflags
somber solar
if your syscalls are going to take mode_t as an argument, you would need to translate it
near tartan
i think that's fine
somber solar
hmmm do you store children in vnode or inode
near tartan
vnode
somber solar
hmmmmm
then filesystem would need to access vnodes
for populate()
it's fineeeeeee
somber solar
I should probably have sync for inodes as well
near tartan
tbh idk what i was thinking with lookup
somber solar
I think this is better
for fs instance
no more need for separate mknod
oops forgot to change link target
somber solar
what would populate do
adds children to vnode
optionally you can supply name if you want to request only one child
somber solar
adds children to vnode
so if they are never accessed, they don't take up memory unnecessarily
resolve calls that with needed path segment, if it can't find a child on first try
I don't like the name "backing"
resource or inode sounds better
tbf populate should return a list of backings with their respective names and I should have a separate function that adds those to vnode children
perfect
somber solar
how should I do it?
distant cypress
what is the purpose of populate()?
somber solar
adds children to vnode
^
distant cypress
and why do you do that other than lookup?
distant cypress
that's just readdir lol
distant cypress
readdir (or e.g. getdents64, which readdir is based on) is usually implemented as a separate operation on the open file handle, not a vnode operation
somber solar
what's wrong with this approach though?
distant cypress
it allocates everything all at once (at populate() time)
and this can be impractical for large directories
also it is just generally an uncomfortable interface
a function that allocates and returns a potentially very large array, in kernel space
somber solar
how should I do it?
^
near tartan
is this sane
somber solar
is this sane
hard link vnode would just share inode with another vnode
distant cypress
how should I do it?
there's no specific "best way" to do it, but typically filesystem drivers implement readdir/getdents64 themselves
distant cypress
is this sane
why do you need this?
near tartan
for vnodes
somber solar
there's no specific "best way" to do it, but typically filesystem drivers implem...
I'll just call it cache and now I'm a pro
distant cypress
despite having similar names, a hard link and a soft link are very different things
near tartan
like, a hard link points to an actual inode, and a soft link only points to a node via a path, right?
somber solar
soft link redirects vnode to another vnode
distant cypress
there is no such thing as a hard link
a "hard link" is a vnode which is referenced by multiple directory entries
near tartan
so how should i do it
distant cypress
nlink
near tartan
near tartan
i get that part
distant cypress
is there a one-to-one between an Entry and an on-disk inode?
distant cypress
bruh
near tartan
idk
distant cypress
Linux actually does a very nice thing here
near tartan
yea dentry
distant cypress
and it is that the VFS deals mostly in struct dentry and the underlying fs deals mostly with struct inode (the "vnode")
near tartan
why is inode the vnode
distant cypress
because linux
near tartan
i thought inode was the inode abstraction
distant cypress
same thing
distant cypress
is your "vnode" (Entry) the same as the Linux "dentry"?
near tartan
yes
distant cypress
so there is not much reason for the dentry to have a record about the mode of the inode it points to
near tartan
so should it always point to an inode?
distant cypress
well, you can have a negative dentry
distant cypress
but generally you get the file type from the inode
distant cypress
negative = null?
negative equals not present
near tartan
oh right symlinks are also inodes
i forgor
my old kernel did this on the vfs layer (dumb)
distant cypress
there's also gray/a dentry that hasn't been looked up (not in cache)
near tartan
distant cypress
there's also gray/a dentry that hasn't been looked up (not in cache)
this is something which makes the "interface" between the VFS layer and the filesystem layer very nice in Linux
somber solar
why can't I forward declare nested structs 
somber solar
yes, I know
distant cypress
this is something which makes the "interface" between the VFS layer and the file...
because it means you can allocate a dentry for a file, and then call inode->i_ops->lookup(inode, dentry); and lookup will populate that dentry for you.
near tartan
can there be a dentry that points to nothing?
distant cypress
because it means you can allocate a dentry for a file, and then call `inode->i_o...
this is why in Linux, the VFS deals "mostly" with struct dentry and the filesystem "mostly" with struct inode
distant cypress
can there be a dentry that points to nothing?
as in?
near tartan
ohhh
distant cypress
and caching ENOENT can give performance boosts e.g. with shell exec, because it does lookup on all the possible PATHs it can find an executable in.
near tartan
i see
distant cypress
cache ALL THE THINGS
somber solar
good idea
distant cypress
basically, except maybe not named like that
I'd do Positive, Negative, Unknown, with entries defaulting to Unknown until they have been looked up
somber solar
couldn't be me
C++29 🙏
distant cypress
i guess `link` is also a bad name?
yeah, it is very bad because it is easily mixed up with other filesystemish uses of "link"
near tartan
what's a synonym
somber solar
connect :P
near tartan
i couldn't think of anything better
node is bad imo
because that might also be confusing
distant cypress
Entry::inode
near tartan
eh fair enough
distant cypress
I'd do Positive, Negative, Unknown, with entries defaulting to Unknown until the...
optimisation: if your tmpfs leverages the capabilities of your VFS cache to store its hierarchy, you can leave i_ops->lookup NULL and if you see this when creating a dentry, initialize it to negative instead.
somber solar
I can't wait to actually use this mostly untested vfs and have to redesign everything
it's somewhat tested, basic file lookup and stuff works (I load modules from initramfs)
near tartan
optimisation: if your tmpfs leverages the capabilities of your VFS cache to sto...
yea, can not quite do null, but an empty impl should be fine
i can return enosup
distant cypress
yeah if you cannot leave it NULL because you are using a skill-issued language, obviously this is fine:
errno_t
tmpfs_lookup(inode *, dentry *e)
{
dentry_make_negative(e):
return ENOENT;
}
and that default trait looks like this
distant cypress
yeah just errno lookup(inode, dentry) is how Linux does it, I'm relatively sure
somber solar
@distant cypress could you glance over my code and tell me if I'm doing anything that stands out as obviously wrong? (other than populate being meh)
distant cypress
<@492393383273168906> could you glance over my code and tell me if I'm doing any...
tomorrow I can take a closer look
(if you remind me sometime during the day)
near tartan
thanks for the pointers
somber solar
(if you remind me sometime during the day)
if I remember myself :P
somber solar
thanks for the pointers
here's one more u64*
distant cypress
I should write some notes about filesystems and VFS design and make them available somewhere (although that'd be a slightly more longterm thing to do)
distant cypress
I should write some notes about filesystems and VFS design and make them availab...
slowly but surely I am on the path of becoming a forum boomer
near tartan
why does linux return a dentry pointer 💀
distant cypress
because linux
near tartan
does it just return the input?
distant cypress
actually the reason is some NFS stuff iirc; AFAIK everything else just returns the input dentry or a negative errno
distant cypress
because with NFS there's some condition where there can be multiple struct dentry for one path or something, and that is fixed by keeping a list per inode of dentries that point to it and returning one of those
somber solar
real
distant cypress
yeah, if you already have a errno lookup(inode, dentry), changing it to a dentry_or_errno lookup(inode, dentry) shouldn't be that big of a deal.
somber solar
(if you remind me sometime during the day)
ping
somber solar
@near tartan how's the vfs going
near tartan
512
grave peak
I see u decided to go with air
grave peak
Wtf
grave peak
Dammn
grave peak
How big of a PSU does this thing need
somber solar
my gpu is like 50 💀
near tartan
it's done!
nocturne rampart
it's done!
Can I mine bitcoin-
somber solar
what's the point of the third pcie slot being open at the end if the nearby nvme slot would be blocking any cards with larger connectors?
hybrid island
Smooth brained PCB
grave peak
it's done!
does it boot
vast lotus
how long does the memory test take
near tartan
vast lotus
or just post in general
vast lotus
damn
vast lotus
only 480G of ram
eternal wharf
perfect machine to run gentoo
somber solar
what a god damn sight to behold
is that both cpus or just one
grave peak
Maybe implement PCI kernel api so we can see the number of ops at least
somber solar
which acpi tables do you want?
yes
eternal wharf
i wanna see if it works on a 96 core machine
and how bad it is due to no numa awareness
somber solar
https://builds.managarm.org/repos/files/managarm/2025-06-01T12:03:46/image.xz
nightly builds
last build: 3 days ago
eternal wharf
>nightly builds
>last build: 3 days ago
yes there have been no commits since
somber solar
dead project
eternal wharf
and we only do full rebuilds every sunday at 1am, other times it's triggered by commits
eternal wharf
hmmm
grave peak
Now try pmos
eternal wharf
ts pmos
near tartan
ts ts
near tartan
oh definitely
good aml
vbios doesn't seem to work though
i cant get efi gop from a gpu
near tartan
lol this board has an NMI button
eternal wharf
hm you could try pressing it in managarm :^)
eternal wharf
hmmmmm
near tartan
idk why managarm doesn't run on any of my machines
eternal wharf
when running correctly all the cpus that got the nmi should print some stuff
near tartan
@somber solar your thing also hangs
somber solar
<@759846526880317441> your thing also hangs
where?
near tartan
somber solar
oh it works
that's the most it does
I should really initialise cores in parallel lol
near tartan
is it supposed to die there?
somber solar
I want to do uvm before anything else
and I'm avoiding working on it, so nothing gets done
grave peak
That's probably the first uACPI test on server hw
near tartan
nah
it's the first one that you see
i've ran menix before on dual xeon thinkcentres
also worked
grave peak
Damn
somber solar
I just noticed, so much pci
eternal wharf
hmm it prints that it's configuring the irq but not that it has allocated slot 0 for the irq
somber solar
also is it just me or does the framebuffer seem slow
near tartan
it's not accelerated
eternal wharf
hmm it prints that it's configuring the irq but not that it has allocated slot 0...
uacpi-info: successfully loaded 1 AML blob, 585 ops in 0ms (avg 4486127/s)
thor: Configuring IRQ io-apic.0:9 to trigger mode: 2, polarity: 1
thor: Allocating IRQ slot 0 to io-apic.0:9
i'm curious why it says disabled for so many lapics
near tartan
also is it just me or does the framebuffer seem slow
you should see my intel pc
THAT is slow
grave peak
i'm curious why it says disabled for so many lapics
That's probably correct
Just reserved entries in apic
grave peak
Bios just fills them in
hoary cave
what's the context of >256 lapics
cyan nexus
1 per core
hoary cave
okay
hoary cave
more liek one per logical core
cyan nexus
idk how you would handle all of them tho
near tartan
more liek one per logical core
still
near tartan
yea but how do you address them
cyan nexus
maybe via multiple ioapics?
hoary cave
address them like what
ah
in which case would you fail to address a lapic with id > 255?
or rather
when is that a problem?
eternal wharf
for >255 apics you need to use x2apic iirc
cyan nexus
when you wanna have more than 255 irqs
hoary cave
when you wanna have more than 255 irqs
you either share vectors or route to different cpus
eternal wharf
```
uacpi-info: successfully loaded 1 AML blob, 585 ops in 0ms (avg 4486127/s)
t...
hmm it getting stuck before printing the last line here would imply that some other core is holding globalIrqSlotsLock and not letting go
somber solar
for >255 apics you need to use x2apic iirc
if x2apic is supported, you should use it anyway, so there's no problem
hoary cave
yeah you wanna route to a cpu that's best suited to handle the interrupt
and if you use xapic you can't use some cpus
simple
cyan nexus
yeah, x2 apic is not really hard to support
it is even simpler to use
than normal lapic
hoary cave
both are lapic
near tartan
so it's safe to assume the x2apic is present if i have that many logical cores
cyan nexus
ye
somber solar
yes
hoary cave
you dont have to assume
near tartan
because i don't have an x2apic on this machine
hoary cave
you can check
hoary cave
some machines it's might even be enabled by default
somber solar
you can check
yes, but it's safe to assume that x2apic is supported :P
cyan nexus
can you even disable it?
hoary cave
no
near tartan
bios
cyan nexus
bios can?
hoary cave
once it's enabled you can't disable it
it's a cpu feature, maybe the firmware has some way to mess with it to disable it
but i doubt any board actually lets you
that's dumb
cyan nexus
but probably very rare
near tartan
my asrock am5 board lets you
somber solar
crazy? I was crazy once
hoary cave
what
near tartan
yea
cyan nexus
or is the am5 server?
near tartan
am5 is consumer
cyan nexus
oh ok
hoary cave
common amd L
near tartan
are u fr
near tartan
bc intel doesn't have that either
near tartan
shit lake
hoary cave
coming in summer 2026 !!!
near tartan
(no bios)
hoary cave
at least it'll have 52 cores
marble salmon
Hmmm
This system has more than 256 gsis, we may not support that
CC @eternal wharf
eternal wharf
ah hmmm
marble salmon
I wonder if it overflows the gsi vector
eternal wharf
kernel/thor/arch/x86/pic.cpp
730:void setupIoApic(int apic_id, int gsi_base, PhysicalAddr address) {
741: globalSystemIrqs[gsi_base + i] = pin;
this smells bad
globalSystemIrqs is sized to be 256 entries long
i wonder if we write past the end of it and end up corrupting the globalIrqSlotsLock object
hoary cave
is globalSystemIrqs a static array?
eternal wharf
yes
eternal wharf
not enabled by default
distant cypress
technically it doesn't make sense for it to be an array, because there might be hardware with IOAPIC 0 on GSI0...23 and IOAPIC 1 on GSI1337420...1337499
although this is very unlikely
marble salmon
yeah i think this assumption doesn't make sense
I may have done that because I assumed that all IRQs should be routable to a single CPU but that's not really a reasonable assumption
distant cypress
this is a struct irq_pin_or_whatever * array?
marble salmon
yeah this maps ACPI GSI numbers to our IRQ struct
distant cypress
yeah so just a map<uint32_t, IRQ *> or something would probably work
marble salmon
true
distant cypress
or it can be optimised by grouping together GSIs that belong to the same IOAPIC or are otherwise contiguous
marble salmon
that's not necessary, this is not on a hot path
distant cypress
yeah
marble salmon
it's only used during configuration, not during IRQ handling
we should also move this from x86 specific to acpi code (such that we can enable acpi on aarch64 and riscv64)
who wants to do the work? :^)
distant cypress
or it can be optimised by grouping together GSIs that belong to the same IOAPIC ...
in 99% of cases this would probably result in a single entry with all the GSIs because they are most likely contiguous
marble salmon
well, this system apparently has 9 I/O APICs
distant cypress
and they are probably assigned to GSIs 0-23 24-47 48-63 etc.
marble salmon
216 irqs
it's 280 since all but the first i/o apic have 32 pins according to the log
distant cypress
who wants to do the work? :^)
if no one does it before this weekend I can try to setup a managarm dev env on my machine and do this
cyan nexus
it's 280 since all but the first i/o apic have 32 pins according to the log
oh, even more then
cool
i tought ioapics only had 24 pins
distant cypress
you read it from IOAPIC_VER iirc
what do you even need 280 GSIs for now that there's MSI?
cyan nexus
i read them like this
near tartan
it's crazy i have no idea what this is about
need to learn
in the meanwhile i figured out the dead ram stick
cyan nexus
gg
near tartan
512 gigs now
im installing opensuse and then we test an llvm compile
the idle temps are actually insanely good
33C according to btop
which is perfect for my homelab
near tartan
actually
ill finish vfs stuff
then i can look into smp
when i have smp i should also look into initgraphs
instead of throwing every init function in the same init array
oh god initgraphs in rust
hoary cave
not fun
near tartan
idek how to start doing that
cyan nexus
initgraphs?
near tartan
what @somber solar and managarm use for init
hoary cave
look at managarm
cyan nexus
ah ok
hoary cave
initialization is done using a graph
near tartan
which is fucking cool tbh
hoary cave
instead of good ol init_a(); init_b(); init_c();
it's not fun at all to do in rust btw
i tried
maybe i am retarded but i could not get it done lol
of course not without allocating
or unsafe
marble salmon
Hm
cyan nexus
maybe by preallocating the steps?
marble salmon
yeah it probably needs unsafe
hoary cave
that makes no sense
marble salmon
to emulate [[constructor]]
hoary cave
in rust the issue is the backlink from node to engine
that's a cyclic reference
i was basically tying to rewrite managarm initgraph tho
marble salmon
Cyclic &'static refs are fine though
marble salmon
that sounds like pain
hoary cave
it is lmao
i cant do 'static though
unless i have a global instance of the engine
again, idk what the proper terminology is or what that means exactly
just using managarm initgraph terms
marble salmon
that's what Managarm does though
hoary cave
oh really?
i must have been blind then
it makes sense tbh
and i was definitely blind
it's passed through the constructor
so it has to be global
distant cypress
it should be possible and relatively easy to parse the source code for initgraph declarations and emit calls to them using an external tool, no?
hoary cave
why though
marble salmon
in C++ you could also use a non-global one but doing that in Rust would add a lot of complexity
distant cypress
why though
so no allocations + check acyclicity at compile-time
hoary cave
managarm doesn't allocate either
marble salmon
if i wanted to do this in Rust I'd probably write a macro that emits whatever unsafe code you need to put a ctor into .init_array
for each init graph task
such that it can register itself with the engine
near tartan
if i wanted to do this in Rust I'd probably write a macro that emits whatever `u...
yea i dont think i can get around a macro
near tartan
hm, i tried doing non-static lifetimes
why would you need non static lifetimes?
i thought all graph nodes are a comptime element
hoary cave
i think a macro is nice either way, so you can do stuff like menix::init_stage!("x86:discover-lapic", || { // ... });
or just a function as the 2nd arg works too
near tartan
i think a macro is nice either way, so you can do stuff like ```
menix::init_sta...
oh ya i like this
near tartan
by string would be braindead
near tartan
maybe identifier?
hoary cave
i think so yes
eternal wharf
proc macro to turn the string into a ref to the stage object
near tartan
🤢
then you could just mark a function as init stage
menix::init_stage!("x86:discover-lapic", &[memmap_ready], lapic_ready, || /*...*/);
something like this?
hoary cave
that's not how that works
near tartan
wdym
hoary cave
or you could make it work like that
hoary cave
interesting
eternal wharf
first rust os to have a gui
eternal wharf
rust kernel*
near tartan
when i mount a FS, should that mount on a dentry or an inode 🤔
vast lotus
dentry imo
near tartan
distant cypress
you mount a filesystem on a path
the mountpoint is a path
you can have e.g. the following:
- fs1 mounted on /media/a and /media/b
- fs2 mounted on /media/a/foo
a lookup in /media/b/foo will not resolve to a path within fs2
(and the path consists of parent mount and dentry)
nocturne rampart
crazy that until now there wasnt a single kernel with x11
Huh what about Aero?
near tartan
i fiorgot
idle flower
Rust has the petgraph crate for graph structures
near tartan
tbh i prefer writing my own
nocturne rampart
https://x.com/phoronix/status/1930339846079557769?t=GF2lTj3vxOZaz4ySJX6TfA&s=19
Though why x11
Why wouldn't they opt to implement the wayland protocol (I've not read the article yet)
nocturne rampart
Yeah
And they are implementing x11 inside their window server
So why not implement wayland instead?
near tartan
And they are implementing x11 inside their window server
wait wat
they have their own window server?
nocturne rampart
X11 support has begun to be implemented within the Oribtal display server so that X11 apps will be able to work gracefully on Redox without display-related changes.
Read the article
near tartan
i missed that
near tartan
wtf
nocturne rampart
Which is why I had the doubt why not implement wayland instead?
nocturne rampart
Menix should run Weston /s
nocturne rampart
Though isn't there a wayland compositor for bsds that doesn't on drm and epoll?
fair lintel
eventfd is easy
fair lintel
I signalfd should be easy with a reasonable implementation of signals
nocturne rampart
Though isn't there a wayland compositor for bsds that doesn't on drm and epoll?
I don't recall correctly but it was portable
fair lintel
I forgot what else it needs
nocturne rampart
Ok so signals as well
nocturne rampart
Probably I'll do that after networking
prime seal
first rust os to have a gui
does redox not already have a gui?
near tartan
it's a joke reference
near tartan
yes
prime seal
ah
near tartan
@vast lotus following #x86 , so are IRQs always known beforehand and the controller maps the handler internally?
vast lotus
you mean the index parameter in open? that's pretty much just an opaque value whose meaning is IRQ controller dependent
on a pic controller it'd be the pin number which is known at compile time for most devices
on a PCI controller it'd be A/B/C/D which you get from the PCI header
etc
near tartan
neat
then i think i understand it
my open should probably return an Arc<Interrupt> which gets dropped if the device handling it is dropped
near tartan
duh
nocturne rampart
Some programs use the fd pulled from wayland for that
near tartan
did they respond to you on xitter
nocturne rampart
No but Tristan did
near tartan
damn
nocturne rampart
near tartan
if i'm creating an inode, which has no idea of its own name, how does a filesystem record its file name?
somber solar
if i'm creating an inode, which has no idea of its own name, how does a filesyst...
you pass the name during creation
filesystem can store that name if it wants to
near tartan
hm
eternal wharf
you link the inode into a directory at a later time :^)
near tartan
what later time
somber solar
you link the inode into a directory at a later time :^)
on sync()?
eternal wharf
i mean you have a separate link operation that links it in
both for the initial link and extra hard links
somber solar
ah I misunderstood
near tartan
oh so when i do e.g. mknod i first run create_inode and then link_inode
and link_inode gets passed the name?
somber solar
what's the point of that?
near tartan
well inode has no idea what its name is
idk if that's right
and inodes also have no reference to a dentry
somber solar
yes so that's why you pass the name during creation
link() has no idea of vnode/dentry either
because it works on inodes
near tartan
im confused
eternal wharf
i mean idk what your idea is but in managarm you first create a unowned inode that you then link into a particular directory
hybrid island
This is because using an arc with the explicit type does not use the trait vtable, only has struct pointer under the hood
somber solar
rust
near tartan
i mean idk what your idea is but in managarm you first create a unowned inode th...
i'm just confused
somber solar
confuzzled
somber solar
ilobilix :P
hybrid island
BadgerOS also has working tmpfs with sym- and hardlink support too
near tartan
ilobilix :P
well i can't really use yours because your vfs design is a bit different to mine
somber solar
everyone's design is different
near tartan
yes but iirc you always connect a vnode to an inode
somber solar
yes
near tartan
@eternal wharf where in managarm would i find tmpfs?
eternal wharf
posix-subsystem
somber solar
i mean idk what your idea is but in managarm you first create a unowned inode th...
why is that?
zealous salmon
ig ontologically the inode is separate from the dirent
somber solar
it is, but what use is there for inode that doesn't do anything?
zealous salmon
but ig usually when you're creating something, you want to link it immediately anyway
hybrid island
BadgerOS basically just says inode management is the filesystem's problem
somber solar
hybrid island
All it does is make sure the same one will not be opened more than once at a time
(from the FS driver perspective)
near tartan
BadgerOS basically just says inode management is the filesystem's problem
exactly
the vfs doesn't concern itself with inode management
hybrid island
https://github.com/badgeteam/BadgerOS/blob/main/kernel/src/filesystem/fs_ramfs.c if you're interested in my impl
It's a bit wacky with the dirents though
eternal wharf
managarm doesn't have much of a distinction between inodes and vnodes since stuff is done via inheritance in posix-subsystem
marble salmon
inode == vnode
near tartan
really?
marble salmon
Doesn't vnode just refer to the in memory representation of an inode?
modern hamlet
It can be slightly more than that but that's what I was pretty sure it is
modern hamlet
a vnode is a cached entry which stores parent, name and children
name?
near tartan
yes
marble salmon
That's a "link" in Managarm's language and on linux it's called a dentry
near tartan
the in memory representation of an inode is what i call INode
hybrid island
technically inode is on-disk and vnode is in-memory
marble salmon
That's a "link" in Managarm's language and on linux it's called a dentry
Not sure what the bsd term is but somebody else will probably know
near tartan
but using linux terms it's inode and dentry
hybrid island
Not sure what the bsd term is but somebody else will probably know
Namecache entry IIRC?
marble salmon
ah true
hybrid island
This many OSDV's is a beautiful sight
magic charm
technically inode is on-disk and vnode is in-memory
there are incore inodes too
cyan nexus
why tag gon
it's not?
nocturne rampart
@near tartan Redox implemented Unix sockets partially
idle flower
What tool did you use for that?
marble salmon
probably graphviz
near tartan
<@173337436989030401> Redox implemented Unix sockets partially
bruh
mental tinsel
could it perhaps be possible to find symbols by literally parsing the executable from the filesystem and looking for the symbol at an address because I think it would be really funny to do that for panic traces once I have a working filesystem driver for iso9660
vast lotus
i mean yeah but why not use the executable image that's already in memory for that
you can just tell the linker to put the symbol table in an allocated section
mental tinsel
understandable, I will attempt both for the meme tho
vast lotus
realistically the biggest issue (other than that there's a far more practical and easier solution) with the filesystem approach is that you want your panic code to be as simple as possible so you don't get recursive panics
mental tinsel
alrighty 👍👍
