<bslsk05>
lore.kernel.org: [PATCH 0/5] ioctl()-based API to query VMAs from /proc/<pid>/maps
<mjg>
sysctl for the poor
<mjg>
cc heat
<heat>
ew
<heat>
an interface that can query an address makes sense though
<Ermine>
Probably better than pasting
<Ermine>
s/pasting/parsing/
<mjg>
what are you even talking about heat
<mjg>
plaintext files all the way
<mjg>
or am i misremembering your opposition to sysctl
<heat>
i think you are
<mjg>
what is your position then
<heat>
i'm not intensely opposed to sysctl, but i'm not intensely opposed to /proc either
<mjg>
:S
<mjg>
you are a bad person
<heat>
centrist moment
<Ermine>
sys sys sys
<heat>
i am opposed however to kern_sysctl.c
<heat>
BUNCHA CRAP CODE
<heat>
in any case i don't really like the way BSD did sysctl, linux sysctl (read: names are strings and not random weird ids) is more natural
<mjg>
wtf mon
<mjg>
kern_sysctl.c is great
<mjg>
i mean, it's not like bunch of geezers wrote bunch of shit on there, like i used to claim
<mjg>
clearly, it was great stuff when it was created
<mjg>
if it was not, they would not write it, ergo it is
<mjg>
self-fucking-evident
<mjg>
aren't you one of the twats with the knee jerk defense of old code as soon as it gets criticized
<heat>
woah what's with the hostility
<mjg>
maybe i'm agitated
<mjg>
like you were yesterday
<heat>
it happens
<mjg>
ye andrea rejected me too man
<heat>
did alexandra botez lose
<heat>
is that why you're sad
<mjg>
oh the other one
<mjg>
yes, that's why
<mjg>
even so, the question stands
<mjg>
don't you defend al lthe stuff by default
<mjg>
with the catch-all "was good at the time bro"
gog has quit [Ping timeout: 256 seconds]
<Ermine>
mon
<heat>
yep
<Ermine>
calm down please
<heat>
hi Ermine how r u
<Ermine>
my performance is near zero these days
<heat>
its okay
<heat>
you can be pessimal
cow321 has quit [Remote host closed the connection]
<mjg>
OH
<mjg>
bad performance is called poorformance
<heat>
actually alexandra won her game
<heat>
are you a hater
<Ermine>
It's unsuitable time to be pessimal
<mjg>
i'm a non-give-a-fuck-er
<mjg>
not
<mjg>
i am hatin on that gotham fella
cow321 has joined #osdev
chiselfuse has quit [Ping timeout: 260 seconds]
chiselfuse has joined #osdev
chiselfuse has quit [Remote host closed the connection]
chiselfuse has joined #osdev
agent314 has quit [Ping timeout: 255 seconds]
agent314 has joined #osdev
m3a has quit [Ping timeout: 245 seconds]
edr has quit [Quit: Leaving]
voidah has joined #osdev
<geist>
heat: hmm, on qemu? you mean the guest initiates something that turns trim on?
<geist>
or do you generally just mean discard=true on the command line for the disk thing?
<geist>
the latter i know about. in qcow2 it also frees up the block in the translation table, so it’s good for it to recycle blocks
<heat>
discard=true
<heat>
the fun bit is that it can do it on raw block devices or raw files
<heat>
whether it's desirable probably heavily depends on the workload and setup
<geist>
yep. it’s pretty neat. i tend to mount of qcows over nfs where it can’t punch a hole, sadly, *but* with qcow2 it at least recycles logical blocks in the backing file first before extending it
<geist>
sothe qcow file itself tends to remain over time at the largest size it was ever active with at any point
<geist>
and no more
<geist>
also if you point qemu at lvm sparse partitions it’ll take advantage of it too, though the granularity in that case is pretty big, like 1MB
voidah has quit [Ping timeout: 245 seconds]
voidah has joined #osdev
goliath has quit [Quit: SIGSEGV]
voidah has quit [Ping timeout: 268 seconds]
srjek has quit [Ping timeout: 252 seconds]
<mjg>
ey mofos
<mjg>
here are some funny lockstats from freebsd building itself for all archs 'n shit
<mjg>
5572289829 (sleep mutex:pipe mutex)
<mjg>
1174668890 (rw:pmap pv list)
<mjg>
61155502 (spin mutex:sleepq chain)
<mjg>
14645564 (sleep mutex:vm reserv domain)
<mjg>
13797468 (sleep mutex:pmap)
<mjg>
top of the fucking profile, 5x the second lock, with that one being almost 2x of the 3rd, with that one being way more than the rest
<mjg>
... is the fucking pipe mutex stemming from make polling on the shared token pipe
<geist>
okay.
<geist>
excuse me if i'm not completelyf ucking losing my mind
<mjg>
which as i tried to explain is a massive problem at scale
<mjg>
and which you people claimed it can't be
<mjg>
(here hte scale is -j 104)
<geist>
ah
<heat>
hey bud
<heat>
i thought you didn't do freebsd anymore
<heat>
is this stockholm syndrome?
<geist>
i guess they go to the thing that gives them maximum outrage
<mjg>
if memory serves you and kazinsal were geezering the problem has to be i/o
<mjg>
heat: dayjob has to support this shite os for some years to come, so on that note i'm kind of involved
<mjg>
i only tested now because some pessimizations landed and i was curious how things go
<mjg>
vfs remains way out of sight
<mjg>
and as i was saying, ninja avoids the problem altogether and has my seal of approval
<childlikempress>
why did they land pessimisations
<mjg>
cause they are geezers
<geist>
what do geezers have to do with it?
<mjg>
contrary to popular belief most people who write any c neither care about perf nor understand it
<childlikempress>
popular among whom exactly
<heat>
itz 5am mjg
<geist>
mjg needs to sleep
<mjg>
indeed i'm about to turn in
<mjg>
had to bull off an allnighter few days back
<mjg>
and it is hard to reset for me 8/
<kazinsal>
I’m also not a geezer, just someone who’s been here too long
<mjg>
there is a group for old people who used to program, including writing unix kernels
<mjg>
and who asserted their way about everything perf-related, as opposed to checking what happens instead
<mjg>
and which, if still active, keep pulling off that shit
<mjg>
i refer to the group as geezers
<mjg>
also note justifying one's statement what the problem is with Deep Conviction, as opposed to profiler data, is still pretty common amongst people of all ages
<mjg>
and in particular you two kept pulling that shit when i was complaining about make's pipe
<geist>
who is you two here?
<mjg>
you and kazinsal
<geist>
me? what did i have to do with it?
<mjg>
you did not claim it's not make pipe, it's i/o?
gbowne1 has quit [Remote host closed the connection]
<mjg>
i'm pretty sure you did, also dunking on ninja
<mjg>
i concede i may be misremembering the culprits
<geist>
me? probably not. but there was some vague discussion about make pipes, of which i drive by sniped
<geist>
but ninja is rad
<heat>
how do you remember these little discussions months ago at 5am
<geist>
but i vaguely remember some blabbing about how terribad the pipe is and i was like <shrug>
<geist>
like probably is, but it gets the job done
<mjg>
heat: you missed all the discussions i don't remember, kind of invalidating what you are trying to imply here
<geist>
fascingating that we managed to nerd snipe you months ago
<mjg>
nerd sniping? literally never happens to anyone
<geist>
heh
<geist>
0 days since the last nerd snipe here
<mjg>
(:
<geist>
i probably said something like 'oh it's not great but it works pretty well' in that the whole make pipe thing is a simple functional way to do the job stuff
<geist>
and yeah probably dopesn't scale. and you just found out how!
<mjg>
i already knew at the time, but did not have handy data
m3a has joined #osdev
<mjg>
well i know for years now, it annoys me any time i try to profile build
<mjg>
's liek a self-induced problem getting in the way of looking at bottlenecks from legitimate issues
<geist>
does linux/etc handle everything piling on the single pipe better?
<mjg>
no
<mjg>
also note this is poll, not epoll/kqueue
<mjg>
that is to say you get registered/unregistered on every call
<mjg>
and both gnu make and bsd make do this, but bsd make does it more
<mjg>
it's definitely not something which i would guess to be a problem
<mjg>
but this is where checking what happens instead of speculating comes in
<mjg>
eventfd would handle this drastically better
<geist>
sure, and this is why open source works. if you have enough monkeys (mjgs) to go track down every tiny detail, then you have infinity hours of work to drill into it
<heat>
i implemented primitive readahead but it seems to have made no difference
<heat>
this is so sad
<geist>
whereas any given person only has tmie to deal with an extremely finite amount of stuff
<heat>
geist play despacito
<mjg>
geist: i would not say it works
<geist>
heat: the song?
<heat>
yes
<mjg>
geist: stupid shit remains unfixed for years despite several people knowing about it
<heat>
you are this channel's alexa
nikolapdp has quit [*.net *.split]
clever has quit [*.net *.split]
kazinsal has quit [*.net *.split]
<geist>
is this portuguese?
<heat>
no
<heat>
it's spanish
<mjg>
does despacito mean PESSIMAL in spanish?
<geist>
sound spanish to me, but i havne't heard enough portuguese to spot it
<geist>
something little
<mjg>
portugese is spanish for the illiterate
<geist>
and i assume brazillian porguese sounds different
<geist>
that is not, though i do kinda wonder what brian is up to nowadays
<heat>
mjg, i know
<heat>
joke
<mjg>
i am sayin' bad
<mjg>
geist: while i don't know any brian in person, i can vouch for not being in contact with anyone i made friends with till 27 or so
<mjg>
admittedly i don't wonder what they are up to though
<mjg>
i did the typical thing of becoming great friends with coworkers and job hopping, mostly losing contact with the previus crew
<mjg>
previous
<heat>
is uh
<geist>
yah back when i was in silicon valley everyone was around and so you'd just bump into them again
<geist>
but i moved to PNW 8 years ago and the friend group split
<heat>
is qemu emulated block io always synchronous?
<geist>
heat: there's the whole cache stuff
<geist>
and the io thread bits and aio/io_uring optins and whatnot
<geist>
i think by default though it's synchronous?
<geist>
i was just reading about that the other day. iof you want performance yuo generally switch to iothreads or whatnot
<geist>
i dont know the precise syntax, but there's a bunch of blobs about it online
<geist>
when i was playing with proxmox it's all brought out into a bunch of checkboxes and i think the usual strategy is to use iothreads + io_uring
<heat>
yeah i wouldn't be surprised if the readahead sucks because it's all synchronous
<geist>
i think by defult if you dont do anything its synchronous + linux caching, so whatever it gets yuo that works
Arthuria has quit [Ping timeout: 260 seconds]
<heat>
okay with aio=native cache=none i can see a big difference
<heat>
i didnt try threads
<geist>
yeah there was some blog i was looking at the other day running some benchmarks with the aio settings (native vs io_uring) and iothreads and the combinations thereof
<geist>
iirc any one of them is the big win, and then more than one at a time is a bit more of a nuanced thing
<heat>
reaching 130MB/s read (out of a filesystem, with page cache in the middle) out of 500MB/s (SATA) isn't *awful*
<heat>
without RA it slows down to a blistering 7MB/s
<geist>
TIL about `fsutil` on windows
<kazinsal>
`fsutil` is pretty handy yeah
<kazinsal>
exposes all the funky underlying NTFS stuff that the win32 API doesn't usually let you tinker with
<geist>
yeah
<geist>
also simply lets you make a file of a particular length, which is what i needed
<geist>
since no dd, etc
<kof673>
there were various dd "ports"...take the "windows device names" \\something_or_other
<kof673>
(i.e. without cygwin, mingw, etc.)
<kof673>
i'll vageuly side with gei st. > 's liek a self-induced problem getting in the way of looking at bottlenecks from legitimate issues if it is just about money this also can happen, if it is just about code being available, this also can happen
<kof673>
i don't see it as a 'open source' thing or not anyways
agent314 has quit [Ping timeout: 256 seconds]
* kof673
points at hyrum's law: With a sufficient number of users of an API, it does not matter what you promise in the contract; all observable behaviors of your system will be depended on by somebody
heat has quit [Ping timeout: 240 seconds]
<azonenberg>
Ok hmmmm
<azonenberg>
#include "/usr/include/linux/elf.h"
<azonenberg>
I don't like this
<azonenberg>
But i also am obviously not going to put my host system /usr/include in my search path
<azonenberg>
oh actually, it doesnt even work because it wants to include <linux/types.h>
<azonenberg>
So do i redeclare all of the structures myself? or vendor the linux elf.h?
<geist>
probably vendor the elf.h. or see if you can find a BSD version of it
<geist>
the elf types are pretty much declared in the spec, so i dont think there's much differnce
<geist>
but saves you the trouble of typing it in
<azonenberg>
Yeah I ended up deciding to just type it in since i'm only implementing a small subset of the full elf
<azonenberg>
basically all i need is to be able to read program headers from a statically linked file
<azonenberg>
in order to flash it
<geist>
ah yeah
xenos1984 has quit [Read error: Connection reset by peer]
<azonenberg>
i think you were around before when i was talking about my awesome yet totally unhinged firmware update flow for this platform lol
<azonenberg>
sftp an elf to the board's IP and it burns the code and data to flash
<azonenberg>
there will just be a bunch of virtual device files
xenos1984 has joined #osdev
plarke has joined #osdev
raykv423 has joined #osdev
zxrom has joined #osdev
GreaseMonkey has quit [Remote host closed the connection]
ThinkT510 has quit [Quit: WeeChat 4.2.2]
ThinkT510 has joined #osdev
plarke has left #osdev [Leaving]
plarke has joined #osdev
duckworld has quit [Ping timeout: 244 seconds]
GreaseMonkey has joined #osdev
navi has joined #osdev
raykv423 has quit [Quit: Connection closed for inactivity]
<azonenberg>
i still have to add the bootloader interface code to make "DFU start", "DFU complete", and "OnWriteData" reboot the chip in bootloader mode, reboot in normal mode, and push write data to flash respectively
<azonenberg>
but all of the SFTP code and ELF parsing needed to know what bytes of data get written to which flash addresses is done
<azonenberg>
So i'm very close to SFTP-based OTA reflashing :D
netbsduser has joined #osdev
duckworld has joined #osdev
xenos1984 has quit [Quit: Leaving.]
gildasio has quit [Remote host closed the connection]
gildasio has joined #osdev
<Ermine>
ddevault: goodspeed
<mjg>
so i asked how to do something trivial in rust
<mjg>
was told to create a method to hide the actual implementation from other code
<mjg>
and unsafe { }
<mjg>
:d
<mjg>
g-fucken-g
<nikolar>
Typical rust experience
<mjg>
indeed
<nikolar>
RUST IS SUPER SAFE, but also whenever there's a slightest sign of complexity just use unsafe and hide it
<ddevault>
got waitpid done
<ddevault>
which is one less excuse not to do signals yet
leg7 has joined #osdev
<mjg>
nikolar: tokio internals have a doubly linked list implemented with a tons of unsafe in it, ofc
<mjg>
nikolar: commentary says there is a bunch of conditions all consumers must meet for this to work
<mjg>
i'm confident this means there is literally 0 chance tokio can just crash
<mjg>
as in segfault
<mjg>
when was the last time you had seen a bug in a lib
<zid`>
I can't wait for like, 20 years, when rust is normalized/standard, and we get loads of CVEs anyway because yea, people just do the cmplex parts in unsafe blocks
<azonenberg>
(this routine gets the outer IPv4 header given a pointer to the UDP header)
<nikolar>
Safety!
<zid`>
top tip: unalign your ethernet packet buffers
<zid`>
then you get aligned payload data for ip!
<kof673>
give nuclear increments time, it is pretty much guaranteed, there is a long history: > MOLECULE, n. The ultimate, indivisible unit of matter. It is distinguished from the corpuscle, also the ultimate, indivisible unit of matter, by a closer resemblance to the atom, also the ultimate, indivisible unit of matter. [...] The ion differs from the molecule, the corpuscle and the atom in that it is an ion. see also monad
<bslsk05>
rust-lang.github.io: 3151-scoped-threads - The Rust RFC Book
<mjg>
working around shotcommings in the lang by providing a way for the clueless to keep spawning and kill threads continuously
<mjg>
killing*
xenos1984 has joined #osdev
<heat>
* xor_unlock_is_negative_byte - XOR a single byte in memory and test if
<heat>
* it is negative, for unlock.
randm has quit [Remote host closed the connection]
randm has joined #osdev
npc has quit [Remote host closed the connection]
nyah has joined #osdev
zxrom_ has joined #osdev
zxrom has quit [Ping timeout: 268 seconds]
<nikolar>
netbsduser: I mean rcu like in linux
zxrom_ is now known as zxrom
<geist>
heat: rad
srjek has joined #osdev
<geist>
the aio stuff that is
agent3142 has joined #osdev
<heat>
yeah
<heat>
it makes a lot of sense to disable the caching and turn the block device into a more block-devicy thingy
<heat>
otherwise i have 3 layers of caching between my userspace and the backing disk space
<gog>
when in doubt, cache
<heat>
WEBDEV!!
<gog>
that's right
<netbsduser>
unbelievable
<netbsduser>
i had been working on my kernel almost exclusively on m68k the past 9 months or so, including all new virtio drivers
<netbsduser>
i tried along the way to make everything appropriately endianed and to have a division of labour between the virtio specific device driver classes and a virtio transport nub, but i only implemented such for virtio-mmio (only thing available on m68k)
Matt|home has quit [Quit: Leaving]
<netbsduser>
today i got around to implementing the nub for virtio-pci and was surprised to see it all just worked, as did the fat driver, both only tested on m68k. very satisfying
<gog>
nice
<gog>
i should get to work on things again but i have no desire to rn
<netbsduser>
literally zero modification to the portable code, i can't believe i got that right first time
<heat>
i'm fighting races
<netbsduser>
what sort of races?
<netbsduser>
nikolar: where would refcnting come into it?
<heat>
the data ones
<netbsduser>
what data is so desirable that everyone is racing to it?
<heat>
i added readahead to my kernel last night
<heat>
so thats why
<heat>
some block_buf/page state is getting bonked
<geist>
netbsduser: yah that's a project i need to do for LK: make the virtio and pci stuff endian neutral
<geist>
for precisely the same reason. the m68k virt qemu machine
<heat>
god gets sad when you do big endian
<netbsduser>
geist: i think the spec is mostly unambiguous except for writing address of the queue rings - that one seems to accept (at least on qemu) whatever the native representation of a physical address is
<netbsduser>
that's the only thing i remember *not* being little-endian
<geist>
yeah i just hadn't bothered to put in the swaps at the right place
<bslsk05>
doc.rust-lang.org: scope in std::thread - Rust
<heat>
just good ol dubious locking
<nikolar>
netbsduser: counting the active readers
zetef has joined #osdev
<nikolar>
mjg when was the RFC published
<netbsduser>
nikolar: this is where i think confusion comes
<netbsduser>
linux rcu is a mechanism that makes read-copy-update approach to data structures possible through letting action be deferred
<nikolar>
Oh I know what it is
<netbsduser>
but also facilitates other things which aren't actually reading, copying, and updating at all
<nikolar>
I just want to know how to implement it efficiently
<nikolar>
I understand that it doesn't need to be strictly for data structure manipulation
<nikolar>
But it can't be the best way to just schedule the task on every core
<netbsduser>
the fundamental of it is a mechanism that lets you schedule work to be carried out after every core in the system has passed through at least one state that marks a point at which that core doesn't keep references to something you want to do something to
<netbsduser>
i.e. context switch
<netbsduser>
the original patent is now expired, i copied my implementation directly from its description
<heat>
nikolar, oh i didn't see your question
<nikolar>
Nah it's fine
<heat>
RCU as in linux uses QSBR
<netbsduser>
US5442758A i think
<nikolar>
No way you remembered that
<heat>
the point of quiescence being scheduling out (or being "schedulable")
<heat>
so, on a preemptible kernel:
<netbsduser>
i searched for "patent" in my codebase and found a reference to that
<nikolar>
Kek
<heat>
#define rcu_read_lock() preempt_disable()
<heat>
#define rcu_read_unlock() preempt_enable()
navi has quit [Read error: Connection reset by peer]
<heat>
the preemption counter being cpu-local
<nikolar>
And how do you synchronize_rcu()
<netbsduser>
nikolar: i allocate a semaphore on the stack, defer work with RCU to signal the semaphore, and wait for the semaphore
<netbsduser>
when every core passed a quiescent state the callback to signal the semaphore will be invoked
<bslsk05>
www.androidauthority.com: RISC-V support in Android just got a big setback - Android Authority
<Ermine>
It isn't clear whether they drop risc-v entirely or they just stop producing GKIs for risc-v
<heat>
they didn't drop rv
<geist>
yeah it's not as bad as the news articles say
<geist>
basically for this cycle they didn't want to yet support riscv on GKI
<geist>
it's all. but there was a lot of upset folks internally, me included, but it was mostly due to the lack of care of communication
<geist>
not that it actually implied
<Ermine>
none of them tried to provide a link to a PR in question
<geist>
basically the GKI team didn't want to yet have riscv set in stone, so they decided to roll it out for now for another android release cycle, whcih isn't unreasonable
<geist>
but this is why in general we have to be very careful about certain things we check in, because stuff like this gets picked up by news cycles and blown out of proportion all the time
<zid`>
how do you even build for riscv
<zid`>
like, throw a dart at a selection of extensions?
<geist>
no, that's part of what android was standardizing, which RV level it supports
<zid`>
so they infact, did precisely that? :P
<geist>
there's a thing called riscv profiles that a lot of folks are working on, to precisely standardize the level of support
<geist>
hmm? no. i mean you're being facetious but really trhere's a lot of work
<geist>
i can send you links if you actually care
<Ermine>
geist: are you involved with that?
<geist>
tangentially yes. i did the riscv fuchsia stuff, and a bunch of the fuchsia team is also helping out with android, etc
<clever>
Ermine: why are they removing things like that, and what about android is even arch specific?
<geist>
since we're also kinda riscv experts within google. especially the toolchain team
<geist>
basically fuchsia toolchain team is more or less driving the toolchain standardization across android/etc because we're all under the same org
<Ermine>
clever: the kernel and hal stuff probably
<geist>
thoughi haven't persionally contributed, a bunch of folks on the team and related are on a bunch of the riscv standardization committess
voidah has joined #osdev
<clever>
i thoght the only real android specific part was the binders and rpc, which are generic
voidah has quit [Remote host closed the connection]
<bslsk05>
github.com: riscv-profiles/profiles.adoc at main · riscv/riscv-profiles · GitHub
<geist>
rv23 is being defined in a separate file
<geist>
but the idea is if you have a RVA22 chip, you can standardize on the mandatory parts of RVA22, etc
<geist>
so android (and fuchsia) have stated we're requiring RVA22 + vector
voidah has joined #osdev
<Ermine>
So, the takeaway is that rv will not be officially supported in the next release of android
<geist>
i honestly dunno. GKI support i dont think is mandatory for android
<heat>
i mean, does it even matter?
theyneversleep has joined #osdev
<heat>
you don't have riscv phones
<geist>
but honestly i dunno, i dont work on that team and plkease dont put what i write here in a news article. i'm going out on somewhat of a limb by trying to give you more color here
<bslsk05>
github.com: riscv-profiles/profiles.adoc at main · riscv/riscv-profiles · GitHub
<heat>
i'm already writing the article
<Ermine>
heat: some vendors ship dev boards with android on them
<geist>
honestly aside fro the usual detaults, zba/zbb/zbs are really nice addiotions, especially zbb
<heat>
google ENGINEER goes out on a LIMB against RUSSIAN
<geist>
but AFAICT the main android build supports riscv now, at least on emulator
<heat>
love it
<geist>
which was a lot of work, toolchain, libc, build, etc. lots of foundational work
<heat>
i think GKI is required by android
<heat>
has been for a few version
<nortti>
required in what sense?
<geist>
it may be required, but may be required *per architecture*
<geist>
ie, arm may require it, but doesn't necessarily apply to x86 or mips. though i have no idea
<Ermine>
I guess it's required to use android trademark and probably to get access to google apps
<geist>
and 'required' may be for ... yeah exatly what Ermine says
<geist>
bnut again i have actually no idea. please dont treat what i say with android stuff as having any sort of authority
<nortti>
oh, ah, yeah that makes sense. was wondering since I have android 14 (through lineageos) on a phone that very much does not run GKI
<geist>
i think the idea though is GKI implies a compatibility going forward, so i suspect the GKI team wasn't ready to put a stake in the ground for RISCV yet
<Ermine>
they also have compatibility test suite
<heat>
ok apparently you may not use GKI *but* you're then restricted to 4.19
<heat>
which is being EOLd
voidah has quit [Remote host closed the connection]
voidah has joined #osdev
<heat>
where the rayce :(((
<Ermine>
?
<heat>
i have races and i cant see whats wrong
<heat>
RUUUUUUUUST but unironically
<Ermine>
or kcsan?
<nortti>
what does tsan require for implementation?
<nikolapdp>
rust has races too
<Ermine>
oh
<Ermine>
oh no
<heat>
KCSAN can't see whats wrong either
<Ermine>
nortti: join onyx!
<heat>
nortti, tsan is annoying, basically needs 4x the memory or whatever, and it doesn't support lots of stuff
<heat>
i took linux's kcsan which basically sets up watchpoints randomly
<nortti>
like actual backing memory, and not just address space?
<heat>
actual backing memory in the kernel, address space in userspace
<nortti>
yeah, that does sound annoying
<heat>
but tsan will blow up if you try a memory fence
<nortti>
is that because that goes outside the C++11 memory model?
<heat>
no
<nikolapdp>
heat if it's putting watchpoints randomly, you might just have to run it for longer
<heat>
it's just very hard to support memory fences using vector clocks
<Griwes>
fences are one of the funkier thing to exist
<Griwes>
s*
<Ermine>
what does git bisect show?
<heat>
Ermine, git bisect shows HEAD ;)
<Ermine>
is it on github?
<heat>
no
Gooberpatrol66 has quit [Ping timeout: 260 seconds]
zxrom has quit [Quit: Leaving]
carbonfiber has quit [Quit: Connection closed for inactivity]
Matt|home has joined #osdev
skipwich has quit [Quit: DISCONNECT]
Gooberpatrol66 has joined #osdev
wantyapps_ is now known as wantyapps
<heat>
im so fucking stupid
<heat>
INSANE SHIT
<nikolapdp>
yes, and?
<heat>
me yesterday: "oh, i can accidentally overwrite and leak page cache pages because i never re-check when inserting"
<heat>
yeaaaaaaaaaaaah
<nikolapdp>
lol really
<heat>
this is a weird scheme where the readahead page pre-allocates pages and *locks* them, and they're stable references because you can't truncate without locking the page
<heat>
except... if your code is so borked it overwrites them anyway
<heat>
ext2_readahead could get unlocked pages even though i was definitely locking them
<zid`>
I love an invariant that's an invariant only in your head
<zid`>
and not in the code
<zid`>
because eventually you will derp
<nikolapdp>
:P
<zid`>
That's what I want from a language
<zid`>
the ability to express to it, invariants
<zid`>
rust is sadly, very subtractive, rather than additive, which makes it a pain in the arse
<nikolapdp>
wo
<nikolapdp>
womp womp
<nikolapdp>
you get c, cpp, or rust
<nikolapdp>
pick one
<zid`>
rather than starting with "everything is UB and meaningless", and then you add annotations like "int" and "unsigned" and stuff
<heat>
can i kill myself?
<heat>
it sounds like a better option
<zid`>
you start with "Everything is illegal, convince the borrow checker it isn't"
<zid`>
which is paain
<nikolapdp>
heat just start farming
<zid`>
nothing grows in porutgal
<zid`>
it's basically northern africa
<nikolapdp>
wouldn't it make more sense for it to be westerb spain
<zid`>
they both are, but spain is northern africa * weight1 + westerneurope * weight2
<heat>
no get fucked spaniards woooooooooo
<zid`>
portugal's western europe weight is near 0
<heat>
1143
<nikolapdp>
1234
sympt has quit [Ping timeout: 255 seconds]
theyneversleep has quit [Remote host closed the connection]
gbowne1 has joined #osdev
gbowne1 has quit [Remote host closed the connection]
gbowne1 has joined #osdev
heat has quit [Remote host closed the connection]
<Ermine>
does red alert have building construction queues?
<zid`>
specifically red alert 1?
<Ermine>
3
<zid`>
yes then
<zid`>
one per mcv but russians can build a crane or something and build 2? would need to check GAMEFAQS
<Ermine>
1 per mcv is not really a queue
<zid`>
one queue per
<mcrod>
being an embedded person is both fun and painful
<mcrod>
it's fun because you're reading technical manuals and there's a lot of thinking and planning, almost like you're a surgeon
<mcrod>
now, why is it painful
<mcrod>
any guesses?
<zid`>
because you can't read?
<mcrod>
i can read, certainly
<mcrod>
you have two more guesses
<zid`>
You get a pain in your eye every time you go to drink your coffee
<zid`>
top tip: take the spoon out
<mcrod>
the answer is: when the manual for 'x' peripheral isn't specific enough about details
<Ermine>
Those docs contain all sorts of errors
<mcrod>
right now, I'm working with a few things for fun, one of which is a humidity sensor
<zid`>
I had one more guess
<zid`>
do I get compensation
<mcrod>
no
<Ermine>
scam!
<mcrod>
maybe the ability to play elden ring if you're really lucky
<zid`>
nah my gpu isn't fancy enough
<zid`>
I have to play hitless sekiro instead
<mcrod>
you asked if you get compensation
<mcrod>
maybe it's a new fancy latest NVIDIA GPU
<zid`>
So it's a raffle entry?
<Ermine>
caveat: it's tesla
<mcrod>
sure
troseman has joined #osdev
Left_Turn has quit [Ping timeout: 246 seconds]
<GreaseMonkey>
oh right, i remember another STM32 thing: the SPI peripheral has a stupid bug where if you don't 1. expose the clock pin onto a GPIO and 2. ensure that said pin is set to a fast speed, then you read all-0s or all-1s or something
<GreaseMonkey>
i even contacted ST about it and they said it was a feature
<GreaseMonkey>
basically, sending operates in the digital domain, receiving operates in the analogue domain... but not entirely because the shift register still operates in the digital domain
<GreaseMonkey>
mcrod: ^ that might be of use to you
<mcrod>
YES, THATS WHAT IM DEALING WITH
<GreaseMonkey>
although specifically this was for an STM32L073 so they might have realised that this sort of thing is actually a bug no matter how hard you call it a feature
<mcrod>
YOU ARE A PROPHET
<zid`>
I guess it's just some deep impl. detail where the clock isn't generated unless it's 'used' like that
<GreaseMonkey>
NP, in one of the cases i actually had no need to expose the clock line ASIDE FROM THAT ONE BUG because i was using it as a general timed digital output thing
<nikolapdp>
that's a wild thing to call a feature
<GreaseMonkey>
erm, timed output/input
<zid`>
nikolapdp: any bug that isn't going to be changed is a feature
<zid`>
definitionally
<zid`>
not all features are useful features :p
<zid`>
Like my nose
<mcrod>
i didn’t think you had a nose.
<zid`>
It's a ruse, I'm actually a noseless reptile overlord
<clever>
GreaseMonkey: and i'm guessing the rx side, cant snoop on the unexposed clock, and is relying on the actual clock on the pin?
<clever>
i can see that kind of coming into play when its an spi slave
<clever>
the rx side would use the externally generated clock
<GreaseMonkey>
clever: yeah... but this also affects SPI masters too
<GreaseMonkey>
(the peripheral can do both)
<clever>
feels like laziness, the rx path just gets clocked by the external clock pin
<clever>
if its in master mode, your driving the pin, jobs done