Because if you construct something that gets moved into something else halfway through, the former thing now gets removed from the things to defer.
#Zinnia
hybrid island
near tartan
i read gnu cleanup instead
near tartan
it makes the variable declarations more verbose
that's true
hoary cave
that's why c++ is beautiful :^)
near tartan
near tartan
i mean i don't hate c++
i can just not use the features i don't need
but i don't know how it will work with modules
hoary cave
well really you don't need to even use them
it's a thing but you don't even use them that often
you either use make_shared/make_unique
or your way of allocating memory which hopefully has support for new-in-place
you could of course make it work with operator new/delete if you like
near tartan
tf
near tartan
does c++ have a stable abi across SOs? or is it like on rust
hoary cave
yes
near tartan
yooo
hoary cave
well i'm not sure if it's stable stable stable
like c
but you can 100000% link a shared library
with c++ symbols
near tartan
nice
hoary cave
as long as you use the same compiler version for both you will be fine
it will probably also work across different versions
near tartan
well the idea with modules is not to compile modules standalone
but instead so you can opt out of things you never use
hoary cave
probably
near tartan
pog
near tartan
sick flax
I’ll cross post it here. VC status unknown today, I give it a 25% chance. Tower is acquired tho so we are ballin the next 3 weeks
hoary cave
pog
storm bobcat
but that's cringe anyways
Wouldn't you need some kind of external interface in rust anyway?
storm bobcat
It's the simplest way and you can still provide a C++ interface
hybrid island
the simplest way is to export c++ symbols
Just a small heads up: Those don't encode return type so be careful about changing the return type of a function exported this way.
near tartan
wdym
hybrid island
C++ mangling encodes parameters and namespaces, but not return values.
near tartan
why does that matter?
hybrid island
Only if you decide to change the return type
hybrid island
If you change the return type in a kernel function referenced by a module, but forget to recompile the module, you'll run into strange bugs.
near tartan
oh that
hybrid island
Instead of when a param is changed, which would cause it not to dynamically link
near tartan
the build signature takes care of that
only modules that fit to the loaded kernel are loadable
hybrid island
Sure
It's not a big thing, just something I noticed when I looked into C++ mangling and thought was odd.
hybrid island
wdym by custom containers?
near tartan
vector
hybrid island
Oh custom impls of container types?
near tartan
yes
hybrid island
Yeah C++ STL sucks IMO
near tartan
because
a) allocations can fail
b) i despise the stl
hybrid island
TBH I should probably do something about "alloc can fail" stuff. Because even my C code doesn't handle that properly.
late bramble
U not doing a rust kernel anymore?
distant cypress
The C++ STL is actually very well designed for most usecases. In general kernels are hard because a kernel often has very specific requirements on the implementation of various things.
near tartan
U not doing a rust kernel anymore?
yeah
it kinda takes the fun out of it because you need a workaround for almost anything
next cairn
it kinda takes the fun out of it because you need a workaround for almost anythi...
not true
grave peak
flair checks out
next cairn
yes
you used to need workarounds, now almost everything has a specific way of being handled with rust
grave peak
@near tartan can u explain what u needed workarounds for
storm bobcat
you *used to* need workarounds, now almost everything has a specific way of bein...
nah
rust still sucks
eternal wharf
It's not a big thing, just something I noticed when I looked into C++ mangling a...
i mean it's redundant information, you cannot overload on the return type alone
grave peak
And thats why Linux modules hash the goddamn source file for exported functions 
next cairn
<@173337436989030401> can u explain what u needed workarounds for
.
i've gotten to userland and filesystems without needing workarounds, so what is it
just curious
near tartan
well for one, you need a nightly toolchain, even though the actual version is stabilized
i needed a bunch of unstable features
next cairn
well yeah
near tartan
working with Arcs everywhere requires you to put locks everywhere and do like nested structures
next cairn
they argue about the finalized api
next cairn
working with Arcs everywhere requires you to put locks everywhere and do like ne...
why
are you needing arcs in os dev
😔
near tartan
why not
like
filesystem comes to mind??
even in other langs that needs refcounting
next cairn
The real issue is almost always A. someone attempting to write rust code like it's C, or B. rust being so opionated the "correct" way feels annoying to do
near tartan
I don't see how that's an answer to my question
you definitely need arcs because you cannot possibly know the lifetimes
next cairn
what filesystem were you trying to do
next cairn
then i extra don't see why you needed arcs
vfs lifetime is just: Yes
Entire program
near tartan
????
near tartan
this makes 0 sense
next cairn
it doesn't need a lifetime it's there the entire duration of the program
near tartan
take struct inode/vnode for example
there may be multiple references to it at the same time
and you don't know how long it's going to live
next cairn
mutex guard my beloved
near tartan
working with Arcs everywhere requires you to put locks everywhere and do like ne...
.
which brings me to my point
next cairn
it's multithreading your options are locks or some other magic
😔
oh well
just sad to see rust abandoned in corner
near tartan
rust is not a bad language
just not optimal for a kernel
also yeah, dont even get me started on memory usage
near tartan
well yes but linux also doesn't use alloc afaik
rust also used so much stack memory that it overflowed
like 8 functions deep
next cairn
you don't have to use alloc in rust
next cairn
its no different in C
needing to allocate stuff, requires you to setup allocations
and handle things
next cairn
because many no std crates want it
write them yourself 🔥
next cairn
GASP
near tartan
then i extra don't see why you needed arcs
do explain how you achieved this
marble salmon
are you needing arcs in os dev
?
You certainly do need Arc<>s in a lot of cases
in osdev
You can't just make your struct File 'static, otherwise you can only have a static number of files
next cairn
need is a strong word
marble salmon
This is not a property of Rust, the same is true for C (except that it's less ergonomic in C because you have to do the ref counting manually and it's easy to get wrong)
next cairn
static_mut_fs
near tartan
this makes me wonder how you implemented this
next cairn
🔥
near tartan
because it sounds like you just did it wrong 
marble salmon
Btw Marvin, i said this before but I'm pretty sure Managarm's VFS has no data structure at all that can't be literally translated to Rust
W/o running into borrowing issues
next cairn
vfs = include_bytes!
near tartan
Btw Marvin, i said this before but I'm pretty sure Managarm's VFS has no data st...
yep
near tartan
that still needs arcs
marble salmon
@next cairn you're just trolling at this point
marble salmon
then explain how that's supposed to work
next cairn
you can once cell mutex guard a ramfs
marble salmon
you can only have a finite number of objects that are 'static
sure but that's not a real VFS
that's a static archive
near tartan
there can be more than one ramfs at once too
next cairn
scary
marble salmon
you can't create files in it
and you can't take references to the files
inside the Mutex
so you have to access them by path each time
great data structure
next cairn
peak
marble salmon
yeah
that's like saying: oh lifetimes in C are easy, i just don't use pointers and everything is global
@near tartan what part of the VFS are you struggling with?
near tartan
nothing in particular, just having to have this mutex wrapper around everything
next cairn
uh
marble salmon
I'd try to think about the VFS in terms of what traits you need
not how to implement them
next cairn
make dirty cache
don't lock on writes because everything is a lie and it's queues
you got this
I'm not trolling but I'm also not 100% serious
I just know there's supposed to always be ways to avoid arcs
marble salmon
In Managarm, the VFS looks roughly like this:
trait Link {
fn getParent() -> Arc<dyn Node>;
fn getName() -> &str;
fn getTarget() -> Arc<dyn Node>;
}
trait Node {
fn open(flags: OpenFlags) -> Result<Arc<dyn File>>;
// Only supported on directories:
fn getLink(name: &str) -> Result<Arc<dyn Link>>;
fn mkdir(name: &str) -> Result<Arc<dyn Link>>;
// Only supported on symlinks:
fn readSymlink() -> Result<&str>;
// ...
}
trait File {
fn read(size: usize, buf: &mut [u8]) -> Result<usize>;
// ...
}
If you're not trolling with this statement: you need an Arc<> when you have shared ownership. There are not always ways to avoid shared ownership. Nor is it desirable. Arc<> is not evil
near tartan
you have to
next cairn
hmm
near tartan
if you have two hardlinks
pointing to the same data on disk
they're pointing to the same struct in memory
the only way that works is with arc
marble salmon
don't share ownership?
that's not possible if you want to be posix compat, for example because posix has dup()
which is shared ownership of FDs
near tartan
also for scheduling, both the runqueues and syscall handlers need a reference to the active thread
marble salmon
also, if you open the same file twice, you WANT to share ownership of the underlying data structure as it is otherwise a pain to keep in sync
marble salmon
and shared ownership is generally the best performing strategy there is in that situation
marble salmon
accessing an Arc<> is as fast as accessing a raw pointer
next cairn
if Linux uses rc for this issue, and arc isn't slow, then why don't you want to use rust over it?
marble salmon
copying it is faster than locking a mutex
marble salmon
fwiw there are crates like arc_swap
but I don't think it's a problem that Arcs are not mutable
marble salmon
I only very rarely needed an atomic Arc and when I did, it was for some niche performance optimization
near tartan
then keep using rust
tooling is still trash
near tartan
any other c build system
next cairn
rust OS with 500 line Makefile 🔥
marble salmon
https://github.com/menix-os/menix/blob/main/kernel%2Fsrc%2Fgeneric%2Fvfs%2Finode...
I think one issue of this is that your inode type is too concrete
not all FSes will have this inode structure
near tartan
rust OS with 500 line Makefile 🔥
that's what redox does
marble salmon
tbh I also don't see why you don't just use cargo
next cairn
you can't expect to not have a build process just bc cargo is there
makefiles are still common
marble salmon
i mean sure, you need scaffolding on top of cargo
but not using cargo to build the rust files seems weird
next cairn
Idk why you'd choose something even more painful just because cargo didn't provide every step for you 😭
you do
near tartan
wdym painful
next cairn
cargo calls rustc and builds all the stuff, then you use other tools in your makefile
next cairn
wdym painful
Last time I used C it was 100x worse than using cargo and rust
marble salmon
C with Meson is mostly fine
near tartan
meson is sane
next cairn
so idk why youd go with any other language based on "cargo sucks"
near tartan
it's the whole package
marble salmon
but yeah, cargo is also very good except for very weird cases
like, pathing other crates with cargo is a mess
next cairn
but yeah, cargo is also very good except for very weird cases
like what?..
everything is config files
marble salmon
since you usually have committed lock files that don't allow you to do it
next cairn
cargo is great at everything rust as far as I've seen, what is there to hate
marble salmon
so you need to get into your deps, patch or delete the lock files as well etc
recursively
next cairn
so you need to get into your deps, patch or delete the lock files as well etc
huh
lock files keep versions
what're you on about
marble salmon
exactly
near tartan
cargo is great at everything rust as far as I've seen, what is there to hate
it doesn't do what i want to do and that pisses me off
next cairn
what're you wanting it to do?..
near tartan
dynamic modules
next cairn
features?
marble salmon
e.g., when we patch something in rustix to make it managarm compatible, we have to patch all users of rustix to include our rustix version
marble salmon
dynamic modules
that's not a property of cargo, that's just a property of monomorphization
marble salmon
the way you want it to work is just impossible with templates
the same would be true in C++
you have to write an extern API to make it work
near tartan
that's not the issue
marble salmon
even if it's rust -> rust extern
next cairn
._.
near tartan
it's absolutely a problem with cargo
near tartan
yes, but you have no real control over how they're built
meson has no issues in that regard
marble salmon
you can either use rust dylib or cdylibs
both should work if all your modules are rust
next cairn
I don't feel like cargo not doing something it wasn't meant to do is a reason to leave a language altogether
marble salmon
but you do need the explicit extern API
near tartan
I don't feel like cargo not doing something it wasn't meant to do is a reason to...
whats the alternative
marble salmon
i don't think any other build system will help you here
next cairn
whats the alternative
well I'm not sure what you want dynamic modules for to begin with
near tartan
that's one thing i want to have, like no compromise at all
marble salmon
you will need to include the parts of your deps that the module uses inside the module
no matter which build system you use
next cairn
I'm assuming you want some parts compiled in depending on some flags
next cairn
conditional compilation is peak in rust
marble salmon
they just have rust interfaces
vast lotus
I'm assuming you want some parts compiled in depending on some flags
dynamic as in dynamically linked
shared library
next cairn
Oh that
near tartan
like tristate in linux
vast lotus
not dynamic as in can be configured at compile time
next cairn
so making or using dynamic modules?
near tartan
both
next cairn
because rust can target dynamic lib and compile into run, or load them at runtime
vast lotus
the primary issue iirc was how to make it so the user can choose between having a certain module statically linked (compiled in) or dynamically linked
next cairn
you can either dyn or static
near tartan
wat
hoary cave
what lmfao
near tartan
and again, what i have at the moment to experiment with (with meson + c++) does work how i want it to
marble salmon
why don't you just always make modules dynamic?
next cairn
cargo::rustc-link-search=native=/path/to/library/directory
marble salmon
instead of picking at compile time
next cairn
you can pick tho ig
you can link shit statically in build.rs
idk why you would but you can
marble salmon
i guess
but you can exploit some features of shared libs if you always link dynamically
near tartan
i already do
marble salmon
for example, you can give each lib their own symbol namespace
near tartan
maybe i'm retarded
marble salmon
I think the hard part of Rust vs C when making modules is having a proper ABI
and that is completely independent from the build system
in C if you have a const char *foo(int a, long b), this has a well defined ABI
in Rust you need to do
unsafe extern {
fn foo(a: i32, b: i64) -> &'static str;
}
on the consumer side and
extern fn foo(a: i32, b: i64) -> &'static str {
// ...
}
and the producer side
C (by default, unless you're using attribute visibility) allows you to be sloppy with your external symbols while rust doesn't
next cairn
clippy my beloved
marble salmon
i think this will just not work at link time if you don't do it
near tartan
hm
i should try if i can get meson to work with rust
i think the main issue was build-std
marble salmon
if you just do fn foo without extern, rust will pull the code of foo into the consumer crate
next cairn
there's even a way to make your kernel entry point public and call it from uefi-rs code through an import for whatever reason
forever being pe instead of elf
marble salmon
if you just do `fn foo` without `extern`, rust will pull the code of `foo` into ...
no matter if you build a dylib or an rlib
next cairn
😔
marble salmon
no matter if you build a dylib or an rlib
and it should, there is no other way to make this work in the presence of monomorphization
since if foo was generic, the producer would have no way of knowing which specializations of foo should actually be built into itself
near tartan
yes that's true, but that's a not as frequent
a simple hello world module just needs a reference to the loggers
marble salmon
the proper way is still to have a well-defined extern interface
near tartan
i don't really need that. my modules are always supposed to be used together with the same kernel
rusts symbol mangling makes sure you can't do otherwise
marble salmon
sure but then all your dylibs will still have a lot of shared code
In the worse case, all your dylibs will contain the entire core kernel code
near tartan
sure but it's unfeasible to wrap every single kernel function that modules may use in an extern C wrapper
i mean i would still like to use rust, but i need to find solutions for the things that are bugging me
rn it's mostly scheduler code
analog crane
That's what I like so much about Ada, it's super maleable, all the issues I have can just be enabled or disabled at will
https://codeberg.org/Ironclad/Ironclad/src/branch/main/source/pragmas.adc you can have a file like this and enable and disable what you want of the language at will
analog crane
Feature flags don't do as much
near tartan
-fno-rtti -fno-exceptions
analog crane
That's like not what I'm doing
But you wouldn't know because you wouldn't know what the pragmas mean
analog crane
But things like exception propagation, secondary stack, and dispatch rules are less trivial
analog crane
What problems does rust give you for the VFS that you mentioned before?
analog crane
Want to bust
grave peak
marvin i feel bad for u
near tartan
😭
grave peak
no one can understand what ur issue is
near tartan
i can't articulate it either
grave peak
even though they've all seen u struggle with that crap
near tartan
the breaking point was the scheduler issues
i can't for the life of me figure it out
analog crane
You need a healthy amount of fuck it we ball energy I feel
grave peak
back to rust?
marble salmon
sure but it's unfeasible to wrap every single kernel function that modules may u...
Why?
near tartan
core and alloc
marble salmon
A syscall API essentially does that
You don't need to wrap core and alloc
Each module can have its own core and alloc
marble salmon
A syscall API essentially does that
hel's syscall api also exposes all functions necessary to write drivers, so it's possible to provide such an extern API :^)
grave peak
just make a storport-like interface for every driver 
all storport drivers are technically only allowed to use the storport api
which is primarily one function with 999 switch cases
near tartan
hel's syscall api also exposes all functions necessary to write drivers, so it's...
but that's because it crosses priv boundary
there's no other way
marble salmon
What is storport?
grave peak
What is storport?
generic windows interface for modern block devices
all block device drivers use it i think
it also allows you to use NT drivers for nvme/ahci if u implement storport in your kernel
marble salmon
sounds cursed (the strategy of implementing it in your own kernel)
near tartan
oh well
the main issues i need to solve are memory usage (especially stack) and scheduling
grave peak
sounds cursed (the strategy of implementing it in your own kernel)
keyronex does it
near tartan
i'd rather add a linux driver compat layer
grave peak
u cant really do it since linux doesnt have any stable api
hybrid island
Has any hobby OS ever ported actual accel drivers for modern graphics cards?
near tartan
idr if managarm nvo actually has accel working
grave peak
kinda
marble salmon
Managarm does not have accel for NVIDIA yet
hybrid island
Like you could slap a modern radeon card in there and it'd actually get used?
marble salmon
we need to implement fencing for that
marble salmon
afterwards, it should work afaiu
hybrid island
nvidia
I thought there'd be support for AMD before NVIDIA cards because AMD's drivers are open
near tartan
nvidia drivers have sysdeps
grave peak
nvidia drivers are also open
hybrid island
nvidia drivers have sysdeps
You mean you can port it by giving different sysdeps?
near tartan
yes
near tartan
and amd drivers are linux-specific
hybrid island
Ah. I see.
grave peak
its like uacpi but 10 times more complex
near tartan
hybrid island
Damn. I run a modern RADEON card in my desktop.
Not that I'm close to graphics stuff in BadgerOS but...
near tartan
gop
grave peak
i think the situation for radeon is even worse atm
because it doesnt have a portable driver
near tartan
it also doesn't have a gsp
grave peak
on modern nvidia the driver doesnt really do all that much, its just a shim for doing RPC stuff on the card
near tartan
as it should be
hybrid island
Yeah most of the NVIDIA driver stack was actually userspace right?
hybrid island
Only NVIDIA card I have is a 960 lol
hybrid island
I'll wait until I actually get to a point I need accel before I buy shit
near tartan
i do it the other way around
i buy funny hardware then force myself into writing drivers cuz sunken cost fallacy
hybrid island
lolol
grave peak
thats why i got a 5090
hybrid island
I already had RISC-V booting (as the only one at the time) when I bought that HiFive Unmatched
near tartan
thats why i got a 5090 <:trl:829316641191886888>
you do?
grave peak
yea
near tartan
crazy
grave peak
i was just upgrading my pc recently, not really osdev releated tbh lol
near tartan
back to this i guess
i do need to figure this one out though
if i have a ton of built-in drivers, will this not slow down the compilation process a lot?
because afaict every crate is its own TU
@next cairn this is your time to shine
zealous salmon
I just know there's supposed to always be ways to avoid arcs
Whoever told you this is stupid and has no clue about kernel dev
hybrid island
I just know there's supposed to always be ways to avoid arcs
Uhh no. VFS is actually a really good example of you being forced to have something equivalent to an Arc (at least if you want POSIX semantics).
grave peak
Saying you dont need refcounting because tmpfs exists always is fundumentally misunderstanding how anything works tbh
zealous salmon
I'm not trolling but I'm also not 100% serious
Also, if you want to avoid getting banned again, don't double down on shit you're not sure about yourself
halcyon copper
Saying you dont need refcounting because tmpfs exists always is fundumentally mi...
what the fuck
halcyon copper
Also, if you want to avoid getting banned again, don't double down on shit you'r...
near tartan
what the fuck
read above
halcyon copper
read above
but I like my brain 
near tartan
💀 i did too
next cairn
Also, if you want to avoid getting banned again, don't double down on shit you'r...
I really don't see confusion as a banable offense, especially in one of the most confusing topics of programming
Tmpfs was what I thought they were asking about, and me mixing it up doesn't mean "oh my god he's trolling ban him"
good lord
near tartan
i mean i quite clearly said vfs
near tartan
yea vfs is absolutely not the same
grave peak
but what u said is wrong for tmpfs also?
next cairn
okay
next cairn
if i have a ton of built-in drivers, will this not slow down the compilation pro...
shouldn't it only compile what's changed
near tartan
unrelated
it still can't parallelize it
afaict
it can compile multiple crates at once
next cairn
parallelize the compilation?
near tartan
yes
next cairn
it can compile multiple crates at once
it can to a point
cargo uses multiple threads by default
near tartan
yes, but only one crate per cpu
next cairn
yes, but only one crate per cpu
not sure if that's true
just do what I do
make everything its own crate
near tartan
if i have everything in one crate I'm basically limiting myself
next cairn
💀
near tartan
I CANT 
near tartan
yes
next cairn
but even if it's all one thing, it shouldn't be recompiling things that haven't changed
near tartan
never said anything about recompiling
next cairn
well the initial compilation will always be slow idk what else you could do about that
next cairn
near tartan
as most rust issues are
next cairn
sometimes mold helps, but mold isn't os dev friendly at all so
near tartan
mold has issues with ld scripts i think
next cairn
yes that's what I mean
it doesn't support a lot of keywords for them
Well last time I checked, this was on by default for the number of cargo jobs, but you could try setting it yourself and see if it helps
cargo +nightly build -Z threads=8
RUSTFLAGS="-Z threads=8" cargo build --release
"It may be surprising that single-threaded mode is the default. Why parallelize the front-end and then run it in single-threaded mode? The answer is simple: caution. This is a big change! The parallel front-end has a lot of new code. Single-threaded mode exercises most of the new code, but excludes the possibility of threading bugs such as deadlocks that can affect multi-threaded mode. Even in Rust, parallel programs are harder to write correctly than serial programs. For this reason the parallel front-end also won't be shipped in beta or stable releases for some time."
interesting
now I want to try the faster mode myself
it's not like using nightly will be an issue, it's already the only option for os dev 💀
near tartan
lol
next cairn
how much is that
next cairn
I want an EPYC :(
near tartan
ebay
next cairn
I actually want to have a threadripper
near tartan
thery're not really expensive
next cairn
they're cool
next cairn
they continued them
near tartan
and you cant run them in dual cpu mode
near tartan
yeah but if you're compiling llvm for example you want a ton of cores
because c/c++ is highly parallelizable
next cairn
this would be like the one machine I could tolerate gentoo on
near tartan
i'm compiling llvm for my target
tbh i should port rustc too
rn i'm using the debian rust
next cairn
it would be great if I could stop being in pain and work on my os
near tartan
you can also make menix PRs
near tartan
💀
near tartan
what the hell is that
near tartan
you couldn't pay me to work on that
next cairn
I don't
I was working on a decent Thinkpad x1
but I had to sell it
now I'm using some cheaply made but decent spec gaming laptop
near tartan
yeah no it only uses one core
next cairn
where's the repo
near tartan
near tartan
that doesn't sound healthy
next cairn
prob not
halcyon copper
explains a lot tho
near tartan
gib star
next cairn
wtf is the make doing that installs 10k packages
halcyon copper
why is make installing any packages
near tartan
blame for what
halcyon copper
fucking stupid fork from a billion years ago
one of the two xorriso implementations is absolute shit
next cairn
this build system pmo
next cairn
500 line makefile
near tartan
it's not even that big
halcyon copper
or am i mixing up mkisofs and mkisofs
next cairn
no i want the 500 line makefile
halcyon copper
all I know is that libburnia is ass cancer
next cairn
Wtf is make doing on bootstrap
near tartan
i use jinx to build packages
halcyon copper
yeah for jinx that is fair
next cairn
like why is it rebuilding linux-headers
near tartan
rebuilding?
next cairn
i just watched something mentioning linux headers 6.11 fly by
near tartan
yes
near tartan
because you need linux-headers to compile mlibc
and no you can't use /usr/include
it's not the same
near tartan
duh
halcyon copper
better use the damned cores, you paid for them
next cairn
i dont think i could contribute to menix if i wanted to 🥀
near tartan
why
next cairn
every build is gonna take this pos an hour
halcyon copper
PEBKAC
near tartan
well, in your own words, it should be faster after the first compile
near tartan
what
not how it works
you need to explicitly tell it what package to rebuild
like, it can't detect if something changes
next cairn
Atp 100% serious, start distributing this shit 💀
have your server host ready to use ones
jesus
next cairn
use axum
near tartan
just one more build system
next cairn
I've done that but for a linux distro 🥀
near tartan
then do it for jinx
next cairn
just one more build system
yes but then users and contributors will have the binaries
next cairn
no
near tartan
near tartan
lol
next cairn
imma have to ask god himself for a pc just to continue os dev
near tartan
let me guess, no job?
next cairn
anyway while this is building
near tartan
fair enough
next cairn
cargo workspace my beloved
near tartan
did you put the gdt into its own crate?
next cairn
yeah
next cairn
that was supposed to be the goal
"no more os dev boilerplate because 800k crates for the tasks you can't avoid"
near tartan
so you just end up with crateOS
near tartan
my goal is mostly NIH
next cairn
I've already made MakefileOS
near tartan
i'm not writing a kernel because i think it's linux 2
next cairn
the best linux distro
near tartan
i'm writing one because i want to write it once
next cairn
im wanting one because using anyone elses work feels like i did nothing, until the point of needing to write my own os to feel good
💀
Holy shit
I hate python vs code extensions
Why the hell is the python extension slowing down my computer on a rust project
halcyon copper
turn it off?
next cairn
I do
Then the one time I run into a python project, i turn it on and forget
Every other language pack only activates when the language is actually in use, python just does whatever tf it wants
halcyon copper
just stop using python then
near tartan
okay TTY time i guess
next cairn
@near tartan can I get some advice
next cairn
just stop using python then <:meme:575445094589661215>
I never do
it's always someone else's thing
next cairn
<@173337436989030401> can I get some advice
like 10k features in you had to start getting mixed up surely
how do you keep up with what features you're done with and what you want to add
near tartan
todo!() or // TODO
i usually stub out everything and gradually implment things
also there's usually just one thing i'm doing at a time
halcyon copper
also there's a nice TODO Tree extension for vscode that scans your codebase for todo comments
near tartan
also yea you can see the vast amount of todos in the code
it's a lot
i wonder what linux opens for fd 0-2 for init
next cairn
<:meme:575445094589661215>
how do you get that in rust
near tartan
it's just an extension
next cairn
ah
hybrid island
what happens if you use Bash as init?
I dunno. Also don't have an easy way to check unfortunately.
near tartan
same thing
next cairn
`todo!()` or `// TODO`
so, no 800 page notion account
near tartan
todo tree
next cairn
💔
hybrid island
Actually, yes I can check. Lemme make a Limine entry that sets init=/bin/bash and report back what happens.
next cairn
the only thing I like about coda/notion is the ability to check blocking tasks to see what's needed first
hybrid island
@near tartan /dev/console (deleted) is what I get
next cairn
my issue is
hybrid island
With init as bash
next cairn
"I'm gonna make the next linux" level decision
where I compare what I'm doing to something as daily drivable and useful as Linux
then I overwhelm myself
near tartan
feature creep
next cairn
yeah
hybrid island
real
fair lintel
<:meme:575445094589661215>
that shit's broken for me 
mental tinsel
ragebait lore
hybrid island
/proc/1/fd lore
near tartan
okay one issue i have at the moment
because everything is basically demand paged, how am i supposed to satisfy a page fault that happens during a syscall, while the current process is being locked
because if it's locked, i can't access its address space
storm bobcat
i've gotten to userland and filesystems without needing workarounds, so what is ...
Also that's 100% because your kernel doesn't do anything interesting
rust just requires extra thinking and workarounds for basic things and it's annoying
And its memory model can't model everything a kernel may work with
grave peak
Mutex for global variables to be extra safe 🤓
distant cypress
because everything is basically demand paged, how am i supposed to satisfy a pag...
either
- more fine-grained locking, e.g. only take the read lock on the mm struct during page faults.
- move accesses to a process' address space outside such critical sections.
- back off from the critical section, fault-in the page, and then try again.
these are IMO all good options.
near tartan
context is, i have a UserSlice<T> structure, which takes in an address and length. now, to access such a pointer, i pass an address space to it
looks something like this
hm i guess i could map it in as_mut_slice without going through a fault first
distant cypress
ah, so the slice is basically an iterator over userspace addresses
near tartan
i dunno how i should do this
do i write to the address directly, or do i copy a buffer that's allocated in the kernel?
distant cypress
looks something like this
IIUC file.read(slice) happens without the process lock being held.
near tartan
yep
distant cypress
and all faults happen during the file.read, don't they?
distant cypress
Possibly slightly orthogonal to what you're asking, but if you're satisfying a read from the page cache, you can grab and hold a strong reference to a page cache page when copying from it into the userspace slice. Then you do the actual copying without holding any lock, then you decrement the mlock count of the page cache page, and thus there is no problem. (This is all internal to the implementation of file.read.)
near tartan
i'm dumb
read works
openat is causing issues now
because i don't free the lock
hm
what's an ideal way to copy a c string from userspace
vast lotus
make userspace pass the length
near tartan
good point
vast lotus
if you don't want to do that you need a user_strnlen
and you pass either the max you want to copy or top_of_user_memory-ptr for the limit
next cairn
Also that's 100% because your kernel doesn't do anything interesting
nobody was asking you
I'm glad to hear Linux doesn't do anything interesting also, pretty nice
grave peak
Are you saying your toy kernel is at the same level of capabilities as Linux
next cairn
No
Linux has rust code infected into it already
Multiple operating systems thatre well known have rust in them
I'm tired of the rust denial cycle 😔
grave peak
Rust bindings that call into C core is very different from a full rust kernel
next cairn
And its memory model can't model everything a kernel may work with
It just has memory-model=kernel as a joke also
near tartan
that's... not the same "memory model"
next cairn
It can do whatever you want it to now, all the complaints are usually older editions before all the updates
brisk totem
It can do whatever you want it to now, all the complaints are usually older edit...
actually not really
next cairn
there's plenty of examples working fine, hell you're literally in a thread for one
brisk totem
peripherals dont necessarily have coherent caches for example
marble salmon
claiming that Rust can model every possible data structure in safe code is just wrong
brisk totem
and dma can violate &mut invariants unless you are suuuuper careful
brisk totem
claiming that Rust can model every possible data structure in safe code is just ...
its not afaik
next cairn
it's up to you to make it safe
brisk totem
it can model a vm
next cairn
same for C
brisk totem
and thus any ds within it too
marble salmon
no there are data structures that can't be made safe in rust
next cairn
That's not what the safety is supposed to mean
brisk totem
no there are data structures that can't be made safe in rust
afaik thats not true
next cairn
you make it safe
marble salmon
btw @next cairn you seem to have the impression that people hate or dislike rust here
brisk totem
they cant be made without crazy perf overhead
next cairn
if whatever defaults aren't safe and it requires unsafe code
marble salmon
which is not true
next cairn
you make it safe
marble salmon
I do like rust and i also do rust coding as part of my job
next cairn
btw <@393220516502306837> you seem to have the impression that people hate or di...
you should see reactions in #lounge-0
brisk totem
*you make it safe*
for some things, you cannot do so
marble salmon
but it does have limitations
next cairn
for some things, **you cannot do so**
Like what?
near tartan
mmio?
next cairn
it's no different than making it safe in C, you have to do it correctly 😭
brisk totem
Like what?
intrusive data structures?
marble salmon
like a struct Foo that is alive as long as an AtomicU32 in it is nonzero
this is a perfectly safe concept
but it's not expressible in safe rust
near tartan
this is what i meant originally with inner structs
next cairn
we're at the point of being able to tell borrow checking to fuck off entirely just to create things
near tartan
like having Process and InnerProcess
brisk totem
we're at the point of being able to tell borrow checking to fuck off entirely ju...
huh
next cairn
💀
grave peak
marble salmon
having limitations is also kinda the point of Rust: they ensure that you can't violate Rust's invariants
brisk totem
wat
next cairn
having limitations is also kinda the point of Rust: they ensure that you can't v...
you can definitely violate them
marble salmon
only in unsafe code
near tartan
it's just
struct Process {
inner: Mutex<InnerProcess>,
}
struct InnerProcess {...
this just reminded me of the issue where two structs reference each other and are never dropped
marble salmon
(except for unsoundness bugs ofc)
brisk totem
and its very easy to write incorrect unsafe code
next cairn
and its very easy to write incorrect unsafe code
yes
marble salmon
writing unsafe rust is way harder than writing C
next cairn
that's the point
marble salmon
because there are a lot more invariants that you need to care about
like, making a shared memory region is already quite a challenge
because you can at no point in time keep a ref to it
grave peak
it's no different than making it safe in C, you have to do it correctly 😭
You keep saying this, but what do u mean by safe C exactly?
next cairn
the same safety rusts unsafe exists for
you still need to ensure thread and memory safety in C
Just because it doesn't force you to write explicitly unsafe code doesn't make it inherently safe
marble salmon
Rust is only worth it if you can contain the unsafety at the module level though
next cairn
Rust is only worth it if you can contain the `unsafe`ty at the module level thou...
a lot of the time safe wrappers exists
grave peak
But you can segfault safe rust also
next cairn
but still a lot of the time, they can't exist
next cairn
But you can segfault safe rust also
huh
marble salmon
But you can segfault safe rust also
no, you can't
grave peak
Well I've seen tons of snippets that do
near tartan
those are compiler bugs
next cairn
Well I've seen tons of snippets that do
those are bugs
every language has them at some point
marble salmon
yeah they are compiler bugs, no different from llvm miscompiling C code
distant cypress
this just reminded me of the issue where two structs reference each other and ar...
yeah that's like a shared_ptr cycle in C++ (where you have object A and object B pointing to eachother with shared_ptr<MyClass>s)
next cairn
compiler bugs 💔
distant cypress
but that's like an entirely different thing
grave peak
Oh ok
next cairn
There was even one compiler bug where you could use lifetimes to leak your entire program
🔥
distant cypress
you can leak memory in safe Rust under a good compiler
distant cypress
you're not supposed to be able to
really?
distant cypress
memory leaks != memory safety
next cairn
it's supposed to be guranteeing you that it won't leak
well you can also leak on purpose
next cairn
memory leaks != memory safety
I guess?
that's usually what they're talking about though
UB and memory leaks
distant cypress
yeah ofcourse you don't want memory leaks in your programs...
next cairn
there's some shit called BoxLeak iirc
you can leak on purpose in the rare case you need it
distant cypress
is a Box<T> Rust's equivalent to shared_ptr<T>?
next cairn
memory leaks aren't unsafe
if there is a memory leak it shouldn't be an accident tho
you're supposed to know it exists
next cairn
is a Box<T> Rust's equivalent to shared_ptr<T>?
im not sure
distant cypress
memory leak 'safety' is explicitly not a thing that Rust enforces
near tartan
Box is just a heap pointer
distant cypress
that's Arc
ah, ok.
vast lotus
is a Box<T> Rust's equivalent to shared_ptr<T>?
unique_ptr iirc
marble salmon
it's supposed to be guranteeing you that it won't leak
no
you can std::mem::forget a box
or an Arc or Rc
marble salmon
next cairn
intrusive data structures?
it's not the funnest or easiest topic of rust but people have done it a lot
https://github.com/Amanieu/intrusive-rs
marble salmon
forget is not marked as unsafe, because Rust’s safety guarantees do not include a guarantee that destructors will always run. For example, a program can create a reference cycle using Rc, or call process::exit to exit without running destructors. Thus, allowing mem::forget from safe code does not fundamentally change Rust’s safety guarantees.
That said, leaking resources such as memory or I/O objects is usually undesirable. The need comes up in some specialized use cases for FFI or unsafe code, but even then, ManuallyDrop is typically preferred.
Because forgetting a value is allowed, any unsafe code you write must allow for this possibility. You cannot return a value and expect that the caller will necessarily run the value’s destructor.
distant cypress
... so if I have something like:
struct Foo {
Arc<Foo> ptr;
};
and I create some Foos pointing to each other, that's the very same thing as a C++ shared_ptr cycle.
near tartan
yes
distant cypress
and that does leak memory
near tartan
kinda
distant cypress
and you're not explicitly writing forget or leak
near tartan
it even leaks memory if you have only weak refs to it
marble salmon
yeah, weak refs keep the allocation alive
next cairn
... so if I have something like:
```rust
struct Foo {
Arc<Foo> ptr;
};
`...
so there's weak reference wrappers for that
marble salmon
they just don't prevent drop from running
distant cypress
and you're not explicitly writing `forget` or `leak`
yes there are weak reference types, but my point is this.
marble salmon
Weak<> keeps the memory allocation alive
e.g., if you store a Weak in something 'static, that keeps the allocation alive
both Rc and Weak point to RcInner which is the acutal allocation
storm bobcat
I'm glad to hear Linux doesn't do anything interesting also, pretty nice
Linux only uses rust for some drivers
Also didn't they remove rust or something?
near tartan
marcan removed themselves
distant cypress
still there in 6.16
near tartan
big drama because linux maintainers are children
storm bobcat
Yea I remember there was drama recently but idk how that ended
near tartan
basically, marcan left kernel development altogether
so no more upstream work
because they wouldn't merge some changes and acted like kids
mental tinsel
static mut files is silly 🤪
next cairn
RUSTFLAGS="-Z threads=$(nproc) -C relocation-model=static" cargo build 12.75s user 2.14s system 494% cpu 3.012 total
RUSTFLAGS="-C relocation-model=static" cargo build --target 10.83s user 1.39s system 415% cpu 2.938 total
bruh
multithreaded used more cpu and was slower?..
hoary cave
wow no way, if you try to parallelize small tasks it gets slower?
near tartan
🤯
next cairn
that's not how it works
hoary cave
that's what you'd like to think