<zid>
I don't approve of writing code that assumes things like that regardless, what if you wanna port our.. x86 jump_label_gen_branch to a dead risc cpu!?
stolen has joined #osdev
<heat>
no
<heat>
i would only port it to dead VLIW cpus
colega has quit [Quit: Leaving]
<heat>
gosh how do I patch a live system easily
<zid>
down all APs
<heat>
sounds bad
<zid>
stop all processes
<heat>
i could int3 it, sync icaches, write the real instruction, sync again?
<zid>
I think you should unmap the page
<zid>
write to it through a different mapping, and set up a special fault handler for anything that faults from the missing mapping
<heat>
actually since i need an IPI anyway... broadcast to live CPUs, make em spin for the write, flush icache, resume?
<zid>
flushing icache isn't needed on x86 btw
<heat>
it is, on SMP
<zid>
you and your fancy smp, geez
<heat>
you need a serializing instruction
<heat>
that does the trick on automagic x86
<zid>
you don't even *need* one of those
<zid>
it just helps certain cpus that don't snoop as aggressively
<zid>
I don't even know which ones those are
<heat>
you do, it's in the manual
<zid>
yes, I am talking about *in practice*
<zid>
only *some* cpus need it
<zid>
which, in a manual, means all cpus need it
<zid>
you can just execute mov [rip+4], blah quite handily and have it execute first try, on any cpu i've actually found
blop_ has quit [Remote host closed the connection]
blop_ has joined #osdev
qbasiq has joined #osdev
edr has quit [Quit: Leaving]
<heat>
gosh i need to write this properly tomorrow
<heat>
but in principle i have nearly-zero-cost branches
<heat>
basically a similar idea to linux static_keys
<heat>
just asm gotos that i int3 at compile-time and then patch really really early
<zid>
yea I always wanted to do this for config options in my emulator
<zid>
instead of if(blah_option) this;
<zid>
or replacing chunks with a function pointer
<heat>
keys that are true or on the "likely" value are just nice big fat 5-byte nops
<heat>
then if they're enabled at runtime you just patch in a jmp/nop and that's it
<zid>
are you explaining this to me?
<heat>
idk
<heat>
im just saying what i did
<zid>
just like hearing yourself think, I see
<zid>
maybe you can find a nice footballer and whisper this into his ear, really get him into you
<geist>
no, i find it useful when reading things back
<geist>
like, i'm following along with what heat is saying and then sitting here with a hmmmm expression on my face
<zid>
I think it has half a shot
<geist>
thumb and index finger to my chin, looking up
<heat>
🤔
netbsduser` has quit [Ping timeout: 240 seconds]
<heat>
i theorize that a call alternative could be possible and as such avoid a nop but that's microoptimization
<heat>
i really doubt that some efficient nop sequences sprinkled on real code have measurable overhead
<heat>
(see, i can say this and mjg can't interject because it's too late)
<zid>
yea almost done unless you're heavily decode bound
<zid>
done? none
<zid>
and x86 can decode a *lot* of nops per second just fine
<zid>
remember we have uop caches and shit
<zid>
you'd only pay the penalty for a nop decode directly after a bad mispredict or something
<geist>
so obvious question: how d yoimplement this on other arches?
<zid>
The obviousier question is
<zid>
where do the jumps come from
<zid>
that's the real hard part
<zid>
embedding control flow with asm("") and coming up with a label scheme, etc, is the gross part
<geist>
indeed, and whatever sort of register allocation/code flow bubble it may need to generate in case a branch *may* be needed
<kof123>
> find me a big endian x86 sort of Numeric values in VOS are always big endian, regardless of the endianness of the underlying hardware platform. On little endian servers with x86 processors, the compilers do a byte swap before reading or writing values to memory https://en.wikipedia.org/wiki/Stratus_VOS
<heat>
that's cute but why WriteProcessMemory if its the same proc?
<zid>
That's a fairly good point, just felt right, heh
<zid>
if(c < 0x70 || c > 0x7B && (c != 0xE3 && c != 0xEB && c != 0xEB && c != 0xE9))
<zid>
is a great line
<zid>
I have no idea what it means
<heat>
&& c != 0xEB && c != 0xEB
<heat>
better check it twice
<zid>
ikr
<heat>
might've changed in the meanwhile!
<zid>
volatile unsigned char c;
<geist>
hmm, what else was special about 0xeb
<geist>
0xEB sticks out somehow
<zid>
yea we mentioned it 20 seconds ago
<heat>
eb is jmp imm8
<geist>
like it's the magic value... actually maybe it's like the first byte of a binary?
<geist>
because branch....
<geist>
is this where MZ comes from?
<heat>
oh
<heat>
FAT bootsector?
<zid>
yea
<geist>
aaah yeah maybe that's it, yeah
<zid>
fat bootsector is my guess?
<geist>
first byte of a bootsector, because jump
<zid>
MZ is 4D 5A
<zid>
dec bp pop dx?
<heat>
yeah MZ isn't anything special
<heat>
pretty sure the a.out magic also had special meaning for the PDP11
<heat>
asm goto really is magic
<heat>
fuckin nice
<geist>
yeah the fun one is the MZ sequence is thankfully inert on arm64, so you can have a UEFI looking binary that you also allow offset 0 to be an entry point
<geist>
then after the MZ sequence you toss in a real arm64 jump to the actual code
<heat>
yeah i think riscv also has the same trick
<geist>
yah haven't mapped out what MZ maps to
bnchs has joined #osdev
<heat>
/*
<heat>
* This instruction decodes to "MZ" ASCII required by UEFI.
<heat>
*/
<heat>
c.li s4,-13
<geist>
oh noice
frkzoid has joined #osdev
<geist>
though without C extension it's a fault
<heat>
oh that sucks
<heat>
so you can't enable CONFIG_EFI without C
<geist>
well, i think that's only if you also intend for it to be branched to at offset 0
<heat>
yeah and that's the standard riscv64 linux boot protocol
<heat>
which does not seem disableable
xenos1984 has joined #osdev
Hammdist has joined #osdev
<heat>
anyway i need to go to sleep, bye bye
<Hammdist>
so I fixed my page tables. to debug, I put print statements in qemu's page table walker. turned out I was setting BLOCK flags where it should have been PAGE
<geist>
oh that'll do it!
heat has quit [Ping timeout: 258 seconds]
terminalpusher has quit [Ping timeout: 245 seconds]
Hammdist has quit [Quit: Client closed]
[itchyjunk] has quit [Remote host closed the connection]
qbasiq has quit [Ping timeout: 240 seconds]
duderonomy has quit [Read error: Connection reset by peer]
duderonomy has joined #osdev
gog has quit [Ping timeout: 255 seconds]
Hammdist has joined #osdev
<Hammdist>
hi all. I am now trying to execute a program at EL0 (aarch64). I -think- I'm dropping to L0 correctly, but when the program does an svc, this results in trap slot 4, not 8. to me, this indicates the el level was not actually changed properly. here is my el changing code: https://paste.ee/p/6dKiM . any ideas? maybe not the exact problem but how to
<Hammdist>
debug? is there a way to determine from gdb+qemu whether the drop to l0 was successful?
<bslsk05>
paste.ee: Paste.ee - View paste 6dKiM
<Hammdist>
I know one apparently can't read currentel from qemu ... that is a bummer
<Hammdist>
ah with -d int it tells me I returned to EL0. hmm
<Hammdist>
ah -d int further reveals it's actually taking two exceptions so the first one might have the right address, but it faults further
zxrom has quit [Remote host closed the connection]
stolen has quit [Quit: Connection closed for inactivity]
<geist>
ah there you go
<geist>
yeah some sort of double fault would do it. suggestion: put an infinite loop in your 'from EL0' handler first, to see if it makes it
kneskade has joined #osdev
benlyn has quit [Read error: Connection reset by peer]
kneskade has quit [Ping timeout: 246 seconds]
<kazinsal>
god, someone linked me the 8088 MPH demo and I'd forgotten this masterpiece was 8 years ago
<kazinsal>
1024 colour stills and patterns and sprite emulation on a CGA
<kazinsal>
also some fantastic music coming out of a beeper
benlyn has joined #osdev
GeDaMo has joined #osdev
gog has joined #osdev
<geist>
oh yeah that was fantastic
<geist>
speaking of slow, just got the old VAX running netbsd again
<geist>
even with netbsd 3.0.3, circa 2007, it's already wayyy underpowered
<kazinsal>
yeah, last time I booted mine up with netbsd 5 it took a solid 15 minutes before I had a console
<kazinsal>
never managed to get ssh working on it, the crypto took longer than the TCP timeout
<geist>
yep, just tried sshing into it now, but it has too old ciphers for modern linux to talk to it
<geist>
telnet to the rescue
<geist>
just have to enable it in inetd.conf
<kazinsal>
yeah, my thought if I ever wanted to give vax access to a group of people would be to give them an account on a linux machine that would sync their account info to the vax and have a shell doing a passive telnet login to said vax
<geist>
looks like a sizable amount of the 8088mph demo are a bunch of race the beam tricks
<kazinsal>
but I never got around to it before my vax released the magic smoke
<geist>
i couldn't get the scsi2sd thing working the other day so given that i may have fried it i ordered a new replacement. zuluscsi, looks neat
<Hammdist>
hello. now my guest is trapping on swpal. is there an enabling bit for allowing the guest to perform swpal?
TheCatCollective has joined #osdev
kleebane has joined #osdev
<ddevault>
the swp instructions were removed from ARMv8-A
<ddevault>
ref. The Big PDF, section 8.3.2
gog has quit [Quit: Konversation terminated!]
<Hammdist>
hurr does that mean cortex-a53 is or isn't capable of swpal?
xenos1984 has quit [Ping timeout: 246 seconds]
<Hammdist>
well if there isn't an enabling bit it seems at least qemu thinks a53 should not be capable
<ddevault>
is not, I think.
xenos1984 has joined #osdev
nyah has quit [Quit: leaving]
qubasa has joined #osdev
bnchs has joined #osdev
mcfrdy has quit [Server closed connection]
mcfrdy has joined #osdev
zxrom has quit [Quit: Leaving]
danilogondolfo has quit [Quit: Leaving]
kleebane has left #osdev [#osdev]
gog has joined #osdev
nyah has joined #osdev
Burgundy has quit [Ping timeout: 258 seconds]
<qookie>
Hammdist: ddevault: looking at the armarm, swp was added in v8.1, with FEAT_LSE
<ddevault>
ah, alright
<qookie>
so the cortex-a53 doesn't have it (nor does the a72, so none of the 64-bit rpis)
<Hammdist>
then I guess I might have to emulate these instructions in my kernel as the compiler for the guest program has no feature switches for arm64 (it's a wishlist item)
<heat>
>These instructions are already used after a capability check
<heat>
so your capability check code is borked
<heat>
geist, im going to add riscv64 static branching support next, the codegen looks kinda straight forward
<heat>
you need 2 nops, one for the jal, one for the possible auipc
<Hammdist>
hrrm I did look at the asm and it didn't look like there was a capability check in this case. maybe I'm wrong though. as far as how the program would test capability I did notice it reading midr_el1 but I just passed through the value available in kernel space. everything else would be up to qemu to declare capabilities correctly which I would
<Hammdist>
think it does
<moon-child>
owie! my personal computer!
<heat>
wait, guest? this is a hypervisor?
<Hammdist>
no the guest runs in el0, my kernel in el1
<heat>
oh ok that's not a guest
<heat>
just a program
<Hammdist>
well the kernel is a program too I guess
<Hammdist>
let me post the disasm of the code in question
<qookie>
line 15 jumps over the swpal into the ldaxr/stlxr code path
<qookie>
and both then merge at line 23
<Hammdist>
ah hm. well that could be a check then. I was looking for a movbu like in the example
Hammdist has quit [Quit: Client closed]
Hammdist has joined #osdev
<Hammdist>
guess I might have a look at the source code of this runtime.lock2
<heat>
what exactly are you doing?
<heat>
weren't you like, erm, doing basic board bringup a few weeks back?
<heat>
how doz bord werk -> 2 weeks -> fully fledged go port?
<Hammdist>
well I guess I copied a lot of existing MIT/BSD code from other kernels and I'm trying now to put together enough of a kernel to run go programs
<heat>
frankenkernel?
<heat>
sounds spoopy to me
<Ermine>
frankix
zid has joined #osdev
<gorgonical>
frankenstein's monstix
Left_Turn has quit [Read error: Connection reset by peer]
Left_Turn has joined #osdev
Left_Turn has quit [Remote host closed the connection]
Bitweasil has quit [Server closed connection]
Left_Turn has joined #osdev
Bitweasil has joined #osdev
qubasa has quit [Ping timeout: 255 seconds]
<gog>
hi
<gorgonical>
hello
netbsduser` has quit [Ping timeout: 244 seconds]
Turn_Left has joined #osdev
<gog>
i'm not as sad today as i was yesterdday
<gorgonical>
that's good to hear
Left_Turn has quit [Ping timeout: 255 seconds]
<Ermine>
That's poggers
<gorgonical>
have you ever signed the book at the top of mt esja?
<gog>
no i haven't done the hike
<gog>
i meant to this summer but life happens
<gog>
next year
<gorgonical>
I can recommend it. I was out there until like 11pm and it was still light because you live in fairyland
<gog>
true
<zid>
henlo
<zid>
my internet was broken again today
<zid>
I mean, the internet
<gog>
henlo
<zid>
what did you do while it was down?
<gorgonical>
I went and got a haircut and ate pizza
GeDaMo has quit [Quit: That's it, you people have stood in my way long enough! I'm going to clown college!]
Left_Turn has joined #osdev
Turn_Left has quit [Ping timeout: 246 seconds]
<Hammdist>
well I got past the problem with the capability test - issue was I had made a copy of the stack data from a run of qemu to seed the execution of the l0 program. however I hadn't specified -cpu so instead of cortex-a53 it was probably using -cpu max or something. the capability was ultimately detected from the auxv data. fixed easily by specifying
<Hammdist>
-cpu cortex-a53 to qemu user mode emulation and then copying the stack data again
osdever has joined #osdev
<bl4ckb0ne>
is there a common naming when refering to a { uintptr_t phys; size_t pages } kind of struct?
<gog>
hi
<bl4ckb0ne>
hi gog
<osdever>
gog: Hello
<gog>
i call mine struct memory_range
<osdever>
Does anyone know how to FORCE x86_64-elf-gcc to build a shared library? The dirty bastard is creating static executables even when I say "-shared"
<bl4ckb0ne>
efi uses memory_descriptor but its long
<gog>
you could call it memrage or addr_range
<gog>
or anything
<gog>
there are no rules
<gorgonical>
do a lewis carroll and invent wholly new, nonsense words
<gog>
osdever: you'll need to invoke ld and do some Things
<osdever>
gog: Thank you, I had feeling x86_64-elf-gcc filthily removes `-shared` from its invocation when invoking ld for some reason. I just confirming it with `-v` and I can make a shared library with your command
<gog>
yeah it's because it's a bare target
<gog>
and it doesn't have a spec file to make a shared library
<gog>
you can nudge it to do the right thing
<gog>
just takes a little more work
Hammdist has quit [Quit: Client closed]
<bl4ckb0ne>
uwu naming is hard
<gorgonical>
bl4ckb0ne: an idea is to give all the important kernel structs ridiculous, old-timey names
<gorgonical>
"the kernel has to allocate an archibald every time this happens"
<osdever>
I want to manufacture my own toolchain but I fear if libgcc depends on hosted clib when built like that. My kernel is architected like the way of AmigaOS, with shared libraries essential... Until now I use host x86_64-linux toolchain which make a shared library, no problem
<bl4ckb0ne>
memory region!
<bl4ckb0ne>
at least thats what the uefi spec calls them
<gog>
uwu
<osdever>
I call it "Region"
<bl4ckb0ne>
your a region
<gog>
i'm gog
<bl4ckb0ne>
hi gog
<gorgonical>
you're very o-region-al
<gog>
huehue
<osdever>
bl4ckb0ne: This is the word on AmigaOS for continous physical memory spaces. "Region"
<osdever>
You can see if you look in the ExecBase documentation, that's how they call its word, but you discovery them with structures called MemHeaders
<osdever>
Sorry I need to go now. Thanks to God answering my question.
<osdever>
* Gog
osdever has quit [Quit: Goodbye]
<gog>
byeee
Burgundy has joined #osdev
<heat>
the more i think about that frankenkernel the more questions i have
<heat>
did he just crib my kernel? is that all? i was using it as a reference anyway
<heat>
he*
<zid>
whose?
<heat>
no way he has a custom kernel with random code
<heat>
<Hammdist> well I guess I copied a lot of existing MIT/BSD code from other kernels and I'm trying now to put together enough of a kernel to run go programs
<zid>
is that the same guy as a couple of months ago
<zid>
who upset gog
<heat>
taking random code from many kernels and frankensteining that shit together has to be more effort than actually writing it
<heat>
no, i dont think so
<ChavGPT>
which is why heat takes from just one kernel
<ChavGPT>
innit
<heat>
amen bruva
<heat>
don't tell anyone else i steal from illumos
<netbsduser`>
i have pilfered too many ideas from illumos
<ChavGPT>
why not contribute to illumos
<netbsduser`>
i have done
<heat>
why would you ever steal from illumos
<heat>
thats like stealing from any BSD
<heat>
you're objectively worse off
<netbsduser`>
illumos has a purer and more elegant vfs
<moon-child>
I only use illumos's memcpy
<moon-child>
best memcpy ever
<heat>
"purer"
<heat>
linux has a working and faster vfs
<heat>
what now
<heat>
purity means jack
<netbsduser`>
bsd vfs uses the lock vnode op for actual synchronisation instead of just for file locking, it has a convoluted lifecycle, and an incomplete integration of the vfs in general (this is why the file ops struct exists)
<heat>
thats why freebsd pmap is crap
<heat>
purity and elegance!! but growing regions downwards is too hard :(
<zid>
purity was made up by the patriarchy to make sure they weren't being cucked
<zid>
true fact.
<heat>
sorry, freebsd and netbsd and openbsd and dflybsd pmap
<heat>
none of their designs ever fixed that
<netbsduser`>
i always suspected freebsd had a decent pmap
<heat>
IIRC either netbsd or openbsd didn't even merge regions
<heat>
mmap(addr) and mmap(addr + pagesz) just had two separate mappings
<netbsduser`>
they have transparent huge pages and even large pages support, absent from netbsd
<mcrod>
parsing sucks
<mcrod>
FUCK
<mcrod>
FUCK!!!
<ChavGPT>
only freebsd has huge pages
<ChavGPT>
while bsd vfs is well known to be a clusterfuck
<heat>
they store data redundantly and focus on nice beautiful data structures
<ChavGPT>
i don't know illumos to be visibly better
<heat>
why does private memory have fucking radix trees?
<netbsduser`>
now freebsd does have a weakness in that their anonymous memory mechanism still uses the original shadow object chaining technique of mach, which is more hideous than netbsd's reference-counting technique
<mcrod>
why is your name heat
<heat>
stole it off of the miami heat
<heat>
literally
<ChavGPT>
? :d
<heat>
sue me floridians
<heat>
i don't even want to go to florida
<ChavGPT>
i should nickname myself vice then
<zid>
I assumed you took it from the oestrus cycle of rabbits
<heat>
netbsduser`, it's a huge weakness and that code is a huge clusterfuck
<netbsduser`>
heat: you may scoff at it now, but when you want to efficiently port to a machine which deals in inverted page tables, you will learn to love the arch-independent representation of address spaces
<heat>
you know how I'd do it?
<heat>
radix-like page tables
<zid>
I'd do it radish-like
<heat>
linux is very portable and has none of that pmap crap
<netbsduser`>
that's what's done on netbsd/alpha for the software-refilled TLBs
<heat>
and most importantly, it's designed AROUND NORMAL FUCKING SYSTEMS
<heat>
actually usable crap
<heat>
x86, arm, riscv all use the same page table scheme
nvmd has joined #osdev
<zid>
namely, number goes in, number goes out WITH FLAGS
<zid>
you can't explain that
<netbsduser`>
if you hit a seal in the face every day for 20 years, you may turn it into a rather fetching hat
<moon-child>
I'm still sad power got rid of their hash table
<heat>
why would you make everyone in the normal world bear your ✨beautiful design✨
<heat>
bear? bare?
<heat>
something
<heat>
you get what i mean
<moon-child>
bear
<zid>
bare is naked, the rest are shared
<zid>
bear/bear/bear/bear
<heat>
✨beautiful design✨ that is ✨pessimal✨
<netbsduser`>
linux has enjoyed those 20 years and that's what its advantage today owes more to i think
<heat>
current linux just has better designs than current BSD
<heat>
and they fit the real world a lot better
<moon-child>
government is forcing me to wear long sleeve shirts
<moon-child>
this is bullshit
<moon-child>
I want the right to have and bare arms
<netbsduser`>
it was only around 2001 or so that linux had to invite matt dillon in to consult on their slow memory manager
<heat>
in the vm example, windows takes a page off the same book and also deals directly with page tables and PTEs
<heat>
good news, it's 2023
<netbsduser`>
i forgot the details, i think linux was iterating over every single page table in the system to look for mappings of a page when it was decided to page it out
<netbsduser`>
windows is radically different, their memory manager has no resemblance to anything ever powering a unix
<zid>
windows xp was so aggressively swappy I used to have to disable it
<zid>
because on a mech drive it meant the system would just pause for 100ms every 2 seconds under load
<netbsduser`>
in the book about it they say it was designed so that a single spinlock would protect the majority of it and every operation carried out under that had to be O(1)
orccoin has joined #osdev
<heat>
probably scales fine for their workloads
<heat>
despite ChavGPT rolling in his grave or whatever they use to sleep in poland
<gog>
no the guy that upset me was jafarlihi
<netbsduser`>
they split up that lock some time ago but the new locking system isn't described in the windows internals books as far as i've read of them
<zid>
heat: coffins
<heat>
until late last year linux would have exclusive locks around the whole vm except when resolving page faults
<zid>
ah yea gog
<zid>
polish people sleep in coffins
<netbsduser`>
heat: no way
<gog>
i'm gonna ask my coworkers tomorrow
<gog>
my polish coworkers
<gog>
if they sleep in coffins
<gog>
and tell them you said
<zid>
heat check ur DMs babe
<heat>
netbsduser`, yes way? it's the obvious alternative
<netbsduser`>
i thought they had very small locks now in linux
<heat>
i mean, its a lock per address space
<heat>
but it's comparively big since mmap, mprotect, munmap serialized the shit out of everything
<netbsduser`>
oh, that's more understandable
<heat>
page faults ran concurrently with the mmap read lock held
<netbsduser`>
i thought you meant global
<heat>
i don't mean global global
<heat>
that's hilariously bad
<heat>
just process-global, which still sucks
<netbsduser`>
that's why windows had to have its operations be O(1)
heat has quit [Remote host closed the connection]
heat has joined #osdev
<netbsduser`>
they had per-process mutexes (the working set mutex) but things like PTE changes, page moves queue, were under the global spinlock
<heat>
yeah that sucks
<heat>
fwiw afaik all other systems still have big rw locks around the address space
<heat>
except LE LINUX
<heat>
the dirty very ungood linux with its amateurish code
<netbsduser`>
what's interesting is that we know Richard Rashid and other Mach people were big wheels around the creation of NT, and mach had much finer locking
<zid>
Time is time
<zid>
and windows wasn't really a big iron server platform
<heat>
yeah
<zid>
I don't see why you'd aim for more than "it doesn't choke up if 30 things are running"
<zid>
if you're on the original NT dev team
<heat>
if it works fine for chrome and word and call of duty you're alright
<netbsduser`>
tru64 at least had much finer grained locking around address spaces (locks taken out against ranges in it), i read about it in the Design of the OSF/1 Operating System
<heat>
turns out user programs are conservative when it comes to mmap and munmap so that's not a biggie anyway
<heat>
netbsduser`, range locking isn't necessarily a win btw
<zid>
Yea I was going to touch on something similar
<zid>
you get to pick *where* you put the locks, but putting them on certain layers is good for *certain* operations only
<netbsduser`>
heat: thanks, this looks like an entertaining article
<heat>
there's also the radix vm work
<heat>
i read the paper and found it absolute bollocks
<gog>
meow
<heat>
"yeah see, our thing is faster, it just needs 40x the memory"
<heat>
meow meow gog meow
<gog>
meow mrrp prr meow
<heat>
aktushally
<heat>
i am wondering now if you could keep a traditional rb tree behind a radix tree cache and have good results from that
<not_not>
so should i write a compiler first or a nifty bootloader?
<heat>
certainly lockless lookups would be nice
simpl_e has joined #osdev
<zid>
never write bootloaders, so, compiler
<heat>
netbsduser`, anyway, linux did not go that route, they switched the rb tree with a maple tree (pretty much a btree with RCU helping it out) and added some bespoke vma locking i personally find horrendous
<heat>
but the maple tree is nice
<heat>
binary trees are not the bee's knees
<heat>
*at all*
<not_not>
why never write bootloaders tho?
<zid>
I mean, if your idea of fun is chasing bugs in bios roms from chinese motherboard cloners from the 80s
<zid>
feel free I guess
<gog>
non binary trees
<not_not>
good point
<zid>
we thankfully have a small archive of fixups for broken bioses like that called 'the grub project'
<not_not>
ye guess you can just use grub to boot into your kernel
<heat>
gog, hey that's a btree!
<netbsduser`>
i heard about the maple trees somewhere
<netbsduser`>
haven't looked at them yet
<not_not>
i love trees
<gog>
you could just write weird experiments
<gog>
like i do
<gog>
and never really focus on anything
<not_not>
im writing this weird experiment wich tries to make a computer do "not this, not this, not this ..... not not"
<not_not>
and achive self awareness
geros has joined #osdev
<gorgonical>
my computer does this thing where when i write a new img to my sd card it occasionally just wont write it
<gorgonical>
and then it will fully stop and i don't know why. cat whatever.img > /dev/sdf2 and it just goes "yeah done instantly boss no worries"
<gorgonical>
liar
<nikolar>
sync?
<gorgonical>
it does nothing
<gorgonical>
unless you know of a supersync command or something
<heat>
your sd card sounds dodgy
<nikolar>
yeah i am not aware of anything like that
<heat>
if sync isn't writing it out
<gorgonical>
it's probably the writer
<gorgonical>
multiple known good cards do it
<gorgonical>
though it is an anker sd card reader
eddof13 has joined #osdev
eddof13 has quit [Client Quit]
geros has quit [Quit: .]
<immibis>
i have a microsd card which accepts writes (in multiple readers) and doesn't actually write. never buying a sandisk card again
<immibis>
this occurred after only about a week of actual usage
<gorgonical>
fancy that, this one's a sandisk too
<gorgonical>
the one that actually works is a samsung brand
<immibis>
maybe in contrived scenarios a high-capacity sandisk card could be a good form of WORM media :)
eddof13 has joined #osdev
<immibis>
if you want to take 400gb of media to watch on vacation offline... it sure beats a stack of blu-rays
nvmd has quit [Quit: WeeChat 3.8]
<gorgonical>
christ i finally got interkernel ipis on real hardware
<geist>
yeah that's really weird it's not writing
<gorgonical>
it was so easy in qemu
<geist>
it may cache behind for sure, though generally that's not the case with a raw device write on linux. i think it can cache but it usually syncs on close, i think
<gorgonical>
geist: and fwiw i don't see any unusual messages about hw behavior in dmesg
<gog>
meow
<heat>
i don't believe it syncs on close
<geist>
yah that is highly strange
<heat>
AFAIK it doesn't sync
<gog>
hi
<gorgonical>
my gf is at a work event and i'm trying to convince myself to not just eat baguette and brie for dinner
<heat>
(but i've never looked at the file_ops for those devs)
<heat>
geist, also it most definitely caches
<geist>
possibly, i thought i've seen a sync-on-close like behavior, but maybe not
<heat>
let me checkkkk
<geist>
but either way you should also eject the card properly before pulling it out, which will sync it anyway
<geist>
mostly out of laziness i tend to use the Disk utility on ubuntu/mint linux with the 'restore from image' ui, which definitely puts a sync in at the end
<geist>
or maybe even uses O_DIRECT
<heat>
yeah
<heat>
i usually use dd and the caching is visible there
<gorgonical>
even dd does
<heat>
if you dd something without oflag=sync(or is it direct? cant remember) the syncing up of the page cache is visible on lower-end storage like sd cards
<gorgonical>
I know for a fact this pos doesn't write 700MB/s
<heat>
yeah what you usually see is blistering speeds, then if the write is large enough it hangs for page writeback
<geist>
over time it tends to collapse to the speed of the device, if you send it large enough data
<heat>
(then it keeps writing the rest)
<geist>
right
<gorgonical>
additionally I do *not* see the led on the reader blink
<gorgonical>
which it normally does when writing
<geist>
hopefylly you're not just blissfully overwriting something else :)
<gorgonical>
i have so much fear i compulsively check lsblk right before every time
<heat>
once i accidentally dd'd to a device that wasn't there
<heat>
so it just created a big tmpfs file in /dev lol
<gorgonical>
now the samsung sd card is doing it too
<gorgonical>
and the fixes on se are alllll over the place
orccoin has quit [Ping timeout: 240 seconds]
<ChavGPT>
heat: mofer not only linux still has a big rw lock around the address space
<ChavGPT>
heat: but the first fault in the mmapped area reada locks it
<ChavGPT>
linukkkz not scale
<heat>
lunikkkkkkz is dropping the lock slowly calm the fuck down big fella
<heat>
something something technical debt
<heat>
even the current wave of per-vma refactoring had a buncha bugs
<netbsduser`>
there was a big scandal recently around linux mm locking which i forgot the details of
<heat>
there was a bug and they found it and they fixed it
<ChavGPT>
it all works now
<heat>
sadly it was already out in a stable release
<ChavGPT>
just DOES NOT SCALE
<netbsduser`>
it caused a major stink
<ChavGPT>
kind of funny how magic testing failed to use it on a desktop innit
<heat>
what
<ChavGPT>
look mate, if you want i can show you a zfs data corruption bug by ahrens
<netbsduser`>
testing what?
<netbsduser`>
zfs is the last word in file systems
<ChavGPT>
it would cause a stink if anybody was using it
<ChavGPT>
heat: the bug was manifesting itself with crashing firefox
<ChavGPT>
heat: or some other wtfbrowser
<ChavGPT>
unless you mean a different bug
<ChavGPT>
now that i mention it there was also stakc locking
<heat>
no, the first bug report was a suse CI build of golang
<ChavGPT>
and that bug was in stable?
<heat>
yes
<ChavGPT>
solid
<ChavGPT>
lvm may suspend any logical volume anytime. If lvm suspend races with
<ChavGPT>
unmount, it may be possible that the kernel writes to the filesystem after