xenos1984 has quit [Read error: Connection reset by peer]
MiningMarsh has joined #osdev
srjek has quit [Ping timeout: 256 seconds]
xenos1984 has joined #osdev
Arthuria has joined #osdev
edr has quit [Quit: Leaving]
heat has quit [Quit: Client closed]
JerryXiao has quit [Ping timeout: 245 seconds]
JerryXiao has joined #osdev
rorx has quit [Ping timeout: 268 seconds]
rorx has joined #osdev
Matt|home has joined #osdev
smeso has quit [Quit: smeso]
gog has quit [Ping timeout: 272 seconds]
smeso has joined #osdev
Arthuria has quit [Ping timeout: 245 seconds]
rorx has quit [Ping timeout: 240 seconds]
rorx has joined #osdev
rorx has quit [Ping timeout: 255 seconds]
goliath has joined #osdev
rorx has joined #osdev
pebble has joined #osdev
gbowne1 has quit [Remote host closed the connection]
rorx has quit [Ping timeout: 260 seconds]
bauen1 has quit [Ping timeout: 260 seconds]
voidah has quit [Ping timeout: 252 seconds]
npc has joined #osdev
Bitweasil has quit [Quit: ZNC 1.8.2+deb2build5 - https://znc.in]
Bitweasil has joined #osdev
voidah has joined #osdev
rorx has joined #osdev
netbsduser` has joined #osdev
<azonenberg>
Do GNU linker scripts support preprocessor directives?
<azonenberg>
or in general is there any good way to create/maintain a set of linker scripts that have a lot of common components but a few bits different?
<clever>
azonenberg: LK has been using sed i believe
<goliath>
can't you just run the linker script through the preprocessor first in your build script?
<zid`>
GeDaMo: tally() operator should return a const char * that contains "1111" if the array has 4 elements
<nikolapdp>
genius
<nikolapdp>
add it to your langauge
<zid`>
and " 1111 1111" for 9 ofc
<zid`>
ack
<zid`>
made a mess of my control chars
<nikolapdp>
you sure did, but the pdp doesn't care
<zid`>
"1111 1111" ?
<zid`>
There we go
<zid`>
just to stop you using strlen() on it mainly
<nikolapdp>
oh the escape sequences are a part of the string
<nikolapdp>
neato
<zid`>
You could probably still do it with strlen(s)/6 + strlen(s)%5 though
Arthuria has quit [Ping timeout: 268 seconds]
<GeDaMo>
𝍸𝍬
<zid`>
nice boxes
<zid`>
even my browser doesn't have those
<zid`>
ah tally unicode, neat
<GeDaMo>
Neither does mine but my IRC client has, for some reason :P
<zid`>
my irc font is a pixel font, windows will sub in from a different font for things it doesn't have, but I don't know what that font actually is though
<bslsk05>
www.theregister.com: Font security 'still a Helvetica of a problem' says Canva • The Register
<zid`>
>written in Python
<zid`>
so not a serious tool then at least
<zid`>
lol they just put "/etc/passwd" in the xml configs it used
<zid`>
can't really blame bytecode fonts for that
<gog>
we need to stop writing code
<zid`>
we need to stop running things other people wrote in python
<zid`>
python is a prototyping language
<zid`>
it should be illegal to transfer python code over a network
<gog>
i can't even read python anymore
<nikolapdp>
lol
xFCFFDFFFFEFFFAF has quit [Read error: Connection reset by peer]
xFCFFDFFFFEFFFAF has joined #osdev
SophiaNya has quit [Remote host closed the connection]
ptrc has quit [Remote host closed the connection]
Burgundy has left #osdev [#osdev]
SophiaNya has joined #osdev
ptrc has joined #osdev
* Ermine
moves from python to go
<kof673>
apparently there is unicode stuff, not sure if for that: > The Mayan numeral system was the system [...] a vigesimal (base-20) positional numeral system. [...] three symbols: zero (a shell),^[citation needed] one (a dot) and five (a bar).
<kof673>
> for example, thirteen is written as three dots in a horizontal row above two horizontal bars; sometimes it is also written as three vertical dots to the left of two vertical bars.
heat has joined #osdev
<heat>
mjg, smp_mb
<mjg>
lock twitteradd
<heat>
twitterchg
<heat>
implicit lock'd
<mjg>
i with there was a rust write up for 1. c programmers 2. doing systems stuff
m257 has quit [Quit: Client closed]
<mjg>
even stuff which claims to be for c programmers is not
<bslsk05>
users.rust-lang.org: How to add an object to a hash map - help - The Rust Programming Language Forum
m257 has joined #osdev
<heat>
isn't the answer Box<> like someone here told you before
<mjg>
nope
<zid`>
grep "unsafe" pl011.rs
<mjg>
it just shifts the fundamental issue
<zid`>
3
<zid`>
not bad for 15 lines of code
<heat>
mjg, why?
<mjg>
real implementation of boxing stuff up still creates a stack-based instance first
<mjg>
which is then copied
<heat>
thats weird
<mjg>
rust
<heat>
does it create something on the stack and then move it to the heap?
<mjg>
anyhow it may be this is in fact not a problme, but i don't see it justtified anywhere
<mjg>
and things like this are a big part of what i would consider to be material for c programmers
<mjg>
someone only using higher level langs does not even need to consider this aspect
<mjg>
and i see why regular docs would not bother talking about it
<mjg>
sincce they are aiming at people from other stuff
<heat>
there's a very select group of people that care if you do an extra copy or not
<mjg>
if you are pretending to be a "c replacement"....
<heat>
and it is you and a few other people in the LKML
<mjg>
and talk shit about perf
<mjg>
anyhow, from conceptual standpoint, there is a massive mismatch between what one would consider a pointer
<mjg>
and what rust operates on
<mjg>
but i don't have a full grasp on it
<heat>
yes, because pointers are unsafe
<mjg>
materials straighetning it out would be nice
<heat>
we figured that out 30 years ago
<nikolapdp>
FEARLESS
<mjg>
aaand are fucking scarce
<zid`>
DOING WORK IS UNSAFE --Rust, 2024
<Ermine>
heat: I don't get the big picture of how block devices work. Is their interface a subclass of io_queue?
<heat>
Ermine, block devices aren't necessarily related to io_queue
skydhash has joined #osdev
<zid`>
nikolapdp: need something to do for 6 days 6 hours 35 mins
<nikolapdp>
LEARN RUST
<nikolapdp>
RUST RUST
<gog>
I'M RUSTING
<nikolapdp>
RUUUUUUUST
<heat>
Ermine, basically blockdev provides an opaque submit_request (with some incestuous blk_mq_ops there)
<zid`>
I can't learn rust in 6 days, I gave up after 1 hour last time
<mjg>
do learn rust
<mjg>
but don't lie about it
<mjg>
8)
<heat>
Ermine, if you use blk mq paths, blk_mq_submit_request will then pick an io_queue (using blk_mq_ops::pick_queue) and submit the request *there*
<mjg>
do you submit requests using mpsc queues from rust
<heat>
no, i have a single linked list with a spinlock on it
<heat>
the classic pessimal
<mjg>
may i interest you in ideas from distributed systems
<heat>
no!
<heat>
i did ponder making this scale but it made no sense
<heat>
because io_queues are generally per-cpu anyway
<heat>
and if they're not, submission is going to need a lock anyway
<mjg>
's was a meme
<heat>
i know
<mjg>
academia twats who never did real multicore in their life refer to stock-standard trickery as "from distributed systems"
<heat>
Ermine, anyway then io_queue::device_io_submit can take the struct request (with its associated data, i.e the blockdev struct itself) and do the thing
<heat>
do note that device_io_submit runs in atomic contexts and as such all allocations (if any) need to be GFP_ATOMIC, all locks need to be irqsafe, and ideally all memory should be preallocated alongside the struct request
<heat>
nvme is a good example
<mjg>
[']
<mjg>
(i'm fucking off now)
<nikolapdp>
drop(mjg)
<mjg>
note this identified going out of scope does not affect the real me
<mjg>
did you know letting std::process::Command objs going out of scope does not affect the child
<mjg>
meaning you don't have a legitimate way to reap it after
<nikolapdp>
wtf
<mjg>
a language for soyboys would do something about accidents like that, but rust creators thought "well there is no leak *within* the program so who gives a shit"
<heat>
hey that sounds like std::thread vs std::jthread
<gog>
pee threads
<gog>
leaking everywhere
<Ermine>
so, fsen call blockdev.submit_request when they want to do IO ?
<mjg>
std? you mean standard transmitted disease?
<heat>
Ermine, yesen at some point
<Mutabah>
mjg, gog - mind toning down (or up?) the language a bit? Put some thought into your insults at least
<gog>
ok
<gog>
i should really be webdeving anyway
<nikolapdp>
hey gog, good news, i've got a language for you
<mjg>
Mutabah: do you know a good resource for c programmers trying to learn rust
<mjg>
i can try to come up with an elaborate insult as gratitude if required
<Mutabah>
maybe "Rust by example"?
<mjg>
i found that stuff to be of weirdly bad quality
<Mutabah>
The challenge I have is that I learnt before 1.0, and learnt by just taking an existing project of mine and hackily converting it to rust
<mjg>
liek anything you read there is super simplified, which would be fine if they just wanted to illustrate something at first
<mjg>
and if they later followed by something which very much is common and is not obvious whatsoever how to do it, but they don't
<mjg>
case in point, see process creation i linked above
<mjg>
literally the only examples are creating a lolproc and immediately waiting for it, maybe grabbing some of its output
<mjg>
this is useful and all, but far from the only case for creating a process, innit
<heat>
have you conisdered just calling waitpid?
<mjg>
mofo, the recommended crate creates an object tied to the process
<mjg>
if i just waitpid i reap the child from under the object
<heat>
and?
<mjg>
kind of a layering violation would not you think?
m257 has quit [Ping timeout: 250 seconds]
<heat>
ZFS!
<mjg>
aight want something funny?
<heat>
you can probably still use signal handlers as much as you can probably also use waitpid
<mjg>
i found a dude who tried to use the famed fearlezz concurrency
<mjg>
and found perf is terrible
<mjg>
their locks immediately go to sleep when contended, so...
<heat>
yes, what now
<mjg>
the solution is to not use locking but message passing
<heat>
all locks immediately go to sleep when contended
<heat>
in userspace
<mjg>
message passing is implemented with hand-rolled spinlocks which never go to sleep
<heat>
FAST
<mjg>
and suddenly perf is acceptable
<mjg>
so much for fearless concurrency
<heat>
what
<mjg>
what what
<heat>
i'm not sure how your conclusion here can be
<heat>
"how about that fearless concurrency eh?"
m257 has joined #osdev
<mjg>
rust docs claim it's all dandy, just use locks
<nikolapdp>
RFEARLESS CONCURRENCY
<heat>
it's still fearless concurrency but with a spinlock
<mjg>
people who try to do it find thigns don't work
<mjg>
you have to use a not recommended method to dodge the problem
leg7 has quit [Ping timeout: 268 seconds]
<heat>
brother in christ try glibc
<mjg>
and the method is implemented in a shite manner which futexes were created to solve
<heat>
the scenes when you find out pthread_mutex_lock also blocks
<mjg>
i know
<mjg>
you must have missed the part where locking does not scale for the most part and quadruple so if you go to sleep
<heat>
correct
<mjg>
but if that's true even by rust standards, they should not be recommending it
<mjg>
yet they do
<mjg>
marketing literally states you can just slap mutexen all over and it's gonna be great
<mjg>
speed ups, safely
<heat>
rcu is very hard to model correctly
<nikolapdp>
that's what FEARLESS CONCURRENCY is supposed to mean after all
<heat>
and used by a teeny tiny % of people
<mjg>
of course, real world multicore performance requires expertise
<mjg>
so for starters they could concede that
<mjg>
instead of lying
<Ermine>
I've got a feeling this rust discussion lasts for days
<heat>
i've seen a web server use mutexes and relatively big locks and run with hundreds or thousands of threads
<Mutabah>
throw rayon at it?
<mjg>
a well meaning beginner can easily buy into this and write themselvs into shit
<heat>
anyone can write themselves into shit
<heat>
for any language
<mjg>
the lang does not have to encourage it
<mjg>
which rust does
<Mutabah>
"fearless concurrency" doesn't mean that your code will be super-duper fast with no effort
<heat>
do you want the language to encourage RCU?????
<Mutabah>
but it _does_ mean that you won't accidentally expose data you didn't intend to due to a race
<mjg>
Mutabah: that's not what rust advocates claim
<mjg>
heat: no, i want the language to stop bullshitting about multicore
<Mutabah>
and it will be faster than other safe languages (e.g. blows python out of the water)
<mjg>
Mutabah: so i got that example guy (no link handy though, sorry) who had a project in go
<mjg>
Mutabah: rewrote that in rust and got the perf drop due to mutexes sleeping
<mjg>
recovered after converting to message passing
<heat>
mjg, not sure what they can do. remove mutexes from the standard library?
<nikolapdp>
Mutabah, for a so called systems language, python is a werid comparison
<heat>
"rust mutexen are pessimal so just use unsafe and roll your own solution"
<mjg>
no, they should stop encouraing multicore
<mjg>
which often times is not warranted
<nikolapdp>
not wrong
<mjg>
for example nginx or apache (in pre-fork mpm) are single-threaded, yet utilize multiple cpus just fine
<mjg>
without multicore fuckery
<heat>
you're bringing world class web servers into the picture while talking about some shitty tutorials
<Ermine>
s/multicore/multithread
<mjg>
no, even numerous examples with tokio where people claim they use shit in production explicitly show 0 use for multicore handling in their code
<mjg>
ultimately people mostly have something which grabs a request and produces some shite output
<mjg>
whateer synchronisation which was needed was already done by code below
<mjg>
for example in the database
<mjg>
i/o multiplexing done by whatever magic framework (tokio in case of rust)
<Mutabah>
nikolapdp: Ok, how about "same performance as C++, but without the uncontrolled memory safety holes"
<mjg>
somehow outside of rust majority of code gets away with very simple code oblivious to multicore aspects
<mjg>
s/of code/projects/
<mjg>
but in rust you better add some locks
<Mutabah>
mjg: At the lowest level of anything - there's ether locks or atomics - otherwise you have race conditions
skydhash has quit [Quit: My MacBook Air has gone to sleep. ZZZzzz…]
<mjg>
i commented on this above
<Mutabah>
Sorry, I probably missed that then - been flicking back and forth
<mjg>
well it's not a /serious/ discussion, so... :)
<mjg>
i just remembered a great example.
<mjg>
there is a new-ish grep rewrite with some magic algos which make it way faster than gnu grep
<mjg>
all in c afair
<mjg>
and single-threaded
<mjg>
meanwhile should you check for a grep in rust you are going to immediately find threading
<mjg>
and it still loses(!)
<mjg>
the baseline program is not as fast and threading itself comes with overhead
<mjg>
arguably for a big enough file tree it is going to start winning
xenos1984 has quit [Read error: Connection reset by peer]
<Ermine>
Ah, so block device can plug blk_mq_submit request and be multiqueued, but it can roll its own submit_request if it wants to?
<Mutabah>
mjg: I think that's the idea of ripgrep - be able to do recursive searches fast
<heat>
Ermine, yep
<Mutabah>
Counter point to the upside of rust's threading and infrastructure - I made a 3D raytracer/renderer, and enabling threading was some simple changes to switch to using rayon
<Mutabah>
and voila, 16 threads crunching the geometry calculations.
<mjg>
you mean you had embarassingly parallel problem to deal with or something else of that caliber
<mjg>
that does happen and even c(!) has lib to handle this (see openmp)
<heat>
Ermine, all in all i don't recommend it, blk_mq_submit_request implements trickier stuff like block plugging and the sort
<mjg>
you may also notice you could get all these benefits without the misleaing marketing about locks
<heat>
it should be the Canonical(r) entry point into most IO stacks
<heat>
personally i think arguing about rust multithreading capabilities ad infinitum is a great use of everyone's time
<zid`>
kibitzing
<heat>
this is a distinctly good discussion because no one is listening to the other participants
<mjg>
Mutabah: wtf, someone added threading to ugrep....
<zid`>
gongoozling is the best sport ngl
<heat>
gongoozling sounds like a new step in ZFS before your data goes to the disk
<Ermine>
Ok, so for virtio I basically need to implement io_queue which somehow translates to virtqueues, and corresponding mq_ops ?
<mjg>
Mutabah: i'm buggering off the subject 8)
xFCFFDFFFFEFFFAF has quit [Read error: Connection reset by peer]
bauen1 has quit [Ping timeout: 260 seconds]
<heat>
Ermine, correct
<Ermine>
Gotcha
xenos1984 has joined #osdev
xFCFFDFFFFEFFFAF has joined #osdev
melonai has quit [Quit: Ping timeout (120 seconds)]
melonai has joined #osdev
spareproject has joined #osdev
xFCFFDFFFFEFFFAF has quit [Remote host closed the connection]
m257 has quit [Quit: Client closed]
m257 has joined #osdev
m257 has quit [Ping timeout: 250 seconds]
Left_Turn has joined #osdev
thaumavorio has quit [Ping timeout: 256 seconds]
thaumavorio has joined #osdev
xal has quit [Quit: No Ping reply in 180 seconds.]
xal has joined #osdev
goliath has quit [Quit: SIGSEGV]
bauen1 has joined #osdev
spareproject has quit [Remote host closed the connection]
<ddevault>
that was significantly more work than I anticipated
<mjg>
:)
<mjg>
congrats
<nikolar>
Very nice ddevault
<mjg>
are you C-ing or rusting it
<ddevault>
hare
<mjg>
oh right
<heat>
nice!
<nikolar>
very nice indeed
m257 has joined #osdev
navi has joined #osdev
skydhash has joined #osdev
navi has quit [Ping timeout: 256 seconds]
<heat>
linux has a locked named blocked_lock_lock
<heat>
lock
<Ermine>
gj ddevault !
<ddevault>
ty!
<kof673>
to clarify your position mjg (this is not a criticism) is there any language/etc. that does really offer fearless concurrency, or is it all a mixture of hype/fluff/etc. ?
<kof673>
"offer" as in a default path/idiom/methodology, not something that needs lots of work (again, not a criticism: maybe it always needs careful planning)
<GeDaMo>
Erlang?
<GeDaMo>
Occam?
<Ermine>
Occam's razor?
<mjg>
kof673: there is tech out there which largely hides anything multicore you for simple things
<mjg>
however, for real problems where real expertise is required so far nobody came up with a magic pill
<mjg>
> A wise man once told me we as managers or leaders we are managing people hence understanding the underlying reasons for conflicts can be crucial for managing them effectively. having open conversations with team members to identify any sources of pressure, personal issues, or misunderstandings that contribute to the conflicts. Additionally, creating a supportive and collaborative team environment can help
<mjg>
reduce the likelihood of conflicts arising in the first place.
<mjg>
sounds like an intern but the photo suggests dude is at least 50
leg7 has quit [Remote host closed the connection]
xFCFFDFFFFEFFFAF has quit [Read error: Connection reset by peer]
xFCFFDFFFFEFFFAF has joined #osdev
<kof673>
wise was double, illiteracy is eternal :D
<kof673>
or, not all conflict is magically bad
<kof673>
nor needs "managed"
navi has joined #osdev
chiselfuse has quit [Remote host closed the connection]
chiselfuse has joined #osdev
<kof673>
> Se-Osiris, Ancient Egyptian Wizard that was the "wise man" lol
goliath has joined #osdev
<Ermine>
if a conflict affects the project, it should be managed i guess
chiselfuse has quit [Remote host closed the connection]
chiselfuse has joined #osdev
xal has quit []
xal has joined #osdev
gbowne1 has joined #osdev
<kof673>
i'm not arguing that, just nitpicking "wise" used to be "wizard" lol
<kof673>
so that is the "wizard' definition lol
skydhash has quit [Quit: My MacBook Air has gone to sleep. ZZZzzz…]
<heat>
lord oh lord why does my systemd have gnutls AND openssl linked in
<nikolapdp>
lel
<nikolapdp>
you know whose init doesn't have two full blown ssl implentations in it
<heat>
2.11BSD
<nikolapdp>
indeed
<mjg>
:(
<mjg>
i'm gonna add openssl to it just to invalidate your statement
<nikolar>
I double dare you
<nikolar>
Do it
<mjg>
waiting for my vax delivery
<heat>
this is insane
<nikolar>
(btw you'd need to SSL implementations to invalidate my statement but I'll accept just one)
<GeDaMo>
Vacuum cleaner? :P
<heat>
apparently if i link my GPL'd code against OpenSSL I'm infringing on the GPL??
<mjg>
?
<mjg>
i''m pretty sure tons of gpl uses openssl
<nikolar>
Wat
<mjg>
so something is funky
<heat>
it appears to have been the entire legal argument for gnutls
theyneversleep has joined #osdev
<heat>
that if not for gnutls, every copyright holder in a gpl project needs to grant an exception for openssl
<zid`>
That's what you told me you'd be watching in your free time
<heat>
ohhhhh the OG openssl license had weird advertisement clauses
<heat>
that's why they weren't GPL compatible
<nikolar>
Oh makes sense
<zid`>
Guys, can you believe
<zid`>
People born in 24 are 2000 now
<nikolar>
I'm pretty sure you're fine heat
<nikolar>
Yes zid, I can believe that
<heat>
ine from what?
<nikolar>
Though I'm not 24
foudfou_ has quit [Remote host closed the connection]
<nikolar>
Licensing-wise
<heat>
yeah
foudfou has joined #osdev
<heat>
i'm not facing this problem though
gog has joined #osdev
<heat>
was just curious as to why gnutls existed at all
<heat>
or why anyone would ever use such a horrible horrible thing
<nikolar>
Lol why is it so horrible
<heat>
i would be very surprised if it isn't openssl but worst and commie'd
<heat>
worse*
<zid`>
openssl but *worse*? how?
<heat>
that's very trivial
<heat>
see: libressl
<zid`>
openssl compiles -fno-strict-aliasing because *they have too much UB and refuse to fix it* :D
<heat>
so does linox
<heat>
does that mean freebsd > linox?
<zid`>
The linux case is weird, linux does very specific UB on purpose because it's "Things that they think gcc should make IDB, for all I"
<nikolar>
Lol and do they do exactly
<zid`>
wat
<zid`>
heat, balkans to english pls
<netbsduser`>
the no strict alising goes without saying
<netbsduser`>
there isn't a kernel in the world that doesn't employ that flag (except for the ones not built with radical compilers)
<heat>
zid`, the FOSS world is full of people saying stuff should not be UB, or that UB is fine
<heat>
linux gets a pass because it's linux and everyone loves it
<zid`>
sadly
<zid`>
Linux gets a *partial* pass from me
<heat>
hell, linux made its own memory model
<heat>
which, fair enough, they kinda had to
<zid`>
They have a lot of contributors and aliasing bugs are hard to chase, I'd consider it a hardening option, for them
<zid`>
just claim linux enables it by default to make the code MORE ROBUST and then whatever I guess, rather than a quality control issue
<mjg>
frogbsd vs linax
<childlikempress>
linux memory model uses data dependencies which aren't really in c++11
<heat>
yes they are
<heat>
consume!!
<childlikempress>
hence 'aren't _really_' :p
<heat>
it's not the spec's fault if the compiler never bothered to implement it
<childlikempress>
oh don't they have control deps too
<childlikempress>
that at least isn't in c++11
<heat>
but it just so happens that data dependencies are kinda automatic if you're not alpha
<heat>
a relaxed load Just Works usually
<heat>
except if you're alpha, in which case you cry
<mjg>
good thing you are a beta
* mjg
<-- sigma
<heat>
mjg what's the openbsd memory model
<heat>
is it "giant lock and pray"
<childlikempress>
oh same as python!
<mjg>
interestingly that's somewhat true
<childlikempress>
match made in heaven
<heat>
x86 should have an interpreter lock
<childlikempress>
it does!
<childlikempress>
look up split locks
<mjg>
they have numerous races which they hope wont happen
<childlikempress>
mjg: wait what?
<mjg>
note giant is autodropped when you are going off cpu
<mjg>
childlikempress: for example they had some code for process export (for ps) which failed to ref squat
<mjg>
so they would deref some pointers while protected by giant, copyout, possibly dropping giant, then continue using them
<mjg>
but by that time they very well may not be what they seem, just like owls in twin peaks
<childlikempress>
that ... seems ... exploitable?
<mjg>
plausibly
<heat>
WHAT
<mjg>
chances are decent their races are "safe" n that they never free that memory
<heat>
noway bro
<mjg>
aka "type stable"
<childlikempress>
oh
<childlikempress>
sad
<heat>
did you know openbsd eliminated all rop gadgets
<heat>
and pads .text with int3
<mjg>
ye i expect for the most part you are getting botched export
<mjg>
missing processes 'n shit
<childlikempress>
wait but then does that mean if you just create a bunch of proceses and then destroy them all, you'll leak some memory used for process descriptors?
<childlikempress>
because it can't be reused for anything else?
<mjg>
they can be reused for other processes
<childlikempress>
but nothing else?
<heat>
its extra secure
<mjg>
it's an age old tradition to have core kernel structures
<mjg>
yes
<mjg>
... handled like this
<mjg>
literally same deal with vnodes
<childlikempress>
o.o
<mjg>
literally can't be freed
<mjg>
age old tradition in the bsd land i mean
<heat>
in unix
<heat>
struct buf bufs[NBUFS];
<nikolapdp>
#defineNPROC (10 + 7 * MAXUSERS)
<nikolapdp>
struct proc PROC[NPROC];
<nikolapdp>
straight out of 2.11
<mjg>
astrological tunning
<kof673>
^ > this does sound legally bogus /me points at double lions outside ocurthouse
<kof673>
*courthouse. that is kind of what "legal" means, "bogus"
<heat>
nikolapdp, it's a classic practice
<heat>
the BSD people are only sad they had to stop doing it
<heat>
but still limit vnodes and shit
<mjg>
why are you dunking so much on bsd
<mjg>
where is someone to call you out
<nikolapdp>
PDP11 RULEZ
<nikolapdp>
BSD2.11 FOR LYFE
<kof673>
"law" did the "Spirit" thing formerly, "legal" is appearances/formalized...may or may not be actual. 3 frogs in a suit
<kof673>
that was not a misuse by you nor the link, just.....illiteracy is eternal :D
<heat>
mjg, it's about time you dunk on my scheduler code again
<mjg>
i'm busy dunking on something else atm
xFCFFDFFFFEFFFAF has quit [Ping timeout: 272 seconds]
<heat>
oh they're rewriting tor in rust
<kof673>
or, "legal" is only 1/2 of the double lion lol
<zid`>
that makes sense
<mjg>
you know what would be funny
<mjg>
if it turned out that rust has a backdoor a'la xz
valshaped7424880 has quit [Read error: Connection reset by peer]
<nikolapdp>
kek
<mjg>
liek think about it
<mjg>
there is a push to get this lang everywhere
<heat>
has jia committed to rust
<heat>
quick someone check
<mjg>
not that i know of, but maybe his brother in law?
<nikolapdp>
no
<nikolapdp>
you
<mjg>
i committed to rust
<mjg>
true story
<Ermine>
You can make this backdoor in literally any language
<nikolapdp>
what magnificent contribution did you make mjg
<mjg>
PERFORMANCE... kind of
<nikolapdp>
Ermine not every language is being pushed everywhere as hard as rust
<mjg>
mostly being annoyed at strace output
<Ermine>
and?
<nikolapdp>
lol fair
<nikolapdp>
just saying
<Ermine>
C is not pushed, yet the backdoor was in C
<bslsk05>
github.com: Stop probing for statx unless necessary by mjguzik · Pull Request #106661 · rust-lang/rust · GitHub
<Ermine>
And autotools are not pushed
<mjg>
fucken' gg
valshaped7424880 has joined #osdev
<nikolapdp>
oh i think you misunderstood mjg
<kof673>
i read that as jira
<nikolapdp>
what if the backdoor was inside of the language itself
<heat>
it'd still be safer than C
<nikolapdp>
sure heat
<nikolapdp>
you'd know, you write in c after all
<heat>
mjg, you know what the musl guy told me when i said you could cache syscall results?
<heat>
nikolapdp, i do
<nikolapdp>
yeah we've seen all of your lambdas in c
<heat>
he told me "what if they migrate the process to a newer kernel and now the syscall caching doesn't reflect the thing :("
<heat>
i feel like you sniff glue
<heat>
do you?
<mjg>
what syscall results are you down to cache heat
<mjg>
are you the the kind of ricer to cache getpid?
<heat>
not that kind
<mjg>
i'm watching you and i don't like what i see
<heat>
caching if syscalls exist or if flags are implemented
<mjg>
then i don't get hiso bjection
<mjg>
my solution: stick to kernel 2.2
<heat>
lets say you're running on 6.0, SYS_ligma doesn't exist, you cahce that. now you migrate to 6.1, suddenly SYS_ligma exists, but your cache is wrong
<mjg>
where tf did you cache
<heat>
memory?
<mjg>
right, so how is this a problem
<Ermine>
how tf do you migrate the process
<mjg>
you hotpatched from 6.0 to 6.1?
<heat>
you can freeze processes
<heat>
it is technically a thing you can do
<heat>
in practice it's a super tiny edgecase
<nikolapdp>
how common is hot patching anyway
<mjg>
does thatcode even work though
<mjg>
a genuine question
<mjg>
it was beyond dodgy
<heat>
what code?
<mjg>
prctl feezer
<mjg>
and more accurately, the restore part
<heat>
idk
<heat>
but criu apparently supports live migration
<mjg>
and openbsd supports 256 cpus
<nikolapdp>
is that defined by NCPU
<mjg>
MAXCPU
<nikolapdp>
heh neat
<nikolapdp>
keeping the tradition going
<mjg>
well you do need a limit to size shit
<mjg>
some of it anyway
<mjg>
even linux has one
<heat>
LINUX WOULD NEVER
* geist
slaps linux with a wet trout
<heat>
is zircon still limited to 32 cpus?
<vin>
what do you mean by migrate a process to a new kernel heat? Won't we have to always restart when the kernel is updated? I have not heard of live migration, sounds pretty cool
<bslsk05>
github.com: musl/src/fcntl/fcntl.c at master · heatd/musl · GitHub
<mjg>
now that's plain... not optimal
<heat>
gnu would have this all wrapped up in macros with some macros getting defined by random autoconf tests
<heat>
they'd also do some uname() testing that would invariably break
<heat>
oh yeah this reminds me: apparently some linux forks define their own syscalls, and glibc just happened to use a new syscall that colided with the shitty vendor one
<heat>
the guy was asking if they could instead not do that :v
<mjg>
?
<childlikempress>
syscall numbers should be uuids, change my mind
<childlikempress>
like uefi thingies
<mjg>
syscall numbers should not bea thing
<mjg>
instead you would have utf16 strings
<heat>
mjg you're reinventing early CSRG proposals stop
<mjg>
as a joke you could even add e to syscalls where it does not belong
<bslsk05>
sourceware.org: clock_gettime after 2.31 and reused syscall numbers
<mjg>
lmao
<mjg>
i have one better
<mjg>
story
<mjg>
so freebsd can run linux binaries. back in the day in order to do it you had to run "brandelf" on them to mark them as linukkz
<mjg>
some fucking guy claimed his machine would reboot every time he tried to run a binary
<heat>
either he forgot to run brandelf or he ran brandelf on a freebsd binary
<heat>
somehow it ended up calling SYS_reboot or whatever
<mjg>
individuals looking at the report geezered this out
<mjg>
it was asserted that due to mismatched syscall numbers the binary just ends up invoking reboot(2)
<mjg>
and the issue ineed no longer occurs after brandelf
<mjg>
except such a binary would not get to execute any syscalls as the loader would not have been found
<heat>
you know, lunix has a safe guard for that!
<mjg>
in other words at the time there was some elf parsing bug which was triggered by some linux binary and it crashed the kernel
<heat>
your kernel is weird
<mjg>
not "your"
<mjg>
's not my circus
<heat>
anymore
<heat>
0x28121969
<heat>
the L man's aniversary IIRC
<mjg>
i thought it was supposed to be birthdays of his children or somethin'
<heat>
his children were not born in 69
<mjg>
anyway i agree with some safeguarding against accidental root usage
<heat>
i don't really agree cuz how tf do you call the wrong syscall anyway?
<heat>
unless it's this case, in which case yeah it'd save your bacon
<mjg>
This system call fails (with the error EINVAL) unless magic equals LINUX_REBOOT_MAGIC1 (that is, 0xfee1dead)
<mjg>
and magic2 equals LINUX_REBOOT_MAGIC2 (that is, 0x28121969). However, since Linux 2.1.17 also LINUX_RE‐ BOOT_MAGIC2A (that is, 0x05121996) and since Linux 2.1.97 also LINUX_REBOOT_MAGIC2B (that is, 0x16041998) and since Linux 2.5.71 also LINUX_REBOOT_MAGIC2C (that is, 0x20112000) are permitted as values for magic2. (The hexadecimal values of these constants are meaningful.)
<mjg>
1996
<mjg>
1998
<heat>
yeah those should be his children
<mjg>
in their interpreatation the kernel failed to use the linux system call table
<mjg>
due to lack of brandelf
<heat>
how do they do linuxulator now anyway?
<heat>
some prctl-ish or personality(2)-ish syscall?
<heat>
will it die tragically if you exec a freebsd binary?
<mjg>
some bullshit in elf parsing recognizes it's not native freebsd
<heat>
oh do they use the abi field?
<mjg>
bottom line you can unpack ubuntu image, chroot into it and it just works
<mjg>
without any fuckery
Left_Turn has quit [Read error: Connection reset by peer]
theyneversleep has quit [Remote host closed the connection]
heat has quit [Remote host closed the connection]
Nixkernal has quit [Ping timeout: 252 seconds]
heat has joined #osdev
<heat>
i would purposefully break that use case
<heat>
not most distros, just debian-based ones in general