Arthuria has quit [Killed (NickServ (GHOST command used by Guest684531))]
Arthuria has joined #osdev
V has joined #osdev
heat has joined #osdev
m3a has joined #osdev
V has quit [Ping timeout: 245 seconds]
Arthuria has quit [Ping timeout: 268 seconds]
hunta987 has quit [Quit: Lost terminal]
netbsduser has joined #osdev
<geist>
it's uncouth, but what's wrong with php?
<geist>
it's close to pdp! my favorite line of computers
<childlikempress>
pdp is short for programmers despise pdp
V has joined #osdev
<heat>
the p in pdp is short for ping pong
<childlikempress>
the d in pdp is short for ding dong
<heat>
pdp stands for penis dick penis
<heat>
subscribe for more mature takes on technology
<childlikempress>
so pdp is gay and z80 is dead. what about the rest of the ancient technology?
heat has quit [Remote host closed the connection]
heat has joined #osdev
edr has quit [Quit: Leaving]
vdamewood has joined #osdev
<geist>
heh i was just pondering if i should order a z80 or two off digikey before they're gone
<geist>
probably will, though they're like $10 a pop
<childlikempress>
that is extremely bad flops/$
<mjg>
php stands for programmes hate php
<geist>
pretty hate peripheral
<mjg>
z80 huh?
<mjg>
no love for atari?
<heat>
pretty hot programmer
* mjg
<-- biased
<geist>
well zilog just announced like yesterday that they're stopping manufacturing
<geist>
thats the news, 48 years!
<vdamewood>
Programming Hell Programatically
<mjg>
:O
<vdamewood>
That means that I'll have to use ther 65C02 for my 8-bit computer needs
<geist>
but yeah i'm somewhat biased towards 6502 based stuff
<geist>
i have a stash of those though
gog has quit [Ping timeout: 245 seconds]
<kof673>
> and z80 is dead well if there is a stork then...the phoenix will birth it into the underworld. it'll be fine.
<kof673>
z80-en
<vdamewood>
I want to build a system with a 65C816
<geist>
yeah neat thing is it's basically drop in compatible
<geist>
*basically* just a few pins different
<vdamewood>
Just have to worry about the higher memory address pins
<geist>
well, to use it without 24 bit memory access, you need to obviously deal with higher addresses being plonked on the D bus and then latch it during the off cycle
<geist>
yah they reused D0-D7 for that
<heat>
the D in D0-D7 stands for deeznutz
<geist>
you like imagine dragons?
<heat>
no
<vdamewood>
I like imagining dragons
<heat>
imagine dragons are like
<heat>
kinda cheesy
<geist>
imagine dragon deez nutz on your chin
<heat>
lol
<mjg>
is this geist
<mjg>
or is this 16 y/o geist
<vdamewood>
I want a system with a dragon drop interface
<childlikempress>
geist was always secretly a 16 year old
<vdamewood>
Not always. There was a time when he was 15
<childlikempress>
lies!
<geist>
for some reason the whole deeznutz thing just cracks me up so much
<childlikempress>
you can crack up deez nuts
<geist>
i was losing it the first time i saw dr ligma video
<childlikempress>
(where by deez i actually mean mjg's)
<heat>
mjg, mofo do you have some trick to debug ref counts
<heat>
or it the trick to be permanently sad
<heat>
is the*
<mjg>
geist thinks dnd means deez nuts dragons
<vdamewood>
Both
<mjg>
heat: there is no magic trick
<mjg>
heat: there are however people who add stack tracking to them
<heat>
yeah i just got some but i feel like i'm looking at sadness
<mjg>
heat: well there is one trick: you get things right first time, then when there is a bug you can bisect
<heat>
i'm thinking about doing a flamegraph of this shite
<mjg>
you overflow or underflow
<heat>
i'm getting leaking a reference somewhere
<geist>
all problems are solved with flamegraphs
netbsduser has quit [Ping timeout: 264 seconds]
<heat>
unironically yes
<mjg>
what obj is i
<mjg>
t
* vdamewood
bisects heat
<heat>
dentries
<mjg>
you can plausibly narrow it down to the bad syscall
<mjg>
so you have it fully reproducible?
<heat>
yes, ALL TEH PATH LOOKUPS
<mjg>
dude
<heat>
yep
<mjg>
you are plaing refcount debug on easy mode
<mjg>
the fuck are you even asking on the channel for
<heat>
am i?
<mjg>
real shit happens when the leak is unreliable
<mjg>
and you can't even hope for a reproducer
<vdamewood>
I hate it when my leaks are unreliable.
<bslsk05>
โ'theneedledrop (live)' by theneedledrop (live)
<heat>
forget libcapstone, lets listen to taylor swift's new album together
<kof673>
yes, i thought someday i might try to c89 it
<kof673>
taylor swift i mean, not capstone
<kof673>
but that too
<kof673>
> MOS65XX :)
<vdamewood>
I need to send an adventurer to fetch the disc of Tay'lor for me.
<vdamewood>
Having surgery on ones foot really sucks.
<geist-sdf>
:(
<geist-sdf>
yeah i bet
<kazinsal>
friend of mine just had surgery on his dominant hand, incision was through the palm. poor dude's got basically negative grip strength right now
<geist-sdf>
oh a fun thing i discovered the other day: telnet mapscii.me
netbsduser has joined #osdev
voidah has quit [Ping timeout: 272 seconds]
<vdamewood>
I should be mobile again some time in June.
kof673 has quit [Ping timeout: 260 seconds]
netbsduser has quit [Ping timeout: 260 seconds]
vaihome has joined #osdev
<vaihome>
morning
xFCFFDFFFFEFFFAF has joined #osdev
heat has quit [Remote host closed the connection]
heat has joined #osdev
xFCFFDFFFFEFFFAF has quit [Read error: Connection reset by peer]
heat has quit [Ping timeout: 272 seconds]
<kazinsal>
man the Rocky 9 equivalent of build-essentials is missing a LOT of important shit
<kazinsal>
I want to do a nice simple `time ./doit i386 x86_64 aarch64` but nooooo I keep having to install shit that's missing...
netbsduser has joined #osdev
gbowne1 has quit [Quit: Leaving]
netbsduser has quit [Ping timeout: 245 seconds]
<kazinsal>
28 minutes to do three toolchains on four cores. not bad. much better than the old sandy bridge box
Fingel has quit [Quit: Fingel]
netbsduser has joined #osdev
zetef has joined #osdev
netbsduser has quit [Remote host closed the connection]
netbsduser has joined #osdev
zetef has quit [Remote host closed the connection]
zetef has joined #osdev
zetef has quit [Ping timeout: 245 seconds]
netbsduser has quit [Remote host closed the connection]
netbsduser has joined #osdev
netbsduser has quit [Ping timeout: 268 seconds]
zetef has joined #osdev
ThinkT510 has quit [Quit: WeeChat 4.2.2]
ThinkT510 has joined #osdev
foudfou has quit [Remote host closed the connection]
foudfou has joined #osdev
zetef has quit [Quit: No Ping reply in 180 seconds.]
foudfou has quit [Remote host closed the connection]
foudfou has joined #osdev
<geist>
not bad
<geist>
i've been playing with proxmox this evening
<geist>
leaning towards repaving my main server box as a proxmox box and then among other things having a large VM in it
<geist>
instead of the other way around where i have a server box with a bunch of qemu instances running via screen
zetef has joined #osdev
<kazinsal>
I probably shoulda done the same since I had to repave anyways
<kazinsal>
went with ESXi 7.0 which has a nicer interface than 6.5 but is deprecated as of next april
<kazinsal>
and broadcom did a broadcom and decided 8.0 doesn't get a free release
<kazinsal>
I think my next go will be a proxmox host and then do some fuckery to mount the VMFS partition hosting my VMs on that and convert them to QCOW
theyneversleep has joined #osdev
vdamewood has quit [Quit: My Mac has gone to sleep. ZZZzzzโฆ]
zetef has quit [Ping timeout: 246 seconds]
zetef has joined #osdev
citrons has quit [Remote host closed the connection]
craigo has joined #osdev
craigo has quit [Read error: Connection reset by peer]
craigo has joined #osdev
zxrom has joined #osdev
heat has joined #osdev
GeDaMo has joined #osdev
<mjg>
geist: for few years now libvirt is good enough to not be a problem
<mjg>
geist: you can use virt-manager to connect to it over ssh and manage everything from a gui
<mjg>
geist: as in you can just install a run of the mill distro and not have to fuck with qemu by hand
<mjg>
that is to say, if you insist on proxmox, more power to you, but it's not necessary for comfortable vm hosting
vaihome has quit [Ping timeout: 268 seconds]
xenos1984 has quit [Read error: Connection reset by peer]
air has quit [Quit: Client killed by user]
heat_ has joined #osdev
gildasio has quit [Ping timeout: 260 seconds]
heat has quit [Ping timeout: 268 seconds]
gildasio has joined #osdev
xenos1984 has joined #osdev
heat_ has quit [Remote host closed the connection]
heat_ has joined #osdev
air has joined #osdev
<sortie>
https://irc.sortix.org/forum/index.php โ You ever just wake up and feel hung over and realize you accidentally ported phpBB to your OS last night
<bslsk05>
โirc.sortix.org: irc.sortix.org #osdev - Index page
<heat_>
hey sortie i tried to register it didn't work
<heat_>
did you fix that yet
<heat_>
i want to say linox kornal on your forum
<sortie>
heat_, hi, are you using the provided Sortix client?
<sortie>
oh it signed me out
<sortie>
I forgot to copy down the admin password
<heat_>
lol
<sortie>
Firefox was like 'do you want to save this password' and I was like 'nah' and then I accidentally closed the terminal with the randomly generated password
<mjg>
password is: sortix > onyx
<mjg>
innit
<sortie>
no that can't be ... it worked how did you know
<sortie>
I was pleasantly surprised to find out sqlite was enough to run this beast
<sortie>
Porting something like MySQL sounded like a beast and also the word Orcacle kept popping up way too much and then I realized I actually don't have cmake yet
<mjg>
sortie: because i'm logged in as an admin
<heat_>
hi sortie do you not want to run an Oracle Database instance
<sortie>
If anyone hacked this thing, congrats
<heat_>
on Oracle Sparc?
<heat_>
you could have Oracle Numbers
<mjg>
is mariadb still a thing?
<heat_>
sure
<mjg>
it was a mysql fork after oracle takevoer
<heat_>
'tis what distros package
<sortie>
I realized with sqllite, it's actually a SNSP server
<heat_>
SNSP sounds like a scottish party
<sortie>
SNNP?
<heat_>
sooo i switched isps and i might not drop randomly anymore
<sortie>
I guess Sortix is now the official operating system of getting Scotland back in the EU.. just think of the exposure from angry people
<heat_>
otoh, can't wait to find out what exciting new router bugs there are
<sortie>
heat_, oh hey they rolled out Sortix net?
<zid>
heat_: bad news, your new ISP has onyx installed on the router
* heat_
googles the nmap os detection command
<mjg>
is it -s
<mjg>
does it even work anymore?
<heat_>
it's -O
<heat_>
i think... it's a mess
<mjg>
it used to be decent 15 years ago, but i would *suspect* things evened out a bit between systems since then
<heat_>
yeah it works pretty well i think
<mjg>
i got a bunch of vms, lemme try
<mjg>
let's try to detect open
<heat_>
oh haha this is running linux
<mjg>
it probably is, but plausibly it is not AND nmap thinks it is linux
<heat_>
it's a huawei router
<mjg>
that is linux
<heat_>
it's plausible they stole linux's network stack and are infringing on the GPL
navi has joined #osdev
<mjg>
huawei actively contributes to the linux kernel itself
<mjg>
all over the place
<mjg>
wut
<mjg>
Running: OpenBSD 6.X
<mjg>
OS CPE: cpe:/o:openbsd:openbsd:6
<mjg>
OS details: OpenBSD 6.0 - 6.4
<heat_>
yes sure to get your GPL source code you need to come to guangzhou china and wait on this dark dark alley right next to the "internment camp" thingy, don't worry about it lol
<mjg>
it is 7.5, but i already give points for spotting the type
<mjg>
infringing on gpl is liek the norm
<mjg>
Running: FreeBSD 12.X|13.X
<mjg>
aight
<mjg>
i guess it does work
<zid>
The man you meet will say "Left or right?"
<zid>
You won't understand, then you wake up in a bath of ice, but with a flash drive in your pocket
<mjg>
it failed to recognize illumos :(
<mjg>
1/10 would not use again
sortie has quit [Read error: Connection reset by peer]
sortie has joined #osdev
zetef has quit [Ping timeout: 260 seconds]
<nikolar>
What does it think about illumos
<mjg>
unknown
<nikolar>
:(
<geist>
mjg: yeah i've known about libvirt for a while, last time i messed with it i bounced off it pretty hard
<geist>
though it was a few years back, maybe it's in better shape now
<zid>
nikolapdp: 3.997?
<mjg>
geist: it works fine
netbsduser has joined #osdev
<nikolar>
Not yet zid
<nikolar>
geist I can tell you that I'm running macos with gpu passthrough through qemu and it works without issue
<heat_>
wow i'm very negatively surprised wrt huawei's legal department
<heat_>
they thought it was a great idea to list like... all copyright holders in linux
<heat_>
not sure if this is all of them or just the code they built into the kernel
<heat_>
in any case it's a huge fuckin list
<mjg>
it's what's normally odne
<mjg>
i even got copyright statement in some lul product because they copied a file
<heat_>
wtf they have uclibc AND musl
<nikolar>
In the same product?
<mjg>
maybe just some files coiped
<heat_>
yep same product
<heat_>
musl 1.1.22
<mjg>
or just a piece of code from a file with given copyright
<heat_>
also, consider this: there's an EOL'd version of openssl on it too
<mjg>
what do you expect them to d ofrom legal standpoint
<heat_>
i'm /fairly/ sure you don't need to list copyright holders to comply with FOSS licenses
<heat_>
but again, IANAL
<heat_>
the kernel is also EOL'd, fucking brilliant
<mjg>
it always is
<mjg>
i have an ebook reader with liek a 3.x kernel
<mjg>
bought 5 months ago, new
<heat_>
a router with an EOL'd kernel and openssl does not fill me with confidence
<heat_>
i would rather use theodore de raadt's software than EOL'd linux
<mjg>
wait till you find out what kind of software is being run by the biggest companies out there
<mjg>
even merely in terms of age
<heat_>
i trust google or oracle or ibm or whatever to maintain EOL software far past expiry date
<zid>
heat_: Is it the footballers that you IANAL?
<heat_>
ianal everyone
gog has joined #osdev
zetef has joined #osdev
janemba has quit [Ping timeout: 260 seconds]
janemba has joined #osdev
goliath has joined #osdev
leg7 has joined #osdev
<leg7>
hey how can I interpret the interrupt lines in the qemu dump?
<zid>
do you know what the 0008: and 0010: here mean?
<leg7>
now
<leg7>
no*
<zid>
...
<zid>
They're the selectors.
<zid>
Which are 8 and 16.. because those are the selectors you made, and loaded, and used
<leg7>
code sector of eip
<zid>
so I'm very confused why you suddenly think your code selector is 40, not 8
<zid>
your gdt isn't even 0x47 long
<zid>
in order for 0x40 to be valid
<leg7>
well according the wiki the upper bits of the binary pattern I sent you are the index of the segment in the gdt
<leg7>
or ldt
<leg7>
and my kernel code segment has index 1
xFCFFDFFFFEFFFAF has joined #osdev
<zid>
each segment is 8 bytes big
<zid>
so they're 0, 8, 16, 24, 32, ..
<leg7>
yes but the wiki says index not offset
<leg7>
that's why I used the index
<zid>
0*8, 1*8, 2*8, ...
<zid>
the index would b e 1
<zid>
so you used neither
<zid>
the 1th element in your array is at offset 0x8
<leg7>
yes I know that but since the wiki said index I thought those bits encoded the index
<leg7>
not the offset in the gdt
<zid>
the reason there are some flag bits packed onto the bottom is because they're irrelevent, given that they're 8 bytes long
<zid>
that means the bottom couple of bits are always 0
<leg7>
yes
Starfoxxes has quit [Ping timeout: 268 seconds]
<leg7>
that's why I added a _ to separate them
<zid>
8 in binary is 1000
<zid>
not 64
<leg7>
yes I didn't say it was 64
<zid>
in binary it would be: 0b0000000001_000_0_00
<zid>
<leg7> that's why I added a _ to separate them]
<zid>
one of those two statements is false
<leg7>
give me a sec I'll write it out
<zid>
You don't need to prove anything to me, I already know what 8 is in binary
<zid>
You need to figure out why *you* thought 8 was 1000000
<leg7>
the first two bits from the right are the privilege, the third is a boolean flag to look it up the ldt instead, the next 3 bits are always 0, the rest is the "index" in the gdt/ldt
<zid>
the next 3 bits are not always 0
<zid>
You've *added* the flag bits
<zid>
to the end of the number
<zid>
not treated the bottom bits of the number as flag bits
<leg7>
the value of Index is never unaligned and contains all zeros in the lowest 3 bits.
<bslsk05>
โosdev.org: Segment Selector - OSDev Wiki
<zid>
you've seen "0bx00000000 bit x is status, 0x0y0000000 bit y is control" and gone "control and status is 0x1000000001000000"
<zid>
yes, that page is bad and confusing
<zid>
you were told multiple times to use the manual instead
<zid>
and also, you *already knew* how to do this
<zid>
because you loaded 8 and 10 into cs and ss, not 40
<leg7>
I thought the segment selector for the gdt/ldt was differrent from segment registers
<zid>
the registers hold selector values
<leg7>
ok
<zid>
which is.. why you loaded the registers with values
<zid>
what did you think the 8 in cs was for?
<zid>
magic you stole?
<zid>
"The magic make it work value to load into cs is 8"
<zid>
"What does cs do?" "No idea"
<zid>
This is what it is sounding like
<leg7>
No I read to load the segment registers with offsets of the GDT
<leg7>
At the time I didn't know of "segment selectors" in the sense that privilege was enccoded in it
zhiayang has quit [Quit: oof.]
zhiayang has joined #osdev
rustyy has quit [Quit: leaving]
zetef has quit [Ping timeout: 272 seconds]
offlinemark_ has joined #osdev
<offlinemark_>
How much lockfree programming knowledge is required for basic SMP osdev? By which I mean - deep understanding of memory models, atomics, barriers, data/address/control dependencies, etc. Asking because I was trying to understand Linux's READ_ONCE() etc macros, and now find myself totally confused and intimidated.
<offlinemark_>
Or to rephrase โ what would you consider the minimum amount of knowledge needed in this area for productive osdev, if you're willing to sacrifice performance for simplicity and just "getting things going"? thx
<zid>
depends if you're doing an easy arch or not
<zid>
x86 is strong-strong-strong memory model so it's really easy
<offlinemark_>
Let's say plain vanilla x86 :)
<nikolar>
But if you want portability (to arm or riscv presumably) you need to be very careful
<zid>
you need to understand the difference between a memory barrier and a compiler barrier, beyond that
<zid>
a lot of people get confused by that
<zid>
and end up writing code that doesn't work
<offlinemark_>
Ok, so you're saying knowing how and when to use barriers is important mandatory knowledge?
<zid>
That's pretty much the only control you DO have
<zid>
The order of the instructions in the binary (compiler barriers) and the order things happen in memory (memory barriers) covers pretty much everything
<offlinemark_>
Hm, I thought there was more nuance.. such as when to use atomics (and which memory order to use with them)
<zid>
atomics are just 'don't write things to memory only partially, in case someone sneaks a read into the middle'
<zid>
you don't actually need them
<zid>
they're just handy
<zid>
there's no "atomically update this entire sql record" or "atomically update this entire struct" or whatever, you use a lock (implemented with barriers)
<nikolar>
And/or atomics
<zid>
cpu atomics are "atomically update this u32" and things at most
<zid>
so useful, but not required, you could just treat it as a struct with 4 chars in
Left_Turn has joined #osdev
<zid>
and use normal locking algo
<mjg>
offlinemark_: you don't need almost squat
<mjg>
offlinemark_: a low scalability but perfectly correct kernel will get away with locked access to everything
<mjg>
offlinemark_: in order to implement that correctly you only need to know about acquire and release fences for locking primitives
zxrom has quit [Quit: Leaving]
<mjg>
writing code which *does* scale is a fundamentlly different matter
<mjg>
and a lot of it boils down to avoiding any writes to shared areas to begin with
<mjg>
and comes with actual expertise requirements, as far as multicore issues are concerned
<mjg>
well you will also need to know about things like tlb invalidation for other cpus, but that's not strictly memory model related
<offlinemark_>
Thanks, what does "scale" look like, just out of curiosity. I assume it is measured in number of cores
<mjg>
you will be fine with most primitive variant
Turn_Left has joined #osdev
craigo has quit [Ping timeout: 245 seconds]
<heat_>
dosent scale literaly unusable
<zid>
let me guess
<mjg>
just like onyx innit
<zid>
mjg had an insane rant to the guy asking how smp works
<zid>
about scaling
<heat_>
not really
<zid>
whitequark says I won the jackpot
<mjg>
i'm pretty sure i gave concise and actionable advice, no rant that i can see
<mjg>
but zid would know better not knowing the content
Left_Turn has quit [Ping timeout: 268 seconds]
Fingel has joined #osdev
xFCFFDFFFFEFFFAF has quit [Remote host closed the connection]
zxrom has joined #osdev
<heat_>
mjg, something i've come to appreciate these last few months is how rcu can give you a nice existence guarantee
<heat_>
like holding a really big lock would, but without holding a really big lock
<mjg>
well yes, as i noted, rcu or an equivalent is mandatory for real-world scalability
<mjg>
fearlessly concurrent locked access all over is the webdev's idea of utilizing multicore
<mjg>
(is this an insane rant yet?)
<heat_>
i'm not even talking about scalability
<heat_>
just general code correctness and simplicity
<nikolar>
Are we shitting on rust
<nikolar>
FEARLESS CONCURRENCY
<heat_>
knowing the thing is Just There (despite being valid or not) is really powerful
<mjg>
if you don't care about performance, you may as well take the lock
<mjg>
so i don't think you should be raving about this aspect
<heat_>
no
<heat_>
you can care about performance and not care enough to make it super performant or super scalable
<mjg>
the one thing correctness-wise which rcu does help is avoiding establishing certain lock orderings
<heat_>
'tis why most new code in e.g linux uses locks and not rcu
<mjg>
in turn avoiding numerous deadlocks
<zid>
There's only ONE valid measure of performance heat
<zid>
and that's how many simultaneous clients can hammer on it before it falls over
<zid>
all other things are irrelevent
<zid>
how many more times do we need to teach you
<mjg>
this is *probably* why even openbsd has an equivalent
<mjg>
they don't use it much, but it is there
<heat_>
huh, they do?
<heat_>
is it quiescent state based or ebr?
<mjg>
i dont' remember, something turbo primitive
<mjg>
git grep SMR
<mjg>
it is used in the network stack, prsumably specifically to dodge deadlocks
<heat_>
that would involve checking out openbsd, and im not doing that
<mjg>
theo sent you an email
<mjg>
and you refuse to read the code?
<mjg>
show some gratitude
<heat_>
i didn't consent
<mjg>
my apologies
<mjg>
but on the note of rcu and "correctness", while it does prevent the object itself from becoming freed
<heat_>
yeah that reminds me sortie talked with me about some really awkward lock inversion that can happen in a naive tcp stack with accepted connections and their parent sock
<heat_>
which could use some rcu i think
<mjg>
as in the backing struct
<mjg>
the obj itself may get destroyed as you try to use it
<heat_>
yes
<heat_>
which is why cmpxchg or taking a lock or whatever
<mjg>
ye network stack is the primary lock order reversal driver
<mjg>
and this is where openbsd uses smr
<mjg>
well then perhaps you can appreciate that if the obj was protected with a global, you could inspect more than one without any fearzzz
<mjg>
or seqlock trickery
<heat_>
yeah it'd be great for single threaded
<mjg>
rcu makes it harder to reason about correctness (modulo deadlock avoidance), but it is worth it in plenty of cases
<heat_>
or !SMP
<mjg>
like the famed path lookup
<heat_>
what i was thinking of was actually related to path lookup
<heat_>
getting a parent of a dentry without taking 1) a big lock 2) a really weird complex mix of locks with different ordering; is super hard
<mjg>
instead of talking shit better tell me if you got to a point where you can sruvive creating more than a handful of files
<heat_>
without 3) rcu
<mjg>
ye the classic of wakling upstream is trylocking
<mjg>
it's slow af, error prone and you are likely to lose forward progress guarantee
<mjg>
but again, this here is deadlock avoided by no establishing an ordering, which i already mentioned
rustyy has joined #osdev
Starfoxxes has joined #osdev
<mjg>
now that i mention it, do you have something like lockdep?
<mjg>
or are you rusting it
<heat_>
i don't have lockdep
<mjg>
even openbsd ported an equivalent from freebsd
<mjg>
so they can check for things like that
<mjg>
sounds like your kernel sucks
<heat_>
i want to but i dont really grok the theory and stealing an impl from someone else is hard
<mjg>
well the good news is that you can give yourself poor man's verification with moderate effort
<mjg>
the idea is that you predefine a bunch of orderings
<heat_>
there's a funnier idea i'm yet to implement
<heat_>
linux has a hung task timeout system
<mjg>
so does freebsd (no, really, named deadlock detection or similar)
<heat_>
if uninterruptible sleeps go over a certain amount of time, they splat the task
<mjg>
i'm aware, one sees it a lot with any non-trivial linux deployment
<mjg>
so where do you stand with surviving file creation
<heat_>
it survives file creation
<mjg>
at SCALE
<heat_>
what scale do you want?
<mjg>
the one i tested on
<heat_>
your fs tree LRU bench?
<mjg>
s/LRU//
<heat_>
well, reclamation bench
MiningMarsh has quit [Ping timeout: 252 seconds]
<heat_>
but no i can't survive that yet
<mjg>
i'm tempted to check if sortix can do it
<heat_>
i need an LRU, and one that doesn't shaft the scalability
<mjg>
as i noted you can start with just having a global list of all inodes
<heat_>
>global list
<mjg>
that does not affect scalability
<heat_>
global lock, performance shafted, mjg triggered
<mjg>
you add inodes to the list in the constructor
<mjg>
in the slab allocator
<heat_>
i dont implement ctors
<mjg>
they don't move around on mere alloc/free, only when new pages are imported or exported
<heat_>
though i do already have a per-superblock inode list
<heat_>
i could use that
<mjg>
ther you go
<mjg>
you can even go full bsd and literally whack one inode
<mjg>
to make room for a new one
<mjg>
boo, sortix still does not have smp
<mjg>
wait, the wevpage even says no networking ,but that can't be correct
theyneversleep has quit [Remote host closed the connection]
<heat_>
it depends on the build
<heat_>
i think nightly has networking
heat_ has quit [Remote host closed the connection]
heat has joined #osdev
<heat>
mjg: anyway the real problem is handling correctness at all
<heat>
i can have a nice list of all inodes, i'll still need to find a way to correctly yank that inode without racing with anything else
<mjg>
that's becuase you are not using rust
<heat>
i can have inode yanking done properly, doesn't matter if memory reclamation is busted
<heat>
etc
<mjg>
yanking is trivial, you lock it, check the ref and unlink from stuff
<heat>
ok. now imagine someone else concurrently looks up that inode. what do?
<mjg>
for that to be possible you ar either incorrectly using rcu
<heat>
i have an answer for what do, but it's not trivial
<mjg>
or incorrectly locking stuff
<heat>
no?
<heat>
first lets establish the idea that you can't have two struct inodes referring to the same on-disk inode
<mjg>
do you rcu it or not
<heat>
for safety reasons
<mjg>
of course
<heat>
i do not
<mjg>
do you know of the "inode hash" thing?
<heat>
yes
<mjg>
both bsds and linux have one
<mjg>
there you go
<heat>
it doesn't help
<mjg>
how so
<heat>
if i yank it off the lists (sb list and hash) it'll still be alive, in a dying state, doing whatever needs to be done to kill it
<heat>
in the meanwhile, someone can look that inode up, create a new struct inode, and start fucking around with that same on-disk inode. yay, i have two struct inodes for the same on-disk inode
<mjg>
anyone trying to allocate it will have to wait for this to finish
DoYouKnow has joined #osdev
<heat>
yes
<mjg>
they find it on the hash
<mjg>
and wait for destruction if it already started
<mjg>
and then pretend they did not find it
DoYouKnow has left #osdev [#osdev]
<heat>
>i have an answer for what do, but it's not trivial
MiningMarsh has joined #osdev
<heat>
which is my point, there are tiny edge cases that need to be thought of and solved
<mjg>
maybe i'm biased, ultimatley all this just requires some proficiency in handling locking
<heat>
it's not unsolveable, it's just... harder
<mjg>
and mostly not being afraid of it
<mjg>
not that there is 0 corner cases to worry about
<heat>
it is solveable, it's just annoying and needs thought and testing
<heat>
i've done this for long enough to know that a lot of issues only come up when testing and stressing
<mjg>
what are you planning to stress this with
<heat>
it also turns out that reclaiming cached up shit is the one part of the kernel that i have the least experience with
<heat>
uhh, no clue, maybe your script
<mjg>
well you will definitely want to survive that, but it does not test the particular scenario you are worried about
<heat>
it is very hard to set up any particular scenario cuz i need just the ideal memory pressure
<heat>
so, in-kernel unit tests maybe?
<mjg>
xfstests should be able to help
<heat>
xfstests has other deps
<mjg>
100% seroius comment: i would give it a shot to port subset of stress2 from freebsd
<heat>
just as a good mkfs, fsck, mount and umount system
<heat>
what's stress2?
<heat>
i have a stress-ng port i'm yet to put into good use
<mjg>
as the name suggests a stress test suite
<mjg>
has tons of scenarios, including highly parallel fs acccess
<mjg>
creation, destruction, renames 'n shit
<mjg>
by efault it creates md-backed ufs partitions, but you can just whack that bit
<mjg>
and have it operate on a bare directory
<mjg>
this thing finds a metric fuckton of bugs
<mjg>
i would say before you go there you want to make sure fsx.c does not mess you up
<mjg>
that and dirconc
<heat>
fsx.c works well
<heat>
dirconc renames still fuck with the fs
<heat>
oh i also have fsstress and that one's messing my ext2 up too
<leg7>
When writing the stdio part of the libc do you bother trying to make it independant of your os?
<leg7>
Or do you assume stuff (like every libc I've seen assumes linux)
Left_Turn has joined #osdev
Turn_Left has quit [Ping timeout: 255 seconds]
<nortti>
how do you mean, assume stuff?
<mjg>
presumably syscall numbers, calling convention and whatnot
<mjg>
i doubt people care to even try to make it portable
<heat>
glibc is portable
<mjg>
yourt ypical libc is not
duckworld has quit [Ping timeout: 258 seconds]
duckworld has joined #osdev
Arthuria has joined #osdev
leg7 has quit [Ping timeout: 245 seconds]
dude12312414 has joined #osdev
dude12312414 has quit [Remote host closed the connection]
xenos1984 has quit [Ping timeout: 260 seconds]
xenos1984 has joined #osdev
Fingel has quit [Quit: Fingel]
xenos1984 has quit [Ping timeout: 268 seconds]
Arthuria has quit [Read error: Connection reset by peer]
xenos1984 has joined #osdev
heat has quit [Quit: Client closed]
heat has joined #osdev
Arthuria has joined #osdev
kof673 has joined #osdev
Arthuria has quit [Ping timeout: 245 seconds]
chiselfuse has quit [Remote host closed the connection]
chiselfuse has joined #osdev
xFCFFDFFFFEFFFAF has joined #osdev
leg7 has joined #osdev
gbowne1 has joined #osdev
xFCFFDFFFFEFFFAF has quit [Read error: Connection reset by peer]
carbonfiber has joined #osdev
GeDaMo has quit [Quit: That's it, you people have stood in my way long enough! I'm going to clown college!]
<bslsk05>
โcomputerhistory.org: Fifty Years of the Personal Computer Operating System - CHM
<mjg>
that was quick
<heat>
mjg, fyi stress-ng works pretty well
<heat>
dunno if you've ever used it, but they have stressers of various parts of the kernel and you can tell it to spawn N of each instance
<zid>
stressors shorten your lifespan
<geist>
scissors do too
<geist>
well, ordered a few z80s off mouser. dunno why, i'm sure there's enough of them floating around on ebay and whatnot to still be around for 100 years
<geist>
but i had to have my own, maybe i'll put them in a glass case with a hammer to break in case of emergency
<geist>
also happy 4/20 day
<heat>
wasn't expecting this from you geist
<heat>
smh
<mjg>
is this how midlife crisis looks like?
<mjg>
deez nutz jokes, weed jokes
<mjg>
next thing he is gonna post a pdp tiktok
<heat>
420 blaze it swag yolo
leg7 has quit [Remote host closed the connection]
<mjg>
you know what ip octet did my vm got on my 192.168.122.0/24 subnet?
<mjg>
.69
<mjg>
you heard that geist
<geist>
nah i dont really like to blaze up, i have asthma anyway
<heat>
everything *looks* okay, with the proper lock and all
<mjg>
why are you using different conditoins to clear it
<heat>
wdym
heat has quit [Read error: Connection reset by peer]
heat_ has joined #osdev
<heat_>
if you're getting woken you can try and unset WAITERS if the wq is clear (to avoid the wait queue traversal looking for same-page waiters)
<mjg>
your logic in the while loop looks very suspicious
<heat_>
if you're waking you can know if you see the page while waking something up
<mjg>
i can take a closer look in about 1h
<heat_>
oh yeah?
<heat_>
that'd be much appreciated <3
<mjg>
i would start with adding an assert over there that the waiters bit is set
<heat_>
yeah, my problem rn is that i have no way to repro
<mjg>
the going to sleep side should be never clearing this anyway
<mjg>
ye i think i see the race
<heat_>
oh yeah?
<mjg>
consider 2 threads waiking up in page_wait_bit
<mjg>
oh wait, they only remove themselves from the list
<mjg>
for a moment there i thought one guy could clear the flag and bail, while the other one waits on line 232
<mjg>
i'm gonna tgake a closer look after i'm done with some stuff here
<heat_>
waaaait now i think i see it
<heat_>
__wait_queue_wake also dequeues waiters. consider a wait for WRITEBACK and !LOCKED. both conditions can be transiently satisfied, the queue can be clear, and the race you describe just happens
<mjg>
why the fuck do you have 2 spots to do it
<heat_>
well, not LOCKED, cuz we grab it immediately, but maybe WRITEBACK, where it can be WRITEBACK for a bit, then clear, wakes up 2 waiters, one sees !WRITEBACK, one sees WRITEBACK and sleeps again
<heat_>
i have two spots because it looked(looks?) like a blatant missed optimization
<heat_>
i don't want to always have a spurious page_wake_bit trip after every wait
Left_Turn has joined #osdev
kof673 has quit [Ping timeout: 245 seconds]
<mjg>
that code is indeed PESSIMAL
Turn_Left has quit [Ping timeout: 256 seconds]
<mjg>
but also written in a way which suggests you are trying to fuck yourself over
<mjg>
it should be an invariant that if you are woken up, you are not on any fucking list
<heat_>
that's usually true except signals
<heat_>
it is non-trivial to do that with signals
<mjg>
ye modulo that one case which should be handled separately
<heat_>
oh, and timers if i'm waiting with a timeout
<mjg>
in which case you may or may not happen to be there
<mjg>
but for the usual case..
<mjg>
i'm saying you might received both regular wakeup AND a signal
<mjg>
while the condition you were checking for might have flipped back and forth
heat has joined #osdev
heat_ has quit [Read error: Connection reset by peer]
<geist>
heat: why are you doing it twice?
<mcrod>
hi
xenos1984 has quit [Read error: Connection reset by peer]
<geist>
ah i see mjg asked
<geist>
mcrod: 'lo!
<heat>
i *think* it makes some sense
<geist>
just to double check, make sure the compiler doesn't elide the two ands