<vin>
Won't we need a lock to ensure visibility of counter on other cores? MESI will invalidate the cacheline (counter) on other cores but doesn't gurantee the read will be latest. Also, wouldn't there be instruction reordering without a lock?
<vin>
*linux kerenel
<childlikempress>
idk linux but i assume it's the caller's responsibility to put barriers if they care about ordering
<childlikempress>
'really atomic' the linux memory model doesn't have atomic memory locations, unlike c/c++11
<vin>
Hmm then the function and struct name is really misleading "atomic_set" and "atomic_t"
<childlikempress>
again i don't know the linux memory model. but i would guess it does still guarantee that this is atomic
<childlikempress>
just not ordering
<jjuran>
"do I get compensation" <— No, you get condensation
<vin>
childlikempress: Yes, interesting that the barrier is not implemented in the function itself. Without a lock there is no guranteed visibility of the counter on all cores
<clever>
vin: there is a thing ive seen before, where basically any write of the native size/alignment (say, a 64bit write, on a 64bit machine), will always be atomic
<clever>
another cpu will either see the old value, or the new value, and nothing else
<clever>
and locks are only needed for a read/modify/write loop
gog has joined #osdev
<clever>
and down on line 52 of the x86 atomic.h, is an inline asm, to use the special incl opcode, which i believe is atomic by design
<clever>
ah, but yeah, that inc is using the lock prefix
<zid`>
jjuran: but I don't wanna be wet
dude12312414 has joined #osdev
sympt has joined #osdev
dude12312414 has quit [Remote host closed the connection]
navi has quit [Ping timeout: 268 seconds]
<vin>
makes sense clever
<clever>
vin: as for the cache stuff, i think the general rule is that only a single L1d can own a cache line at once
<clever>
so if another core wants to do anything with the cache line, the ownership has to transfer to another core
<clever>
so if you have a `uint64_t[4];` and 4 cores are constantly incrementing `foo[threadnr]`, they will be fighting over ownership of the cache line and performance will suffer
<clever>
but `foo[threadnr*64]` (with a big enough number, and array) would perform faster, with each counter in its own cache line
<clever>
vin: for x86, i think atomics are done with `lock; incl <reg>`, where reg contains a pointer? and the cpu will do a read/increment/write and hold the cache line for the whole operating
<clever>
but for arm, you have `ldex <reg>, <reg>`, which just loads from ram into a register, and requests exclusive control, but that "exclusive control" is very weak
<clever>
and then the `stex` ocpode will store back to that address, but only if you havent lost the race (still have exclusive control)
<clever>
so rather then blocking other cores, it will just fail the write step, and you can retry
heat has joined #osdev
<heat>
vin: atomic_set, et al, are all relaxed atomics
<heat>
no ordering
<heat>
(lock mov is also not a thing)
<heat>
hth
<vin>
It does, thanks!
heat has quit [Quit: Client closed]
heat has joined #osdev
heat has quit [Ping timeout: 268 seconds]
troseman has quit [Quit: troseman]
agent314 has quit [Ping timeout: 260 seconds]
bradd has quit [Ping timeout: 268 seconds]
<childlikempress>
clever: 'any write of the native size/alignment will always be atomic' this is true on basically all hardware architectures, but very much not in c/c++
<childlikempress>
so it is not at all obvious whether it's true in the linux memory model
<GreaseMonkey>
been getting my Ultimate OS Idea No Really This Time It Will Be Useful together, i have dynamic linking between modules, and there's this lovely call called "ldr.chainload" which lets me load the next module in a chain of modules to load (the initial chain being provided in a concatenated blob loaded by a bootloader)
<GreaseMonkey>
after getting the import/export machinery working (took a surprising amount of debugging - turns out fasm's "you can define something many times then review all of the old definitions" thing was reversing the order of things), i moved the text screen initialisation into its own module and made it call ldr.chainload and it honestly just worked beautifully
<childlikempress>
??
<GreaseMonkey>
so the current arrangement of modules is that they are loaded in this order: 1. the module loader machinery, which will eventually also handle memory allocation, 2. the text-mode video driver, and 3. some test program which relies on said text-mode video driver
<GreaseMonkey>
the most basic idea is that a module can export functions under given names, and can also import functions under given names from the modules before it
<GreaseMonkey>
everything happens through imports and exports and nothing outside of drivers touches IN/OUT/INT
<GreaseMonkey>
the way you initialise a driver is you load it as part of a module chain, and then once it's loaded it chainloads the next module
<GreaseMonkey>
when you're done, you do a far return
<GreaseMonkey>
if you need to clean up the driver, then when you get the return, you do your cleanup
<GreaseMonkey>
...erm, "when you're done" what i mean is when it's time for your program to exit
<ddevault>
it's been triple faulting in qemu this whole time and I hadn't noticed
<ddevault>
looks like a use after free
<ddevault>
in... the scheduler. of course.
FreeFull has joined #osdev
<nikolar>
Oh how did you how notice
<nikolar>
Lol
<zid`>
nikolar is it still easter
<nikolar>
Yes
<zid`>
k
<ddevault>
I've been narrowing in on the problem between hardware and gdb-on-qemu in lockstep and when I got close enough to the source of the problem it became clear what was going on
* kof673
points at basilisk in the corner > Primavera (Botticelli)
<nikolar>
Heh at least you know now
heat has joined #osdev
stolen has quit [Quit: Connection closed for inactivity]
rustyy has quit [Read error: Connection reset by peer]
<mjg>
note if you allow a random sucker to saturate a page, they can keep doing it to other pages as well, no?
<heat>
kernel.pid_max = 4194304
<mjg>
ultimately dosing the kernel
<heat>
vm.max_map_count = 1048576
<heat>
this is my system's limits, unmodified from arch's defaults
<mjg>
you do understand "saturation" is a lul defense against *LEAKS*
<heat>
saturating is better than making it crash spectacularly
<mjg>
something can legitimately only get so high, if it goes past that not only there is a leak but someone is actively trying to exploit it
<mjg>
but in the case at hand, of struct page, you can just prevent the problem?
<mjg>
if you are concerned with someone created too many mappings
<mjg>
if you are concerned with a leak in refcounts vs struct page, that's a different story
<mjg>
but so far it seems to be the former, not latter
<heat>
yeah but preventing it is hard
<heat>
you can say "wow that's a lul max_map_count" and i'll tell you that lots of wine programs (like video games) die on the default max_map_count (which is around 64K)
<mjg>
i'm going to wildly speculate here, so bear with me
<mjg>
with as high as 1048576 map_count still being safe on this front, and 65536 being too small for some programs
<heat>
1048576 isn't safe
<mjg>
it is not?
<heat>
nope
<heat>
pid_max * max_map_count = 4398046511104
<mjg>
i'm pretty sure one can pick pid_max and map_count where both are way higher than needed
<mjg>
don't have 4 fucking million pid_max maybe?
<mjg>
.. and safe
<mjg>
even if you had a machine to hold this in memory, there is so much linear shit in the kernel that this just straight up wouldn ot work anyway
<mjg>
i mean all of the task management code is just tech debt
<heat>
fyi everyone running systemd has 4 million pid_max
<heat>
see /usr/lib/sysctl.d/50-pid-max.conf
<mjg>
ok
<mjg>
then lower the luller number
<mjg>
systemd not being a paragon of sanity is not new
<heat>
i would not be surprised if lowering this would break someone
<\Test_User>
why not just have the mmap/munmap/etc call fail if pid_max*max_map_count is exceeding the technical limit rather than following the config for each
<mjg>
that someone should probably use less threads
<\Test_User>
then it becomes perfectly safe again
<mjg>
or add a check: if refcount would bump the page past some value, deny it
<mjg>
error out
<mjg>
but again sounds like an error condition which does not need to be there
<heat>
here's another luller value
<heat>
fs.file-max = 9223372036854775807
<mjg>
that i know
<mjg>
aka no limit
<mjg>
did you know that SOLARIS does not have a limit either?
<heat>
aren't inode refcounts 32-bit too?
<heat>
atomic_ti_count;
<heat>
yep
<mjg>
yes this one, provided enough ram, can overflow
<mjg>
with a malicious actor
<heat>
i don't think these should be characterized as security problems, because you don'tn eed an exploit
<heat>
basic system operation can get you there
<mjg>
8P
<mjg>
so you attended a night out with mrvn or something
<heat>
what?
<heat>
are you trying to tell me you *can't* get there through basic system operation?
<mjg>
no i don't think overflowing a 32-bit inode counter is what happens during "basic system operation"
<mjg>
it does happen during malicious activity though
<Ermine>
> fork a lot of processes and have them all mmap the same file
<Ermine>
does binary image count?
<heat>
ofc
<heat>
mjg, maybe not in your LULSCALE
<heat>
but if people are running systems with hundreds of TB of RAM it's bound to happen innit
<Ermine>
main frames
<mjg>
i admit i only used a system with liek 4TB
<mjg>
if someone has more than that, i would like to think they have a reason
<mjg>
and legit use for that reason still does not overflow this value
<clever>
mjg: on xfs, the inode table is distributed across the whole disk, and i think its creating too many by default, plus it picks an inode near the first data block, to reduce seek times
<clever>
mjg: as a result, if the first block of a file is >2tb into a partition, the inode# is over 32 bits in size
<mjg>
bro
<mjg>
we talkin refcount on struct inode
<mjg>
active users
<clever>
ah, i thought you meant the inode# itself
<mjg>
inode nubmers are 64-bit for years now
<clever>
yeah, refcnt is much harder to max out
<mjg>
even freebsd does it
<heat>
actually it seems like linux does not take a ref for the file, only takes a ref on the dentry
Brnocrist has quit [Quit: Lost terminal]
<mjg>
then move the problem to the dentry
<clever>
i discovered this xfs issue, because a 32bit userland util lacked the large-file flag at compile time
<mjg>
whatever
leg7 has joined #osdev
<clever>
so readdir() just went EOVERFLOW
<mjg>
why are you using 32-bit userland
<clever>
because i was targeting a 32bit machine
<heat>
pi probably
<clever>
yep
<heat>
yeah dentries have a 32-bit refc
<clever>
nfsroot on a pi, backed by xfs
<mjg>
"self-induce problems for $100"
<Ermine>
and what if refcount overflows?
<clever>
mjg: building the entire userland with large file support fixes it
<heat>
you can trivially overflow it to 1, then unref, then have a nice fat UAF
<mjg>
which distro did not?
<mjg>
large file was commonly used over 15 years ago
<clever>
mjg: nixos, it turns out several low level packages (tty font utils) dont use that flag
<mjg>
lol
<mjg>
that is a sad bug
<clever>
i can sort of see why, its a font, why is it over 4gig in size?
<clever>
nobody considered inode numbers on the font file
<heat>
ugh ino64_t is part of LFS?
<clever>
yes
<clever>
the old readdir() struct had 32bit fields
<clever>
if you want the readdir64() struct, you have to enable LFS
<mjg>
32-bit machines were a mistake
<clever>
ive also similarly run into problems with mmap, LFS, and haskell
<mjg>
rpi
<mjg>
nixos
<mjg>
haskell
<mjg>
i'm surprised you did not go with a bsd
<clever>
due to the size of the arguments, the `off_t offset` arg for mmap64(), needs some alignment padding
<mjg>
sounds like you are looking for setups which don't work
<heat>
haskell definitely works
<clever>
so there is a 32bit gap in the stack, when calling mmap64
<heat>
idk why you'd use haskell, but it works
<clever>
haskell ignores the `#define mmap mmap64` that fixes up C stuff
<clever>
so haskell called the 32bit mmap, with the 64bit mmap64 args
<mjg>
last i checked haskell runtime was classic webdev, with rwlocks calling yield()
<clever>
and it respected the ABI, and put a 32bit alignment gap in for the 64git `off_t offset`
Brnocrist has joined #osdev
<heat>
mjg, DONT LOOK AT GLIBC
<clever>
the 32bit mmap then didnt need that alignment, and read $UNDEFINED from the hole
<heat>
YOU'LL HAVE STROKE
<mjg>
(shit, or was it erlang?)
<mjg>
defo a fp lang
<clever>
and then spewed forth days of debug, because mmap said the offset wasnt page aligned
<clever>
yet it clearly is!
<heat>
LFS is so sad
<zid`>
poor linux from scratch
<heat>
i don't entirely grok it
<zid`>
catching strays out here
<mjg>
do you think LFS ships a custom patch to saturage page refcount
<heat>
drake vs kendrick, heat vs linux from scratch
leg7 has quit [Ping timeout: 268 seconds]
<heat>
LFS doesn't ship patches
<clever>
mjg: just to add to the "setups that dont work" stuff, i was cross-compiling haskell from x86 to arm, and i was using template haskell, lol
<clever>
i was then doing bloody MMIO from haskell :P
<bslsk05>
www.jerf.org: Functors and Monads For People Who Have Read Too Many "Tutorials" - iRi
<clever>
if IO is not involved, then there cant be side-effects, and the compiler is free to optimize in many ways
<clever>
so it could pre-compute at compile time, or cache the result of running something
<mjg>
needing to actually do something is the bane of FP existence innit
<clever>
ive also played with STM, its a fancy monad for creating your own custom atomics
<clever>
and at the core, its a similar design to load/store exclusive on arm
<clever>
any time you try to read an STM variable, it will (atomically) make a copy of the current value and sequence counter, and then pass that value to your code, and keep that snapshot if you read it again
<clever>
any time you write to an STM variable, it just stashes it in a temporary space
<clever>
then when you commit, it will grab a big lock, check all of the sequence counters, to see if the input hasnt changed, update the written variables, and bump the sequence counters, and release the lock
<heat>
i have to say i don't understand why anyone would use haskell for anything
<heat>
although i do admit it's a fun little language
<heat>
very recursive, math style
<clever>
if it lost the race (seq counters mismatch), it just retries the entire action
<bslsk05>
pdf.datasheetcatalog.com: Intel mXvqwzr datasheet pdf
<heat>
highly recommend you use this one and go straight to 2.5.3
<heat>
it tells you exactly what you need to do
<leg7>
site gives me 404
<leg7>
nvm
<leg7>
didn't copy the last 'f' character of the url
<leg7>
what is that controller you sent me?
<leg7>
the one that emalutaes the 8259A?
<heat>
PIIX3 is an old late 90s intel chipset
<heat>
basically the 8259 init has been set in stone for a good while, lots of bits don't do anything anymore
<heat>
and you don't have a real 8259 from the late 90s onwards anyway
<gog>
the real 8259 is the friends we made along th eway
<leg7>
so the "chipset" is the motherboard chip that emulates all the old controllers?
<gog>
idk how much it emulates them, it's more that their functionaltiy was integrated over time to reduce cost
<leg7>
ok
<gog>
and also that only relevant modes of operation are implemented
gbowne1 has joined #osdev
<gog>
idk, the feature scale between when the 8259 was invented and today is massive
<heat>
yes it emulates lots of stuff
<gog>
ok
<gog>
idk what i'm talking about :D
<heat>
there's no 8259 anymore
teardown has joined #osdev
<gog>
i should just focus on cheese and meow
<heat>
i believe
<heat>
maybe you're right
<gog>
and webdev
<leg7>
yeah I figured from reading some stuff. I downloaded the manual for the chipset that is supposed to emulate all of the old controllers but I found the manual to be worse than the ones for the old controllers
<leg7>
so I stuck with the old manuals
<gog>
if you really want an emulated classic 8259 just fire up bochs
<heat>
the new ones tell you exactly what you need to do
<heat>
because they don't support anything else :D
<heat>
no one knows what Edge/Level Bank Select means
<bslsk05>
osdev.org: Advanced Integrated Peripheral - OSDev Wiki
<leg7>
that was the man I downloaded
<heat>
you're downloading men??
<leg7>
manual
<leg7>
manuel ;)
<heat>
menual
<Ermine>
in other news, netbsd xorg uses EXA
leg7 has quit [Read error: Connection reset by peer]
netbsduser has quit [Ping timeout: 256 seconds]
foudfou has quit [Ping timeout: 260 seconds]
foudfou_ has joined #osdev
netbsduser has joined #osdev
GeDaMo has quit [Quit: 0wt 0f v0w3ls.]
<netbsduser>
dug up my old rough outline of a namecache
<heat>
Ermine, i see you're bored (you're looking at netbsd and xorg), want to review my new readahead code?
<netbsduser>
if i had planned it today instead of a year ago i think i would've made this more RCU-friendly (but i can always do that later)
<netbsduser>
i'm moving to the dragonfly bsd model where the namecache is no mere cache but (through pinned entries) represents the namespace with mountpoints and such
<heat>
good idea, that's the linux model too
<netbsduser>
yes, i think you call it a dentcache there, and it has an RCU-based resolver available
<netbsduser>
one really strong merit of it
<heat>
dcache
<netbsduser>
i don't know if you've seen the nullfs code in netbsd or freebsd. i don't like it
<heat>
what's nullfs?
<netbsduser>
it had to be written by rocket scientists (nasa) and it creates shadow-vnodes for underlying vnodes
<netbsduser>
it's what linux calls a bindmount
<netbsduser>
but not quite as it only binds one FS
<heat>
something awful that i've been planning to do for a while is an overlayfs (or unionfs or whatever)
<netbsduser>
i love the idea of one of those but it seems scary, moreso than a nullfs
<azonenberg>
tl;dr the STM32 I'm running on has a silicon bug where pin PB4 is able to be configured as either (among other things) SPI data out or JTAG reset
<azonenberg>
the *intended* behavior is that JTAG just runs in 4-wire mode without TRST (i.e. you have to do the state machine based reset with TMS) if the pin is configured in SPI mode
<azonenberg>
the *actual* behavior is that if you ever set the pin to anything but JTAG mode, it immediately resets the TAP and you lose your jtag connection
<azonenberg>
But I need to use both JTAG (to debug / flash the chip) and SPI (to get data out of this micro which is a peripheral of the main system MCU)
<azonenberg>
So i'm constantly switching back and forth, keeping it in JTAG mode unless actively executing a command that requires readback
<azonenberg>
This worked great until i crashed the board during processing of one of those commands and couldn't debug the crash or even reset the chip without a power cycle
<azonenberg>
So now i have to make my crash handler put the pin back in jtag mode lol
<Ermine>
heat: ok, but remember that I'm noob
chiselfuse has quit [Remote host closed the connection]
Gooberpatrol66 has quit [Ping timeout: 260 seconds]
<mjg>
scoped_mutex g{vmo->page_lock}; if (!vmo->insert_page_unlocked(off, p))
<mjg>
what's unlocked in this context? :p
<mjg>
did you name it backwards
<heat>
i usually name the versions that don't grab locks _unlocked
<heat>
or just go full linux and ______
<mjg>
that's some bullshit right there
<mjg>
if it expects the fucking lock to be held, which it seems to, it sure as fuck should not be _unlocked
<mjg>
like wtf
<heat>
sorry
<heat>
send patchen
<mjg>
maybe you would have easier time seeing the absurdity if you had proper asserts
<mjg>
then your foo_unlocked(lulpage_t page) would start with assert_lock_held(page->lock);
<mjg>
or so
<heat>
mon see DCHECK and CHECK
zetef has joined #osdev
leg7 has joined #osdev
<heat>
you know what i really hate? the name vm_object
<heat>
address_space is much worse, but vm_object is still crap
leg7 has quit [Ping timeout: 256 seconds]
<netbsduser>
readahead by heatd
<netbsduser>
the new fragrance coming soon
<heat>
lol
<netbsduser>
earliest reference i have found to "vm object" is mach and i assume it proliferated via mach's big influence
<heat>
tbf i can't find a better name
<netbsduser>
i think it's an alright name
<heat>
pagecache? vm_mappable?
<heat>
struct pagecache is slightly imprecise but it makes some sense
<mjg>
you can't find a better name?
<mjg>
should be easy by your taste
<mjg>
since it's vm related, the vm thing is out
<netbsduser>
windows calls them SECTION objects apparently
<mjg>
how about vfs_locked
<heat>
hilarious
<mjg>
i am chuckling a little ngl
<heat>
SECTION is ass too, vm_mappable i don't like too much but it's at least more specific than vm_object
<heat>
and in the same spirit
<zid`>
a conspiracy by big mach
<mjg>
i do agree naming an object 'object' is not very helpful
<mjg>
typical invention from the department of redundancy department
<netbsduser>
they call them segments in solaris, don't they?
<mjg>
hm
<heat>
aren't segments the maps?
<mjg>
they do have vm_seg or so, but i don't know if that's the equivalent
<mjg>
right
<netbsduser>
actually i think segments might be the map_entries
<netbsduser>
with "segment drivers" that are not conceived of as objects but as a control block full of subroutine references
<heat>
i think all structs should have a _struct at the end
<heat>
really helps emphasize the structiness
<mjg>
no, they should have it in the front
<netbsduser>
struct task_struct;
<netbsduser>
for better or for worse it looks vm object is the name most people prefer now
<mjg>
vm_struct_object
<netbsduser>
even people with no connection to nor awareness of the mach tradition and how modern-day BSDs directly inherit from that first portable VMM
<netbsduser>
(well, in openbsd and netbsd only in the form of a successor which kept the good and threw out the bad, like the vm object chains for cows)
<mjg>
who would like to scale illumos vm a little bit
<mjg>
:X
<netbsduser>
i wish i could find out about the famous VM2 project that was carried out for Solaris
<mjg>
if i had to guess it mostly consisted on replacing the webdev multicore support
<netbsduser>
because it was a Solaris project it must have been the king of scaling, it would scale right up
<mjg>
here is an example
<mjg>
anon_decref(struct anon *ap)
<mjg>
ahm = AH_MUTEX(ap->an_vp, ap->an_off);
<mjg>
mutex_enter(ahm);
<mjg>
if (--ap->an_refcnt == 0) {
<mjg>
... }
<mjg>
what could be an atomic dec unless 0 is lock-protected
<mjg>
with the lock coming from a global hash table
<mjg>
basically slow single-threaded and avoidably collides with unrelated pages
<netbsduser>
ah, mutex
<netbsduser>
tell me at least that's a spinlock in a mutex's guise
<mjg>
solaris mutexes have adaptive spinning
<mjg>
which is the only sane thing about them
<netbsduser>
some of them are exclusive spinners (my least favourite element of solaris, and unfortunately replicated by most BSDs)
<mjg>
?
<heat>
mutex_lock_spin?
<mjg>
that is for actual spinlocks
<netbsduser>
some mutexes on solaris don't wait only spin
<netbsduser>
they have the same type
<netbsduser>
but you initialise them with a flag to tell it to be a pure spinlock
<mjg>
well presumably that's for code which can't go off cpu
<netbsduser>
i don't dispute the value of it, who among us would denounce the spinlock?
<netbsduser>
but why make it look identical to a mutex that you can sleep on?
<mjg>
there are spinlocks you literally can't avoid
<mjg>
it's not a matter of liking or disliking them
<mjg>
wewll that i 100% stupid, totes agreed
<heat>
yeah
<mjg>
part of my gripe with SUN ENGINEERING ETHOS
<heat>
type safety is cool
<heat>
that's why linux moved to folios instead of compound page magic
<mjg>
to my understanding this kind of bollocks came to be to "increase robustness"
<heat>
that it brought speedups is only a side effect
Gooberpatrol66 has joined #osdev
<mjg>
heat did you steal folios yet
<heat>
not yet
<netbsduser>
i like the idea of the "folios" but i don't make much use yet of "large pages" nor any other grouping of multiple pages
<heat>
^^
<netbsduser>
it would be nice to implement a page combining daemon some day though
<heat>
late stage folios are going headed into another direction
<heat>
basically the late stage folios plan is memdescs
<heat>
where the struct page is just a pointer to something else
<mcrod>
i
<mcrod>
*hi
<heat>
and that something else is allocated at alloc time
<netbsduser>
a googler and linux kernel contributor on the osdev discord is always going on about where folios are going
<netbsduser>
he loathes and despises struct page and frequently talks of how many millions it costs google every year
<heat>
high profile guy?
<mjg>
is that matthew wilcox or so?
<mjg>
on discord?
<netbsduser>
but until you said memdesc i had no idea how folios were supposed to solve it. now it makes sense
<heat>
willy works for oracle
<netbsduser>
i don't know his real name, he goes by bindage or binder
<mjg>
hm
sortie has quit [Quit: Leaving]
<heat>
ironically most of the great recent vm work was done by oracle
<heat>
vma RCU, maple trees, folios
<mjg>
and it's not the people who did solaris vm
<mjg>
:)
<Ermine>
have they bought patent license?
<mjg>
?
<mjg>
rcu is free for use with gpl code if that's what you mean
<heat>
and lgpl
<Ermine>
solaris isn't gpl is it
<mjg>
this is not done in solaris
<mjg>
solaris is dead and burried
<Ermine>
ah
<heat>
solaris is actually still in use for Big SPARC
<Ermine>
i saw oracle and thought solaris :]
<netbsduser>
rcu classic edition is free for all now
<netbsduser>
the patents went out of date
<mjg>
Ermine: oracle was always a linux shop as far as shipping an os goes
<netbsduser>
turning them into a helpful free-access resource for how to implement them if you can get through the bs patent gobbledygook about "modules" and silly diagrams
<Ermine>
there are maple trees in question, so it's not the classic rcu i presume
<mjg>
solaris is a stepchild which came with sun
<heat>
Ermine, maple trees have nothing to do with RCU
<heat>
except that they use it
<mjg>
and it is not welcome
* geist
drive by eye rolls
<Ermine>
hi geist
<geist>
o/
<mjg>
geist: just admit you have a higlight on "solaris"
<geist>
if i did that i'd go insane with the amount of notifications on my phone
<mjg>
i thought you are insane
<mjg>
my apologies
<geist>
says someone still completely stuck on solaris
<mjg>
ey i migrated long time ago!
<mjg>
now i'm mostly shitting on RUST
<geist>
word.
<mjg>
which btw is loved by sun diaspora
<heat>
swear to god you people are going to make me move to discord
<mjg>
so it is a natural progression
<geist>
heat: right?
<Ermine>
do they use xorg for windowing system?
<geist>
it's old farts arguing about irrelevant stuff
<mjg>
well according to netbsduser discord has a guy shitting on struct page
<mjg>
if that's something you like, i understand
<heat>
struct page is shittable
<mjg>
geist: says fucking guy with vaxen in his basement
<mjg>
:)
<geist>
yeah but i'm not arguing about them
<netbsduser>
managarm famously doesn't have one themselves
<geist>
OMG DEC 512 byte pages OMG WHAT WERE YOU THINKING
<geist>
PESSIMAL
<heat>
LITERALLY SO SMALL WTF
<netbsduser>
which was the first machine to have page tables of the modern kind?
<heat>
yo geisten feel this
<heat>
page tables that do page table access themselves
<netbsduser>
vax can be forgiven for its primacy
<heat>
virtually mapped page tables
<mcrod>
heat doesn't talk to me anymore
<heat>
like WTF
<mcrod>
maybe I have to get him a new PC
<geist>
heat: omg right?
<netbsduser>
heat: necessary for space saving
<heat>
no they're not needed wtf IT IS 2024 we can see it's a shite idea
<netbsduser>
they have to be able to swap them to disk, being linear
<heat>
if its shit now it was shit 30 years ago
<geist>
netbsduser: you mean multi level page tables? hmm. i'd say something like 68k, but i get the feeling that it was already a fairly established pattern
<heat>
mcrod, do it
<geist>
the early 68882 i think MMU (or was that the FPU)? chip did that
<mcrod>
it probably costs a lot of money to get something to portugal
<mcrod>
from the US no less
<netbsduser>
geist: yes, i think the same, the early 68k separate MMUs had them, and by god, they had them in style
<geist>
also. gasp. early 3 level sun 3 page tables, which i think was their own design
<netbsduser>
customise how many levels, page size,e verything
<geist>
yah
<zid`>
portugal is closer to florida than new york is at least
<geist>
but i'm guessing that by then there was maybe some minicomputers or mainframes that would have had page tables of that design
<geist>
i have no idea what say IBM machines in the late 70s did
<geist>
i *think* vax may have been the first time paging sort of got into the superminicomputer market though
<heat>
a superminicomputer is just a computer
<geist>
well it was a marketing term that DEC used for vax, but basically was a slot between mainframes and minicomputers
<geist>
in taht you had a minicomputerish class machine (price,size,power,etc) that could run more big iron stuff
<Ermine>
minisupercomputer or superminicomputer
<geist>
but yeah i get the joke
<geist>
(--computer)++
<heat>
i do not like the marketing term
<heat>
are the marketing guys for the VAX still kicking it? i need to make some calls
<geist>
PESSIMAL marketing
<Ermine>
superminicomputer reminds me of those raspberry pi clusters
<mjg>
aight i'm now offended
<mjg>
i'm gonna call out any arguments about old stuff
<mjg>
:X
<geist>
hey i only answered because netbsduser asked a legit questiona bout old vax stuff
<geist>
i would have otherwise not just started talking about it
<mjg>
well you don't have to entertain talks about old irrelevant stuff
<mjg>
:X
<geist>
that's the spice of life mang
<mjg>
did not you complain about me talking about old irrelevant stuff just few minutes prior?
<mjg>
other than that i agree
<MrBonkers>
Damn, 10 minutes late after being summoned with a Managarm ping. I’m slow
<heat>
mrustc mrustc mrustc
<heat>
hi!
<MrBonkers>
Mrustc, interesting (but god no)
<zid`>
FEARLESS RUST
<heat>
oh wait not mrustc
<heat>
mlibc?
<MrBonkers>
trigger seen
<heat>
lol i seriously got it mixed up
<MrBonkers>
lol
<heat>
geist, why does zircon's vm_page_t have a paddr_t paddr_priv?
spareproject has quit [Remote host closed the connection]
teardown has quit [Ping timeout: 260 seconds]
<geist>
i think it's just for a speed thing to look up the page
<geist>
page_t -> paddr
<heat>
is your page map not contiguous?
<geist>
it is not
<heat>
generally you can get by doing pointer math
<heat>
ah
<geist>
well more to the point, there can and are multiple arenas of pages
<geist>
so based on how many page segments you have it turns into an O(N) search
<heat>
there's a fun idea there, where even if your struct pages aren't contiguous, you map them virtually contiguous
<geist>
yah i was thinking precisely that just now
<heat>
and then the math still works, and you save 8 bytes
<geist>
yah
<geist>
i dont particularly like the paddr_priv thing, but it's also a priv because there's an accessor to get it, iirc
<geist>
and it may be bit packed in with other things since you dont need all of the bits
sortie has joined #osdev
<netbsduser>
heat: i was thinking of doing just that
<netbsduser>
gives me an extra word to play with
<heat>
yeah you could also just store the pfn and use some other encoding (leb128 for example, but i think google has a new fun OPTIMAL encoding too)
<heat>
but the zircon vm_page_t is remarkably small, congrats
<heat>
i don't obsess with struct page size but some structs are just too damn big
<heat>
solaris and illumos's ones are like 200 bytes long
<geist>
yah my guess is if/when we get around to switch to a buddy allocator or whatnot, things will get a bit reorganized
<heat>
my target is 64 bytes (a full cacheline for each page)
<gog>
hi
<geist>
one of the strategies to avoid the O(N) search is to just store say a 4 bit arena number in the vvm_page_t
<geist>
and then use that ti index into which arena it is
<netbsduser>
where's the zircon vm_page_t defined?
<heat>
geist, yeah linux stores zone id (which itself is math between the NUMA node id and the node's buddy zones)
<geist>
yeah
<heat>
steals some bits off of flags
<heat>
currently i check every zone because i don't support numa and i have like 2-3 zones
<geist>
yah
<geist>
there's definitey some bit packing we can do in there and itmay make sense to make a pass over that file and at least pull out a bunch of those accessors that got slammed into the middle of it
<geist>
probably could move the state field to share the paddr_priv
<geist>
but it only really helps if you can shave off a solid 8 bytes beecause it ends up aligned on that
<heat>
yeah
netbsduser has quit [Ping timeout: 240 seconds]
Gooberpatrol66 has quit [Remote host closed the connection]
<Ermine>
since which standard it is valid to use if (statement1; statement2) in c++ ?
<heat>
C++17 it seems
<heat>
it is *really* handy
<Ermine>
go people do like this too
<nikolar>
For F1 fans, verstappen didn't win
<heat>
my team just lost the league
<zid`>
LA LIGA
<zid`>
I hear total underdogs Realm Adrid won it
<heat>
la liga is spanish
<zid`>
That's the joke
<zid`>
You're spanish
<heat>
skrew u
<zid`>
nikolapdp is bosnian btw
<heat>
oh
<heat>
lando won??
<zid`>
lando norris?
<heat>
very fucking cool, congrats lando calrissian
<heat>
yeah
<heat>
i mean, it's what google's saying
<zid`>
won what? f1 drivers champ?
<zid`>
He's only *checks internet*, 48% of the way to max's points, notbad
<heat>
won the race
<heat>
i think it's his first win?
<nikolar>
Let's go Norris
<zid`>
nikolar: I said, ur bosnian
<nikolar>
That's right heat
<nikolar>
I not Bosnian
<zid`>
correct response was "skrew u"
<nikolar>
skrew u
<zid`>
terry area tomorrow right?
<zid`>
I need to get you through the base game before calamity 1.0.4 hits