send the error or it works fine
#Ilobilix - a linux compatible kernel
chilly pond
worn sierra
chilly pond
bruh
worn sierra
bruh
chilly pond
I have some fixing to do
worn sierra
tbh i just wanted a compile_commands json so i can search through the source code
chilly pond
I can't reproduce either of those errors
can you try cloning with --recursive instead of updating after?
the xmake one might have been a github thing because v3.0.0 was released only a few minutes ago
chilly pond
smh
worn sierra
chilly pond
okay everything should be fixed
chilly pond
?????
worn sierra
chilly pond
๐ญ
worn sierra
๐ญ do you have a ci
worn sierra
like bruh
can you just send me your compile_commands.json
idk if that works
maybe the paths are absolute
chilly pond
can you just send me your compile_commands.json
you'll need to change /home/ilobilo/Documents/projects/ilobilix to your cloned path
chilly pond
what option were you trying to change?
chilly pond
I regret using xmake
chilly pond
what xmake version is that and how did you install it?
chilly pond
ah
worn sierra
yea works
chilly pond
nice
chilly pond
hmm yeah
worn sierra
ok im gonna look at your vfs code now
worn sierra
@chilly pond what is a vfs::path?
chilly pond
<@759846526880317441> what is a vfs::path?
combination of a mountpoint and a dentry/vnode
worn sierra
when do you need that
chilly pond
when going up from a mountpoint to parent dentry
that solves the multiple mounts for single fs issue
worn sierra
right
golden kiln
that solves the multiple mounts for single fs issue
golden kiln
when I'm feeling better
worn sierra
@chilly pond wth is this input parameter
chilly pond
<@759846526880317441> wth is this input parameter
source
worn sierra
source?
chilly pond
yes like /dev/sda1
worn sierra
but i thought path stores an entry and struct mount
chilly pond
it does
worn sierra
struct dentry {
...
std::optional<std::shared_ptr<mount>> mount;
};
no because there could be multiple paths with different mounts all referring to the same file
light cosmos
so the thing is
the very same dentry in memory is used for two different mount points of the same filesystem
chilly pond
<@759846526880317441> wth is this input parameter
that shouldn't be a reference
it was shared_ptr before and I probably left it
worn sierra
also unmount() on a fs::instance doesn't make sense, right?
chilly pond
I don't understand what you mean
worn sierra
path contains a struct entry and a struct mount
chilly pond
yes
worn sierra
why exactly are you passing a struct mount to the mount() function
chilly pond
huh true
worn sierra
i would expect to pass just an entry
chilly pond
just dentry should work fine
more stuff like this might come up when I do a real filesystem :P
worn sierra
no because there could be multiple paths with different mounts all referring to ...
i don't get this
different paths would be different dentry's
they can point to the same inode
chilly pond
no, then you would need to duplicate every dentry of the filesystem
/dev/sda1 mounted on /abcd/mnt1 and /home/user/mnt2
one path could be mount: /abcd/mnt1 and dentry: {/dev/sda1}/file.txt while other path can be mount: /home/user/mnt2 but the same dentry
light cosmos
different paths would be different dentry's
no
two paths are different if path.mount differs or path.dentry differs
worn sierra
bruh
from looking at the code, it seems like entrys are basically always connected with a mount point
light cosmos
which code?
chilly pond
shitobilix code
worn sierra
i think i'm actually being filtered by this shit
chilly pond
filtered?
worn sierra
in my mind a dentry is the result of a URI path conversion to a hierarchical structure
chilly pond
that would be vfs::path
worn sierra
no that's just the representation
so /home/user/mnt2 would be a different entry than /abcd/mnt1
because mnt1 has abcd as a parent
chilly pond
I get why windows uses that shitty simple mount system
chilly pond
so /home/user/mnt2 would be a different entry than /abcd/mnt1
dentries of mnt1 and mnt2 would be different, but the children of the filesystem that's mounted on them are the same
worn sierra
oh yea but as a vfs you shouldn't care about that
the inodes should be the same
but not the dentry's
chilly pond
then you have as many duplicates of dentries as you have mounts
that is simply inefficient
worn sierra
i mean you also have a dentry for every failed lookup
chilly pond
I don't
chilly pond
that is simply inefficient
also how would you even synchronise them between mountpoints?
chilly pond
if a file is deleted from under one mounpoint, how does another one know that it's deleted? you would need some hacky workarounds
worn sierra
the inode is what's being deleted
if you want to access an inode from a dentry you have to validate it first
chilly pond
so you keep the dentry allocated until you access it? what if you never do so?
worn sierra
if a file is never accessed, nothing gets allocated
chilly pond
accessed once, allocated, inode deleted, multiple dentries stay under multiple mountpoints
worn sierra
they stay but the fs instance can update a dentry and invalidate it
chilly pond
how?
chilly pond
in every dentry in every mountpoint?
chilly pond
yes I understand what you mean
but as I see it that's inefficient and slow
and tricky to get right
chilly pond
as @light cosmos told me, linux does what I do
chilly pond
I don't see anything about dentries for same inode under different mounts
this is indeed complicated, took me a bit to get how it works
worn sierra
damn
i can see that linux records the mounts in the struct superblock
and not in a dentry
chilly pond
ah good to hear that because I thought I was doing that part wrong :P
worn sierra
wait i'm dumb
i have the tanenbaum bible
maybe they can explain it
oh nahhh i forgor it's the german version
light cosmos
because unlink takes in a dentry
unlink takes in an inode and the name of a file within that directory. dentry is just a nice way to package that name of the file. the filesystem driver doesn't really have to care all that much about VFS shenanigans, apart from knowing that the dentry has a name, and it is that name which should be unlinked from the directory.
worn sierra
right
light cosmos
iirc: the thing that d_invalidate does is it removes the dentry from the hash table so it cannot be found in a lookup (it only does this if there are any other live references to the dentry). this mitigates certain types of TOCTOU where a task opens a path (e.g. O_PATH), checks something, and the inode under that dentry is unlinked and replaced with a new inode (because the new inode will be installed in another dentry instead).
worn sierra
oh and fyi @chilly pond
your mount() prototype makes no sense :3
remind me again when you have a block fs working ๐
chilly pond
your mount() prototype makes no sense :3
wdym?
worn sierra
where does it get the source from
worn sierra
then im misunderstanding your struct names
worn sierra
i get that part
but fs::mount doesn't take a source parameter
does the fs just not care about it?
chilly pond
but fs::mount doesn't take a source parameter
it does though
worn sierra
where
worn sierra
I'm so confused again
chilly pond
worn sierra
linux' mount needs a device path, a mount path, an fs name and flags
chilly pond
linux' mount needs a device path, a mount path, an fs name and flags
mount is a function, struct and a method inside struct filesystem
chilly pond
appropriate reaction
light cosmos
linux' mount needs a device path, a mount path, an fs name and flags
yeah that's the syscall
a filesystem driver really only needs the device path and flags
worn sierra
maybe calling everything the same isn't the best idea
chilly pond
<:meme:575445094589661215> maybe calling everything the same isn't the best idea
I just never thought anyone else would be reading my code
worn sierra
bad mentality smh
chilly pond
chilly pond
after more than a month of not working, I added kallsyms for symbol lookup
hopefully I'll continue doing stuff
grand gulch
Time to make an async lockless logger
chilly pond
lol
I have encountered a little issue
modules need mangled names for symbol resolution
I have demangled names for kallsyms
smh
grand gulch
Lol
chilly pond
if only I could demangle without allocation
fiery grotto
| c++filt
chilly pond
You can't?
I couldn't find anything
fiery grotto
at runtime
you can just pipe output of qemu through c++filt in your makefile or something
chilly pond
It appears to be possible non-alloc at a glance to me
I'm not writing an entire demangler ๐
grand gulch
you can just pipe output of qemu through c++filt in your makefile or something
#1324404719183069358 message
chilly pond
you can just pipe output of qemu through c++filt in your makefile or something
true but I might not have serial somewhere else, like on bare metal
broken beacon
true but I might not have serial somewhere else, like on bare metal
You can't have all three, pick at most two:
- Don't make it yourself
- Non-alloc
- Runs in kernel
fiery grotto
it's hard to demange anything without allocating but i might write a demangler that can output using a callback
or do std::format<MangledSymbol> :^)
broken beacon
it's hard to demange anything without allocating but i might write a demangler t...
You can do it even without recursion if you hate yourself enough.
broken beacon
IMO the best option is still to do | c++filt
You can do that if you're using some command-line serial monitor just fine.
chilly pond
hmm I'll do that
I might try to modify llvm's demangler to use a callback, if it's possible
grand gulch
make stack trace printing output mangled names
Output 600 char long name in the backtrace ๐
chilly pond
I found one that was 2390 characters long in debug mode (demangled)
light cosmos
the stuff that happens when you overuse templates and namespaces.
chilly pond
there's no such thing as overusing templates
it was a libstdc++ thing anyway
smart pointers and construct()
I still left in the runtime demangler, so if I ever need it, I can just uncomment one line
chilly pond
I love C++ (not an actual line from source)
lib::locked_ptr<filesystem::instance, lib::mutex> instance = lib::make_locked<tmpfs::fs::instance, lib::mutex>();
then I can do instance.lock()->stuff
or if it's a rwlock instance.read_lock() or instance.write_lock()
basically rust mutex + arc
limpid jasper
this seems like a prime candidate for auto
chilly pond
this seems like a prime candidate for `auto`
yes, it's just an example
grand gulch
I love C++ (not an actual line from source)
```c++
lib::locked_ptr<filesystem::i...
i hope it does an optimization like make_shared by embedding the mutex inside the struct itself and doing one single allocation
light cosmos
I'm guessing that this is not so much a "smart" pointer as it is a wrapper type coupling the pointer with a hold on the Mutex.
or nevermind
I misread.
worn sierra
stupid pointer
light cosmos
I'm guessing that this is not so much a "smart" pointer as it is a wrapper type ...
anyway this is what instance.lock() would return. :-)
polar lance
stupid pointer
maga pointer
chilly pond
i hope it does an optimization like make_shared by embedding the mutex inside th...
I'm trying to do that but I also need to be able to assign locked_ptr<derived class> to locked_ptr<base class>
and base class can be abstract
chilly pond
anyway this is what `instance.lock()` would return. :-)
indeed
grand gulch
I'm trying to do that but I also need to be able to assign locked_ptr<derived cl...
how does it make sense to assign a unique ptr?
chilly pond
it's shared, not unique
grand gulch
oh
chilly pond
I need to be allocating base and derived classes, not some storage type containing them, otherwise ub will smite me
if that makes sense
grand gulch
placement new?
chilly pond
sure, but I'm stuck on coming up with ideas
tbh placement new solves a different problem
chilly pond
i hope it does an optimization like make_shared by embedding the mutex inside th...
I think I did it
"think" because it works but I feel like something is not right
@light cosmos could you take a look, please?
especially class storage part
light cosmos
<@492393383273168906> could you take a look, please?
you are mistakenly assuming that my judgement of others' templated C++ code is trustworthy
but yeah sure, I'm having a look
chilly pond
on lines where I use alignof I would prefer to have used offsetof if I could make it work with non-pod types
light cosmos
Is the storage::storage(make_locked_tag_t, Args &&...); constructor exception-safe?
light cosmos
The requires(std::is_base_of_v(...)) storage(...) etc. "casting" constructors are definitely worth making sure that they are correct.
chilly pond
yes, most of my doubts are with those 2 constructors
light cosmos
Your class locker stores objects and locks adjacent to each other --- which is fine, except when you cast from/to something which is not at offset zero from the parent class
This can happen with multi inheritance
chilly pond
sorry I don't quite understand what you mean
light cosmos
If you have this:
struct Foo { void *foo; };
struct Bar { void *bar; }
struct Baz : Foo, Bar { /* ... */ };
one of Foo, Bar is stored at an offset from Baz (i.e. (Bar *) baz == (Bar *) ((uintptr_t) baz + 8) or something)
chilly pond
sure
light cosmos
currently, with the way your 'buffer' works, this breaks
this is one of the reasons why std::shared_ptr has separate CB and object pointers.
so that the object pointer can point "into" the object
chilly pond
currently, with the way your '`buffer`' works, this breaks
I don't get how though
ah I do
light cosmos
If you have this:
```c++
struct Foo { void *foo; };
struct Bar { void *bar; }
st...
e.g. with this, Bar might be at offset 8 from Baz
but you don't account for that when moving/copying the pointer
If you want correctness, I would advise you to move the Lock into your own "control block" of sorts, using the same approach as shared_ptr does.
This might require writing your own shared_ptr because I don't think there's a way to expand the control block with your own stuff.
chilly pond
This might require writing your own shared_ptr because I don't think there's a w...
I could store it in the deleter object
isn't that part of the control block? (I checked: yes)
light cosmos
possibly
but can you get a hold of the deleter for when you need to... take the lock?
chilly pond
but can you get a hold of the deleter for when you need to... take the lock?
std::get_deleter<type>(shared_ptr)
I don't understand how I would solve the probem with a control block though
do I store the offset in it?
how would I get that
light cosmos
no, so the way shared_ptr works is you have basically this:
class shared_ptr {
control_block *cb;
T *ptr;
};
in the typical scenario, (uintptr_t) ptr == (uintptr_t) (cb + 1) (i.e. they are allocated next to each other)
if you cast a shared_ptr, cb stays the same but ptr may change
light cosmos
``std::get_deleter<type>(shared_ptr)``
this is actually pretty cool if you can get it to work.
light cosmos
no, so the way shared_ptr works is you have basically this:
```C++
class shared_...
basically you would implement shared_ptr semantics yourself (with your own refcounting etc.) but include a Lock in the control block.
chilly pond
one of `Foo`, `Bar` is stored at an offset from `Baz` (i.e. `(Bar *) baz == (Bar...
apparently static_cast can correctly convert Baz* to either Bar* or Foo*
but I still need the lock to be in the control block, to fix those two horrendous constructors
light cosmos
apparently static_cast can correctly convert ``Baz*`` to either ``Bar*`` or ``Fo...
yes it can
although I expect things to break if you cast it via a void * or uintptr_t
chilly pond
I use the correct types there
light cosmos
e.g. static_cast<Bar *>(static_cast<void *>(baz));.
light cosmos
e.g. `static_cast<Bar *>(static_cast<void *>(baz));`.
this can break
light cosmos
e.g. `static_cast<Bar *>(static_cast<void *>(baz));`.
but this is one thing which is very good to be aware of.
It breaks because you first cast to void * -- no offset applied, then you cast from void * and you have effectively forgotten to apply the offset.
chilly pond
it's not possible to do it with a single allocation only while using a custom deleter
light cosmos
What will you be doing instead?
IMO using what you've written here and disallowing multi-inheritance (since it is a very uncommon thing anyways) is a valid approach.
chilly pond
What will you be doing instead?
find a workaround of course
I believe using allocate_shared with a custom allocator will do the trick
{
struct abcd
{
int a;
abcd(int b) : a { b } { log::println("constructor"); }
~abcd() { log::println("destructor"); }
};
auto obj = lib::make_locked<abcd, lib::spinlock>(5);
log::println("value: {}", obj.lock().value().a);
log::println("value: {}", obj.lock().value().a = 23);
log::println("value: {}", obj.lock().value().a);
}
output:
allocating
constructor
value: 5
value: 23
value: 23
deallocating
destructor
@light cosmos
broken beacon
This is some advanced lifetime extension bullshit
chilly pond
I'll test it with multiple inheritence as well, but should work fine
broken beacon
All this effort just for a mutex?
I will admit it's pretty cool to see work though
light cosmos
I'll test it with multiple inheritence as well, but should work fine
yeah this is the nasty case
light cosmos
```c++
{
struct abcd
{
int a;
abcd(int b) : a { b } { lo...
this I expected to work with the original code you linked.
chilly pond
indeed, but this is single allocation
chilly pond
yeah this is the nasty case
{
struct base1 { int a; };
struct base2 { int b; };
struct der : base1, base2 { int c; };
auto derived = lib::make_locked<der, lib::spinlock>();
{
auto locked = derived.lock();
locked->a = 1;
locked->b = 2;
locked->c = 3;
}
log::println("derived->a = {}", derived.lock()->a);
log::println("derived->b = {}", derived.lock()->b);
log::println("derived->c = {}", derived.lock()->c);
{
lib::locked_ptr<base1, lib::spinlock> base1_ptr { derived };
log::println("\nbase1_ptr->a = {}", base1_ptr.lock()->a);
base1_ptr.lock()->a = 4;
}
{
lib::locked_ptr<base2, lib::spinlock> base2_ptr { derived };
log::println("base2_ptr->b = {}\n", base2_ptr.lock()->b);
base2_ptr.lock()->b = 5;
}
log::println("derived->a = {}", derived.lock()->a);
log::println("derived->b = {}", derived.lock()->b);
log::println("derived->c = {}", derived.lock()->c);
}
I believe this should cover it, right?
light cosmos
```c++
{
struct base1 { int a; };
struct base2 { int b; };
struct de...
yeah probably
with the old gist implementation this would probably give not the results you expect (it's fun to try it actually)
chilly pond
yeah probably
derived->a = 1
derived->b = 2
derived->c = 3
base1_ptr->a = 1
base2_ptr->b = 2
derived->a = 4
derived->b = 5
derived->c = 3
works just fine
light cosmos
https://gist.github.com/ilobilo/160a6cf52ff32c8daf47636faf84ca3a
with this code?
chilly pond
nope, with the new one
chilly pond
I still think it can be improved
the size of the locked_ptr is 32 bytes compared to 16 for the old one
light cosmos
because the lock pointer has two shared_ptrs now?
chilly pond
it has one shared ptr and two pointers pointing to the data inside that shared_ptr
shared_ptr is 16 bytes
light cosmos
yeah... if you want to cut it down to two pointers, you can implement shared ptr semantics yourself
light cosmos
it has one shared ptr and two pointers pointing to the data inside that shared_p...
you can reuse the shared_ptr as the pointer to the object
chilly pond
multiple inheritance strikes one again
the object that it's currently accessing isn't necessarily at the address of the data that shared_ptr holds
light cosmos
yeah but shared_ptr can deal with that
light cosmos
shared_ptr points to the control block (which you don't use), an object within the allocation (which you would use with this scheme), you have an external raw pointer to a Lock within the same allocation. this is one possible solution.
AKA:
struct lockable_shared_ptr {
shared_ptr<T *> object;
Lock *lock;
T *get_pointer()
{
return object.get();
}
Lock *get_lock()
{
return lock;
}
};
I reduced it to 24 bytes by just putting the lock at the start of the held data, instead of storing a pointer to it without knowing it's location
error: cannot yet mangle expression type OffsetOfExpr
chilly pond
sonic copper
should I switch to cmake
use a shell script
golden kiln
should I switch to cmake
.sh team ๐
tame jolt
should I switch to cmake
what are you using currently
chilly pond
xmake
tame jolt
oh, never heard of it
chilly pond
because they're nice
would you use headers if you had the option to use modules?
also cmake has modules now
worn sierra
would you use headers if you had the option to use modules?
what's the diff
chilly pond
include is just text paste
chilly pond
<https://en.cppreference.com/w/cpp/language/modules.html>
with modules you export only what you want
worn sierra
this seems like headers with extra steps
or rather, what rust does
this is why i hate c++
chilly pond
what
remote valve
what is that?
Some fucked up thing that was used to compile x11 apps
worn sierra
there's a trillion ways to do the same thing, but with worse syntax
chilly pond
it's a new feature bru
remote valve
Only time I saw it was when porting xfishtank for astral
And the fact that I chose to just manually compile the c files says a lot about imake cross compiling
chilly pond
the thing is that I have never written anything in cmake
so I'd have to learn it first
past sky
would you use headers if you had the option to use modules?
Different names for the same thing
chilly pond
nah uh
modules speed up compile times as well
you don't have to recompile code from included headers for every source file
I can just do import std and I have everything i need
chilly pond
I started working on a very very simple vmm
and I updated the scheduler a bit
it should be a bit less bad (it allocated in the scheduler before), but I'm no expert
chilly pond
hmmm if the current thread vruntime is the lowest in all threads, should I still switch to a new thread or continue executing the current one until it's vruntime gets high enough?
currently I still switch, regardless of the vruntime of the thread that was just running
my reasoning is that if the current thread was sleeping for a long time and has just woken up, it would block every other thread from running for a while.
switching anyway gives other threads some chance to run as well
does this make sense?
light cosmos
I'm pretty sure CFS handled this by clamping the vruntime of newly woken tasks to the minimum and maximum vruntime in a queue, plus minus some window of allowance, not sure what they do nowadays though.
chilly pond
hmm makes sense
chilly pond
I'm pretty sure CFS handled this by clamping the vruntime of newly woken tasks t...
should I check for timeout and wake up threads from the scheduler itself or have some other worker thread for them like the one for dead threads?
chilly pond
golden kiln
why does this look so sus
chilly pond
wdym
chilly pond
remote valve
why does this look so sus
dead body reported
https://tenor.com/view/amongus-amongsdp-black-emergency-meeting-black-emergency-meeting-gif-18720662
chilly pond
oh lol
golden kiln
dead body reported
tbh instead of reap i read rape (accidentally) ๐ญ
light cosmos
should I check for timeout and wake up threads from the scheduler itself or have...
It's best not to tie timeouts directly to the scheduler core itself but to have a generic wake_up_thread that you can use for this. Typically you keep some kind of global queue of threads sorted by timeout, possibly instantiate it per CPU (but you need to remove entries on remote CPUs in case a thread migrates when waking up), and use some generic timer infrastructure to drive it.
chilly pond
is bug_if_not a bad name for assert?
because my previous name (ensure) doesn't really explain what the check is for
golden kiln
is bug_if_not a bad name for assert?
no
light cosmos
is bug_if_not a bad name for assert?
why not BUG_ON(!condition)?
chilly pond
why not `BUG_ON(!condition)`?
I was too lazy to add ! to every existing assert :P
maybe I'll change it
chilly pond
okay I renamed it
golden kiln
okay I renamed it
isn't ensure is better than bug_on or bug_if_not
chilly pond
ensure has a slightly different definition compared to assert or bug_on(!
grand gulch
`BUG_UNLESS(condition)`
That's a thing in Linux right
grand gulch
I've seen DIE_UNLESS I think
remote valve
@chilly pond do you use slabs and if so how did you get slabs to go 8 mil on uacpi
chilly pond
I switched to frigg's slab allocator as it was faster than mine
chilly pond
I don't know how I got 8 million
keep in mind that it was on 9950x3d
remote valve
I wrote slabs down to the paper and I still dont really get good scores, maybe I am doing something wrong elsewhere
chilly pond
have you profiled the uacpi kernel api functions?
maybe spinlocks or mutexes are slow
remote valve
Like a long time ago, my kernel and uacpi changed a lot since then so maybe I should do that again
chilly pond
hmmm
you can also optimise your memcpy for certain sized copies like managarm does
phd memcpy
and O3
remote valve
Hmmm
chilly pond
The one in the uacpi leadrrboard
the real trick is "hey @ infy could you test this iso on your 9950x3d?"
I get 4 mil on my cpu
remote valve
On my cpu I get like 1.5 mil ๐
But I think I know what might be up, it might be my uacpi_kernel_map
I could probably make that faster and it, alongside unmap, are called a ton I think
I need to benchmark to be sure
vernal moss
I wrote slabs down to the paper and I still dont really get good scores, maybe I...
btw, do you do magazines?
remote valve
btw, do you do magazines?
I do
grand gulch
we BACK 
chilly pond
pfndb done
now I need to modify my buddy allocator so I can actually coalesce buddies
chilly pond
1 mib used for mapping pfndb for every 4 gigs of ram with 16 byte struct page seems correct
does it?
remote valve
yeah like thats like two pointers
chilly pond
hmm I can fit a physical page address in 36 bits can't I
past sky
1 mib used for mapping pfndb for every 4 gigs of ram with 16 byte struct page se...
Yeah mine is about that, about 20 byte page struct
past sky
but what if the user has 2^52 bytes of ram <:bigplead:1299010072411639909>
I wonder how much money that would cost
Chat gpt is good for bullshit like this lol
chilly pond
now I need to modify my buddy allocator so I can actually coalesce buddies
I hope this works on the first try
(it wont )
chilly pond
well
unexpected but it appears to be working on the first try
good enough :P
41 bits used in the struct page
I haven't thought of a way of doing it with fewer bits
chilly pond
It's best not to tie timeouts directly to the scheduler core itself but to have ...
are these extra delays acceptable for sleep(1s)?
it's a bit more than 1 second
I want it to be accurate
worn sierra
are these extra delays acceptable for sleep(1s)?
don't forget actually printing also takes some time
chilly pond
not that much
the delay was lower when I was waking them up from the scheduler itself, not from a separate thread
light cosmos
are these extra delays acceptable for sleep(1s)?
what's your timer interrupt frequency?
chilly pond
6 ms so 1000/6
light cosmos
ideally you should be within one tick of it, e.g. if you drive the lAPIC at 1000HZ and you wait for 1000ms, you should be no later than 1001ms when load is low
light cosmos
6 ms so 1000/6
in that case, this LGTM
chilly pond
this is not completely abandoned
I added hard and soft links
:P
and set up jinx and minimal userspace
vmm worksโข (it can map)
tame jolt
I added hard and soft links
Fancy
worn sierra
chilly pond
https://tenor.com/view/osamason-mj-michael-jordan-michael-jordan-gif-14320364864...
I don't understand this gif
golden kiln
I don't understand this gif
what is rbtree
golden kiln
where do you use it
remote valve
how shit is this code <https://github.com/ilobilo/ilobilix/blob/3cea6963c47064b9...
Inspired by frigg lil vro
chilly pond
Inspired by frigg lil vro
well just template<typename Type, rbtree_hook Type::*Member, typename Less>
how else would I use a hook intrusively
remote valve
Idk I dont speak c++ lmao I was just joking cuz of that
I still need to implement a red black for astral and to switch a few things over to it
worn sierra
Idk I dont speak c++ lmao I was just joking cuz of that
me neither
grand gulch
Nice to see
chilly pond
fiery grotto
I wonder what I'm doing wrong
you're calling initialize twice
or it's garbage to begin with
chilly pond
you're calling initialize twice
that line is in mlibc interpretermain
chilly pond
then you're loading in the mlibc ldso incorrectly
yeah that was the issue
I wasn't clearing the memory between filesz and memsz
golden kiln
is ilobilix alive now
remote valve
Having creat() as a separate syscall than open is an interesting choice
limpid jasper
linux has a separate syscall for creat as well
limpid jasper
backwards compatibility i'd guess
chilly pond
Having creat() as a separate syscall than open is an interesting choice
:P
I'm doing linux syscalls
grand gulch
I'm doing linux syscalls
Linux compat friend?
chilly pond
yep
chilly pond
tbh it's easier to follow a design that's already made, instead of coming up with a new one
grand gulch
Fair
chilly pond
I'll do process groups, sessions and tty next
I do have midterms this week so we'll see
golden kiln
I'll do process groups, sessions and tty next
when bash port
chilly pond
what libc you want port
mlibc
chilly pond
when bash port
already have it
I just need to implement a few more syscalls
I'll push when I get home
golden kiln
isnt these syscalls are enough for bash
chilly pond
maybe but I don't have a tty yet :P
I get div by zero somewhere in mlibc
I need to fix that as well
chilly pond
18553 loc and doesn't even run bash 
grand gulch
18553 loc and doesn't even run bash <:KEKW:913708372329644042>
Sounds like uacpi
chilly pond
lol
tame jolt
18553 loc and doesn't even run bash <:KEKW:913708372329644042>
how do you have so many loc
chilly pond
stuff
remote valve
Astral has like 30k sloc
tame jolt
my kernel has 10k loc
grand gulch
Astral has like 30k sloc
It runs like literally everything
remote valve
It runs like literally everything
Not a (good) web browser
grand gulch
Also no kde I guess
tame jolt
chilly pond
Not a (good) web browser <:meme:575445094589661215>
astral chromium marathon when
grand gulch
Astral needs a drm impl ngl
tame jolt
Also no kde I guess <:trl:829316641191886888>
i've never seen anyone run kde in a hobby os
i'd love to see that someday
remote valve
Astral needs a drm impl ngl
Speech is graticious, mail modifications
grand gulch
i've never seen anyone run kde in a hobby os
Yes because it requires a lot of stuff
grand gulch
Speech is graticious, mail modifications
Lmfao
chilly pond
i've never seen anyone run kde in a hobby os
managarm has kde apps
remote valve
Idk how drm works at all
tame jolt
managarm has kde apps
true
grand gulch
Idk how drm works at all
device in /dev/dri and a few ioctls some of them GPU specific some generic
Some ioctls just do modesets, some allocate buffers, some submit userspace command buffers to the GPU
Thats kinda it
grand gulch
You dont even need the command submission part technically, a lot of stuff works with dumb framebuffers
So just the modeset api
Like managarm
remote valve
Minecraft in astral with virtio gpu hardware accel 2026
chilly pond
grand gulch
Minecraft in astral with virtio gpu hardware accel 2026
Damn thatd be insane
tame jolt
Minecraft in astral with virtio gpu hardware accel 2026
i wonder how minecraft 4k runs rn
yk, the 4kb version
remote valve
Fullscreen on a 1024xsomething it ran at like 10-20 fps I think
tame jolt
oh you tried it already?
tame jolt
I read 4k as resolution
lol
worn sierra
18553 loc and doesn't even run bash <:KEKW:913708372329644042>
13k here
blissful sand
18553 loc and doesn't even run bash <:KEKW:913708372329644042>
Couldn't be me ๐ (14 kloc so far)
chilly pond
I made a clanker make mermaid diagrams for my 2 initgraphs
one running before the scheduler and the other on a kernel thread
chilly pond
what is causing this?
it's supposed to be a file instead of \x1d
is my ld.so loading wrong?
chilly pond
hours debugging an issue with locks only to realise that I shouldn't have used a lock there
timber terrace
I'm trying to switch to cmake from xmake
what changes?
timber terrace
is it simpler to use?
timber terrace
ah, to cmake
chilly pond
and it's considerably slower
golden kiln
and it's considerably slower
write own
timber terrace
Reject advanced build systems use makefiles
cmake uses makefiles TooTroll
polar lance
Ilobilix running Minecraft when
chilly pond
probably never
chilly pond
cmake uses makefiles [TooTroll](https://cdn.discordapp.com/emojis/12327277756020...
ninja
required for c++ modules
polar lance
probably never
chilly pond
begone rust user
go back to the crate from whence you came
broken beacon
Get oxidized
remote valve
I'm trying to switch to cmake from xmake
Wtf first time I hear of xmake
Is it like imake thats something very used in olden unix
golden kiln
why are you panicking on this
golden kiln
i mean exit_group
chilly pond
real
fiery grotto
have you considered implementing symbol compression?
chilly pond
I have it
fiery grotto
wtf
chilly pond
have you considered implementing symbol compression?
I have a string passed in as a template argument and I think it's encoded in the symbol
it's quite unnecessary
I could remove it
fiery grotto
is that a __user pointer i see?
chilly pond
yea
fiery grotto
damn
chilly pond
__attribute__((address_space(1)))
chilly pond
does it have an actual purpose?
you can't access it unless you cast it using (__attribute__((force)) type *)ptr
and I do that in copy_from/to_user
fiery grotto
oh that's fun
remote valve
What the fuck c++ moment
chilly pond
oh that's fun
I learned about it from @worn sierra actually
fiery grotto
What the fuck c++ moment
me when do_the_thing<"oh wait i can pass a fucking string as a template argument">();
mossy tendon
``__attribute__((address_space(1)))``
i thought that was a linux kernel sparse thing
chilly pond
constexpr comptime_string panic_message { "an unfortunate occurrence, which was definitively supposed to have been avoided or precluded, has regrettably come to fruition in the present temporal reality." };
lmao
worn sierra
i thought that was a linux kernel sparse thing
no
well not exactly
it's a clang extension
which does the same thing as in sparse
mossy tendon
yea
chilly pond
hmmmm
what if I use thread_local for cpu local stuff
instead of whatever the hell I have currently
or both
grand gulch
cc @limpid seal
chilly pond
it seems surprisingly easy
chilly pond
instead of whatever the hell I have currently
I could use gsbase for thread struct to access is from a syscall handler after swapgs
because I don't think there is such thing as swapfs
chilly pond
it seems surprisingly easy
yea just a few dozen lines
limpid seal
The problem with it is that compilers assume that gsbase never changes
So if the code ever gets scheduled on another core, even if you have a compiler barrier, it might still use the value it got before
chilly pond
The problem with it is that compilers assume that gsbase never changes
gsbase?
or fsbase?
chilly pond
So if the code ever gets scheduled on another core, even if you have a compiler ...
any way solve that problem?
light cosmos
I could use gsbase for thread struct to access is from a syscall handler after s...
this can be done. however you will effectively have per-thread, not per-cpu data in gsbase now. (can be worked around by pointing to per-cpu data in the per thread data)
chilly pond
yes I currently have that
I think I worded the original sentence wrong
"then I'll use gsbase just for thread struct to access is from a syscall handler after swapgs"
chilly pond
So if the code ever gets scheduled on another core, even if you have a compiler ...
hmmm I don't quite get this
you mean if a kernel thread is migrated to another core?
light cosmos
hmmm I don't quite get this
you mean if a kernel thread is migrated to another c...
yeah. the compiler can and will cache the value of GSBASE and it will screw you over.
chilly pond
then I'll just not move kthreads :P
light cosmos
which is why it's okay to use thread_local for thread-local data but not CPU-local data
limpid seal
imagine hat after inline and optimizations you have a function like so, and that the barrier is basically a schedule of the code into another core
even if you had correctly disabled preemption around each of the accesses, the compiler would still cache the base
if you can ensure that the same code path will never run on a different core, then you can use it
but otherwise you risk running into really really weird bugs
grand gulch
linux does have cpu_read_stable() as well which mimics this behavior
but its only used for get_current() on x86
(and a few other misc helpers)
it uses inline asm for it
and by default its always just __seg_gs deref
chilly pond
I don't think this is worth it
golden kiln
https://github.com/ilobilix
ilobilix supports aarch64 ???
chilly pond
well
I don't think it builds anymore
I haven't maintained it
my arch abstraction is so shit
nothing is designed properly
chilly pond
and split the userspace and kernel to separate repos
I still haven't fully set up the new build system
there's currently no way to run the os or build the modules
chilly pond
I just hooked up a basic console (just write) (because I don't have a tty) to see if it even worked
it does
fiery grotto
how can a module be noarch
chilly pond
how can a module be noarch
it's not a noarch binary
it's for modules that are not for a specific architecture
remote valve
I don't get why setting process group is failing with EBADF
/dev/tty missing?
chilly pond
chilly pond
the ever-dreaded todo list grows larger every passing moment
chilly pond
๐ฅ ๐ฅ ๐ฅ
tame jolt
My pselect is a mlibc wrapper ๐ญ
I don't even implement a wrapper in the kernel
Oh but this is doing Linux compat right
worn sierra
step 1) implement ppoll
step 2) have pselect use ppoll
i mean
is this such a bad idea
remote valve
Nah
polar lance
step 1) implement ppoll
step 2) have pselect use ppoll
sounds like something I should do
grand gulch
sounds like something I should do
Since you're doing Linux compat just do epoll
polar lance
good idea
chilly pond
hmmm I tried running musl and I'm getting a page fault before any syscall is called
probably a problem with elf loading
yep
I was loading interpreter at a wrong address
chilly pond
I'm thinking if I should use buildroot and musl instead
it's shrimply so much easier
remote valve
using musl while doing linux compat is an interesting choice :P
chilly pond
@polar lance does it
remote valve
you can pick between using a complete libc or helping the community and by choosing musl you do neither
grand gulch
<@151016183401938944> does it
iirc its only because hes too lazy to implement syscalls it needs
chilly pond
lol
polar lance
<@151016183401938944> does it
Indeed
golden kiln
I think glibc *might* need futex
just stub futex syscalls
they can be required only for pthreads
chilly pond
me when the
grand gulch
its optional
grand gulch
we've talked about it quite a lot on the maestro's page i think
or thread ig
its not that bad to implement
chilly pond
its not that bad to implement
prs are welcome 
mossy tendon
it's just not in any syscall table or manpage I've searched in :P
what syscall table are you searching that doesnt include it
mossy tendon
https://x64.syscall.sh/ and https://chromium.googlesource.com/chromiumos/docs/+/...
i use https://filippo.io/linux-syscall-table/ which is up to date
it doesnt show the arguments in the table though it has links to both the manpage and the linux source
chilly pond
not a problem
mossy tendon
wait i might be stupid
Double click on a row to reveal the arguments list. Search using the fuzzy filter box.
lol
mossy tendon
yea
grand gulch
polar lance
we've talked about it quite a lot on the maestro's page i think
I still didn't implement it
chilly pond
I think I have tty basics all implemented
I just need to do line discipline and hook up some way to input characters
probably from serial
having coreutils installed makes bash invoke pipe2
I've got to implement that too
then clone, futex, ppoll, pselect
golden kiln
then clone, futex, ppoll, pselect
pselect when you have ppoll is waste of time
chilly pond
insanity
blissful sand
that looks like it'll be fun to debug ๐
chilly pond
wdym why
worn sierra
what's this doing
chilly pond
different kinds of ringbuffers
single/multi producer/consumer
for example some things don't need to be atomic depending on the type
so it's better optimised like this
broken beacon
This is overoptimized tbh
Have you profiled and ran into ringbuffers being an issue? I bet not.
chilly pond
I haven't even utilised those ringbuffers yet
remote valve
20k loc for a hello world
grand gulch
rookie numbers
chilly pond
gotta do sys clone
and I still haven't written that tty line discipline thingy
and I need to write a proper vmm
the one I have currently sucks
probably doesn't even work properly
tame jolt
gotta do sys clone
for what?
tame jolt
well, you could just implement fork
tame jolt
true
chilly pond
init: error while loading shared libraries: /lib64/librc.so.1: unsupported version 0 of Verneed record
hmmmmmmmmmmmmmmmmmmmmmmmmmm
chilly pond
what could cause this?
chilly pond
I was overwriting the modules memmap
(where initramfs was loaded)
well I haven't tried running openrc yet
I just fixed that
yeah still doesn't work
rugged cipher
do I need to add \r or something now
Yes
rugged cipher
I just edited my printf/putc to detect \n shove a \r before flanterm
chilly pond
I started working on tty line discipline
with some "inspiration" from toaruos
I just need to do read and write and it should be done
oh and ioctl
then maybe I'll write a quick ttyS driver
can't forget ptys
maybe glibc bash after that 
that needs futexes iirc
worn sierra
with some "inspiration" from toaruos
remote valve
with some "inspiration" from toaruos
speech bubble meme of that one person who copied toaruos
rugged cipher
speech bubble meme of that one person who copied toaruos
Who did that lmfao
blissful sand
Who did that lmfao
sasdallas
chilly pond
time to get back to working on tty
I had to change a few things before doing read and write
chilly pond
okay read and write done
chilly pond
// TODO count is 73 and rising
broken beacon
TODO count never decreases in any good project
chilly pond
lol
chilly pond
/dev/ttyS0
I'm pretty happy with how this turned out
whole thing is like 1.3k lines (without any ioctls implemented)
excluding any tty drivers like serial or pty
grand gulch
Nice
grand gulch
Damn
golden kiln
glibc found more bugs in my "temporary" buggy vmm
with MAP_FIXED right
chilly pond
one of the issues was with that, yes
golden kiln
one of the issues was with that, yes
i had a lot issues with this too
grand gulch
i had a lot issues with this too
How ๐
golden kiln
How ๐
my vmm was stucking when there's hint on already allocated memory and my unmap just frees all memory which was allocated for this mmap, not part of this
chilly pond
getdents works (no fork/clone or exec yet so I just pressed tab)
pselect6 as well
but I don't really like the implementation
chilly pond
I love it when stuff just works
broken beacon
Bash port?
grand gulch
Linux compat?
chilly pond
yes
grand gulch
big
chilly pond
hmmm the terminal is incredibly slow when printing from a scheduler thread
I don't know why
rugged cipher
Do you have a lock on it or somthing?
chilly pond
what
rugged cipher
Like a spinlock on the terminal?
Atleast for flanterm it is not thread safe so Iโm pretty sure you need a lock there
chilly pond
initramfs parsing is slow as well, I doubt it's the terminal
rugged cipher
Ahhh sorry
chilly pond
bruh it booted up fine one (1) time
then it went back to being slow
damn it was because of smp
well, is
chilly pond
bruh it booted up fine one (1) time
I've been tricked again by this