channel logs for 2004 - 2010 are archived at http://tunes.org/~nef/logs/old/ ·· can't be searched
#osdev2 = #osdev @ Libera from 23may2021 to present
#osdev @ OPN/FreeNode from 3apr2001 to 23may2021
all other channels are on OPN/FreeNode from 2004 to present
http://bespin.org/~qz/search/?view=1&c=osdev2&y=24&m=4&d=12
00:08:00 <heat> mjg: it's not unreasonable to make install safe by default
00:08:00 <heat> sooo
00:09:00 <heat> if shit slows down, tough shit
00:10:00 <mjg> which part of "fsync being added for no reason" you don't understand
00:10:00 <zid> There really needs to be a better api than fsync
00:10:00 <heat> what part of "fsync is there for a reason" don't you understand
00:10:00 <zid> for doing file updates
00:10:00 <heat> there is
00:10:00 <heat> fdatasync
00:11:00 <mjg> they are claiming they are fixing a problem where the target file is in use as it is being installed
00:11:00 <mjg> and they are fixing it by using a temp file and rename, which makes it atomic
00:11:00 <mjg> existing code which happens to roll with temp file and rename also does an fsync
00:11:00 <mjg> which is of no significance to the problem they are addressing
00:11:00 <zid> I said better not more worse :P
00:12:00 <zid> it has to imply the semantics of what you want from a sequence of calls, RISC FS
00:12:00 <mjg> the problem here is that when install is used, there are literally hundreds of files to slap in
00:12:00 <mjg> by fsyncing every single one you are shafting i/o for no reason
00:13:00 <CompanionCube> isn't this stupidity what dpkg does?
00:13:00 <heat> it's called
00:13:00 <heat> data safety
00:13:00 <zid> portage installs shit to a sandbox first
00:13:00 <heat> data safety is implicitly PESSIMAL
00:13:00 <zid> so that it can undo if anything goes wrong trivially I guess
00:13:00 <zid> atomic 'big update of a lot of files' is hard
00:14:00 <zid> per-file is easy, but you'd need like, a transaction thingy to do it properly for package installs
00:14:00 <mjg> for the cases where "data safety" is important, there already is an option to provide it
00:14:00 <zid> else you might have updated ld.so.6 but not ldcache binary or whatever idk
00:14:00 <heat> i don't know what kind of install usage *doesn't* require data safety
00:15:00 <mjg> here is a trivial example from the ports tree
00:15:00 <mjg> you install into a staging area
00:15:00 <mjg> that shit then gets packaged
00:15:00 <mjg> and rm'ed
00:15:00 <zid> there are lots of cases where you don't really give a fuck because it's not important
00:16:00 <zid> because you're only installing headers, a binary, and a man page or whatever
00:16:00 <zid> and nobody cares if when you hit 'man' on a package that you're updating, you might get the old or new one deepnding how far through the install you are
00:16:00 <kof673> it says installworld as an example, and that cronjobs might get screwed up. ye olde instructions IIRC you were supposed to boot to single-user mode to installworld, so i am left wondering what the use case is
00:16:00 <mjg> except now, instead of hopefully never even hitting storage, these files will get written out cause fsync
00:16:00 <zid> but for .so + binary or whatever, you care
00:16:00 <mjg> kof673: the problem they are describing is fixed with temp file + rename, fsync literally not playing any role here
00:17:00 <kof673> sure sure sure i am just out of date on installworld
00:17:00 <heat> ok
00:17:00 <heat> i mean, i use cp in my install: targets
00:17:00 <heat> so
00:17:00 <mjg> good for you mofo
00:17:00 <mjg> meanwhile the shittery in freebsd uses install all over the place
00:17:00 <mjg> including for stuff facing immediate removal
00:18:00 <zid> need to cp them to temporary dir on the same fs first so that the real cp is nice and fast, sill
00:19:00 <mjg> meanwhile they handwave fsync being there with "atomicity being worth it", despite fsync not being a factor
00:19:00 <mjg> for the stated problem
00:19:00 <Mondenkind> wer transactional dbfs
00:19:00 <Mondenkind> posix fs is a racy mess no matter what you do
00:20:00 <zid> heat: Okay how about this, instead of transactions, we add a BFL
00:20:00 <heat> what's a bfl
00:20:00 <zid> it's like a big kernel lock, but it's a big filesystem lock
00:20:00 <heat> lgtm
00:20:00 <heat> OPTIMAL
00:20:00 <zid> and we just stall out all syscalls until the 'transaction' is done. very minimal code changes!
00:21:00 <mjg> transactions here are plausibly doable with zfs
00:21:00 <heat> yes but what about those that do not use shit filesystems
00:21:00 <Mondenkind> zid: just write the kernel in python and you get that for free
00:22:00 <zid> heat: They can implement their BFL per-thread and then do what posix does now, imply meaning from a string of syscalls in full
00:22:00 <Mondenkind> mjg: interesting, how so? i can see cow helping with mvcc, but that's not enough
00:22:00 <zid> if it supports proper transactions internally it can just use them to implement the BFL :P
00:22:00 <mjg> Mondenkind: not without further work, but broad strokes: you mount a snap under /lulupdate, make changes over there, then invoke a syscall to atomically replace the mount point with the new snap
00:23:00 <mjg> Mondenkind: it could even fail if other changes were made
00:23:00 <heat> >snap
00:23:00 <Mondenkind> oh so not actually coping with concurrent writes
00:23:00 <zid> is that the sound you get if you drop the POSIX manual on your leg
00:23:00 <Mondenkind> still, that would be a big improvement over the current state
00:24:00 <heat> actually the POSIX spec isn't that big
00:24:00 <heat> i have a pdf of it somewhere
00:24:00 <mjg> i'm not claiming this would do anything for arbitrary changes
00:24:00 <zid> You're thinking of 'crunch', that's the zfs code listing
00:24:00 <mjg> i am claiming for *system updates*, where things is assumed sane and only needs safety belts
00:24:00 <mjg> it does sound doable
00:24:00 <zid> posix is a nice clean break
00:24:00 <mjg> s/is/are/
00:25:00 * Mondenkind nods
00:29:00 <kof673> i'm still lost on why a cronjob is monitoring installworld. are they installing somewhere for a jail/vm/whatever? anyways...
00:29:00 <mjg> it's not monitoring anything
00:29:00 <mjg> it is running as installworld is running
00:29:00 <mjg> and using files being replaced with ^^
00:30:00 <mjg> if you are unlucky enough, boom
00:30:00 <kof673> yes, i just don't know when that was ever allowed
00:30:00 <mjg> technically it's not legal
00:30:00 <kof673> lol i'm not saying it is bad, just if that is what caused the issue to need to be fixed then...
00:30:00 <mjg> it very much can still break
00:31:00 <kof673> *"fixed"
00:31:00 <mjg> for example if 2 .so got updated and you need both, but you squiezed yourself into a window where you see one
00:31:00 <mjg> they are basically reducing breakage, but defo not fixing it for the stated scenario
00:35:00 <mjg> i checked gnu out of curiosity, it does the temp file thing, but no fsync
00:35:00 <mjg> interestingly does not do copy_file_range
00:35:00 <mjg> someone should probably patch that
01:36:00 <heat> mjg: would not be surprised if copy_file_range is fucked up wrt datasync
01:36:00 <heat> one must assume all filesystems are very fucked in almost every call
10:24:00 <chiselfuse> i recently learned about mmio. on linux, could i be able to check which devices are mapped to which ranges of physical addresses using `sudo cat /proc/iomem`, `sudo lspci -v`, and `sudo cat /proc/vmallocinfo`? or are these not the actual physical addresses?
10:25:00 <zid> lspci is correct
10:26:00 <zid> lspci -vvvvvv shows the BARs
10:26:00 <chiselfuse> do you know what the others are? i am sceptical about /proc/vmallocinfo because i couldn't find much info online
10:26:00 <zid> for example my scsi controller has three regions, at 9ffe04000, 9ffe05000, 9ffe06000
10:28:00 <zid> and in iomem it's claimed by virtio-pci-modern apparently
10:28:00 <zid> 9ffe04000-9ffe04fff : virtio-pci-modern
10:30:00 <chiselfuse> i can't find which field is the BAR in lspci -vvvvvv
10:31:00 <zid> Region %d
10:32:00 <zid> There's 0 through 5, any number of which may or may not be filled out
10:32:00 <zid> the capabilities pointer often has more info about what each bar is supposed to be
10:37:00 <zid> (For example the caps stuff tells me that bar 2 is for msi-x)
10:38:00 <zid> The driver already knows though so it's not super important
13:15:00 <heat> chiselfuse: vmallocinfo shows a list of vmalloc ranges (basically what linux calls virtually-mapped memory, the rest is usually more or less a linear 1:1 mapping)
13:15:00 <heat> some of those ranges are mmio mappings
13:30:00 <chiselfuse> heat: i searched for what vmalloc is but i couldn't understand. it's not the virtual address space of a userspace process of course, then what is it? are you saying it maps 1:1 with physical address space?
13:30:00 <heat> no
13:30:00 <heat> "basically what linux calls virtually-mapped memory, the rest is usually more or less a linear 1:1 mapping"
13:31:00 <heat> most things !vmalloc are 1:1 mapped to physical memory, vmalloc is actually virtually-mapped not-1:1 memory
13:31:00 <mjg> copy_file_range does mess you up
13:31:00 <mjg> anyhow bsd engineering ethos over at linux
13:31:00 <mjg> > kernel test robot noticed a -98.9% regression of stress-ng.key.ops_per_sec on:
13:31:00 <mjg> https://lore.kernel.org/oe-lkp/202404121005.d2eb358a-oliver.sang@intel.com/T/#u
13:31:00 <bslsk05> lore.kernel.org: [linux-next:master] [keys] 019e41d1be: stress-ng.key.ops_per_sec -98.9% regression
13:31:00 <heat> though note that for all intents and purposes vmalloc memory is always backed by pages, there's no demand paging for the linux kernel
13:34:00 <chiselfuse> so you're saying that vmalloc'd ranges don't map 1:1 with physical ranges. so then i wonder what "mmio" stuff in those vmalloc ranges mean. is it the ranges for mmio that appear in this virtual address space which is a kernel's internal abstraction of the physical address space?
13:35:00 <chiselfuse> sorry if it's dumb questions i'm not yet familiar with most things
13:35:00 <heat> the mmio stuff in those vmalloc ranges is 1:1 within that mapping
13:35:00 <heat> but not 1:1 in general
13:37:00 <chiselfuse> is there a resource where i can study the linux kernel (modern, not 2.6) after i get more familiar with x86?
13:37:00 <heat> various resources, most of them suck and/or are old
13:39:00 <chiselfuse> is there nothing that can at least give me a holistic view of the modern one after which i can study further through reading source code?
13:40:00 <zid> there's a bunch of stuff in Documentation/
13:40:00 <zid> for how various subsystems work in general, including memory
13:41:00 <heat> no there's no holistic view
13:41:00 <heat> linux documentation sucks
13:41:00 <heat> in general no one wants to write it except if they really need to
13:41:00 <zid> That's what books are for
13:42:00 <zid> books also suck though
13:42:00 <zid> but in reality, nobody needs to know how that code works other than the pepole who work on it
13:42:00 <zid> and if they work on it they're going to have to read the code regardless
13:42:00 <heat> linux has a strong deficit of technical writers willing to document things
13:42:00 <zid> it does however, have git blame
13:42:00 <heat> well that's not the problem, the problem is that the code is complex and hard to understand
13:43:00 <chiselfuse> how many core devs are there?
13:43:00 <zid> That's because the concept is complex and hard to understand
13:43:00 <zid> it does a lot of random shit
13:43:00 <heat> right, so write the thangz down
13:44:00 <zid> I refer you back to where we started
13:44:00 <heat> mm/vmscan.c is a 8000 line mess of a source file with a bunch of heuristics for page reclamation
13:44:00 <zid> and if you want to know what they are, you can read it, and git blame
13:45:00 <zid> and by want I mean 'need', this isn't recreational :P
13:45:00 <heat> and you'll take a lot longer than if someone just neatly wrote things down
13:45:00 <zid> how
13:45:00 <zid> it's 8000 line mess of heuristics for page reclamation, the mess of heuristics doesn't stop being a mess of heuristics
13:45:00 <chiselfuse> in general, do people in osdev like the design of the linux kernel over windows kernel or would you say that the linux kernel is uglily designed too?
13:45:00 <zid> just because I write on A5 paper
13:46:00 <heat> you'll have to parse and untangle an 8000 line source file
13:46:00 <heat> that's why
13:46:00 <heat> and then investigate wonderful interactions with other multi-thousand-line source files
13:46:00 <zid> but in a book that's trivial
13:46:00 <zid> ofc
13:48:00 <heat> one cannot fully understand linux mm without 1) being in the game for 20 years OR 2) being clinically insane and *really* dedicated
13:48:00 <heat> and they acknowlege this and acknowlege they need better docs and some clean up, but no one wants to write docs
13:49:00 <chiselfuse> can i build it with debug symbols and stop through it in qemu maybe?
13:49:00 <heat> because they're programmers and this is a FOSS project, so no one ever does anything that isn't writing code
13:49:00 <chiselfuse> s/stop/step/
13:49:00 <heat> you will be stepping through many thousands of lines of logic
13:50:00 <chiselfuse> i'll add breaks as appropriate idk :P
13:58:00 <Ermine> Clinically insane ✅
14:00:00 <Ermine> Onyx mm is much cleaner I guess
14:04:00 <heat> it is cleaner but it's because 1) less mileage 2) less features
14:06:00 <zid> fewer, smh
14:06:00 <zid> where's my whipping cane
14:15:00 <heat> i'm working on it boss
14:15:00 <heat> i'm not a MINIMALIST
14:30:00 <Ermine> "Clean" and "minimal" don't even correlate...
15:48:00 <heat> Ermine: sure they do
15:48:00 <heat> roughly at least
15:49:00 <heat> it's implicitly simpler
15:50:00 <heat> like one has to admit those insane s6 ideas about programs and web servers are pretty and conceptually simple
15:50:00 <heat> and elegant
15:51:00 <heat> they won't work as you need more features or as you need to scale up your thing, but the design is nice and pretty and you can easily draw it and be satisfied with the result
15:55:00 <heat> those ~9000 lines of page reclamation could significantly be cut down if you said swap is bad and bloated, or you could delete the whole feature if you said using more memory than you have is explicitly not supported
15:58:00 <nikolapdp> which isn't really a crazy thing to do
15:59:00 <nikolapdp> overcommitting is weird
16:01:00 <zid> I support overcomit but not swap, easy
16:01:00 <zid> you oom when you fault the memory in
16:01:00 <zid> and there isn't any
16:02:00 <heat> page reclamation is not about overcommit
16:02:00 <heat> you need to reclaim pages when doing IO for instance
16:02:00 <heat> would you only be able to do $RAMSIZE reads and writes before your kernel can't do anything further?
16:03:00 <heat> minimal people would say that's PEBKAC because 1GB of IO is plenty.
16:04:00 <zid> My ethernet driver uses the same pages over and over, yours sounds silly
16:05:00 <nikolapdp> lol
16:05:00 <nikolapdp> 1 GB is a lot for IO to be fair when most stuff works with a few pages
16:05:00 <heat> ???
16:07:00 <heat> my SSD has 22TB of writes over its lifetime
16:07:00 <heat> i'd love to tell you LBAs read, but i can't
16:07:00 <heat> would not be surprised if it's 100x the writes
16:07:00 <zid> I have good news for you, ring buffers
16:07:00 <heat> ring buffer of what exactly?
16:07:00 <nikolapdp> oh a few pages
16:08:00 <nikolapdp> not thousands
16:08:00 <zid> To reuse dma locations, so that you don't eventually do "$RAMSIZE reads and writes"
16:08:00 <zid> and run out of memory, because you can't free
16:08:00 <zid> io doesn't need to constantly churn, you just would rather free things
16:08:00 <zid> which reqiures.. free
16:09:00 <heat> i'm not talking about the IO itself, i'm talking about the page cache
16:09:00 <zid> and we're obviously not
16:10:00 <zid> We're talking about *not* using the exact implemtation of the linux page cache
16:10:00 <zid> I know you struggle to conceptualize "not linux"
16:10:00 <heat> i know you struggle to conceptualize "operating system concept that's on every operating system"
16:10:00 <heat> your idea doesn't work
16:11:00 <heat> you could have a ring buffer of N pages for reads and writes, wouldn't work for mmap
16:11:00 <heat> you'd need to *reclaim pages*
16:11:00 <nikolapdp> exactly
16:11:00 <nikolapdp> doesn't need to share pages with mmap
16:12:00 <heat> mmap-read/write coherence has existed since the 90s, and now you're looking to cut that and also run into similar hard limits but for mmap
16:15:00 <zid> yes, taht's what happens, when you don't allow overcommit
16:15:00 <zid> you run out of memory
16:20:00 <Ermine> heat: you can have small codebase which is not clean. Like musl or qbe
16:20:00 <Ermine> think of those spells from dns_parse
16:22:00 <heat> the code isn't clean but the design is
16:22:00 <heat> like, draw a dependency graph between symbols and it'll be very very clean for a libc. draw a dependency graph between symbols for glibc-oh-why-does-it-bring-it-locale-code-and-malloc
16:23:00 <heat> glibc printf is fucking meta-generated from a bunch of CPP macros
16:24:00 <heat> int main(){puts("Hello");} will bring in stdio and iconv and malloc (etc etc) because there are extra use cases it needs to support
16:24:00 <heat> the clean libc design was polluted by dirty usage of stuff
16:25:00 <zid> IFUNC
16:25:00 <heat> the musl solution to locales is pretty much "por favor yo solo hablo ingles"
16:25:00 <zid> like onyx
16:25:00 <heat> onyx's PERFECT keyboard layout
16:25:00 <zid> Your solution to keyboard layouts is not to have one, each key just gives rand()%256
16:29:00 <nikolar> MINIMAL
16:29:00 <heat> yes its a MINIMAL solution none of that dynamic keyboard layout loading and compiling bullcrap
16:29:00 <heat> don't have a pt_PT keyboard? get one, simple as
16:30:00 <heat> anything else is BLOATED
16:30:00 <heat> no one uses other keyboards anyway and if you do you're wrong
16:30:00 <GeDaMo> Just use a single morse key :P
16:31:00 <Ermine> Oh, so you're talking about global cleaness
16:32:00 <Ermine> I was thinking of local cleaness, when you read the code and 'oh, I see what it does'
16:36:00 <heat> a complex design would be something like "the page scrubbing controller goes through the lru lists, applies 10 heuristics, compares this frobble group with other frobble groups, then carefully unfrobbles the pages in a specific order such that your system doesn't deadlock, if it fails the unfrobbling it'll re-scrobble 3x before killing your
16:36:00 <heat> process, if it succeeds it'll unguzzle the pages from all the processes and retry the page allocation again keeping in mind you've already unfrobbled your frobble group"
16:37:00 <heat> complex code is something like "all variables are single letters, all the 4 struct page * variables in this 400 line function are named p1, p2, p3, p4 and i don't use defines because the preprocessor is gay"
16:38:00 <gog> yes
16:41:00 <Ermine> Well, ok, anyway
16:42:00 <Ermine> Are fallout 1 players expected to read the whole vdsg?
16:45:00 <heat> finally, #falloutdev
16:46:00 <heat> i've had new vegas for a bunch of years but i always got bored 1hr in
16:46:00 <heat> same thing for skyrim. bethesda games aren't really my thing, sorry todd
16:47:00 <nortti> isn't new vegas not-bethesda?
16:48:00 <Ermine> In internet people say that fallout 1, 2 and new vegas are TRUE and BEST fallouts
16:48:00 <Ermine> My friend says 1, 2 are boring
16:48:00 <heat> oh yeah new vegas wasn't bethesda nor todd
16:51:00 <zid> fallout alternates developers
16:52:00 <zid> generally, same as cod
16:52:00 <zid> I wish interplay didn't go bankrupt
16:52:00 <zid> black isle made cool games
16:54:00 <zid> fallout 1 was interplay, fallout 2 was black isle (part of interplay), fallout 3 cancelled due to interplay going bankrupt, black isle devs form obsidian, they release new vegas under bethesda as publisher, bethesda now has the rights and shits out fo3 and fo4 which suck
16:54:00 <heat> i think nowadays they don't exactly go tick-tock in CoD
16:54:00 <heat> fallout 3 was before new vegas btw
16:55:00 <zid> yea nv was supposed to be a spinoff, like brotherhood/tactics
17:56:00 <gorgonical> 1 and 2 are great games, but they are just older styles. Some of the last great crpgs
17:57:00 <gorgonical> It took a while for me to get into them. I started with f3 but liked the setting and concept so much that I gavae 1 and 2 a real try and got very much into them
17:58:00 <gorgonical> it has frustrated me to no end how shallow and mis-written the bethesda fallout games are
18:43:00 * Ermine succumbs to vs code once again
18:43:00 <heat> GNU NANO
18:44:00 <Ermine> the reason being jupyter notebooks
18:44:00 <heat> yeah vscode works pretty well for that
18:47:00 <Ermine> electron is the most tedious when it comes to wayland
19:20:00 <nikolar> It's almost like using the whole browser runtime to write a text editor isn't a great idea
19:21:00 <heat> it's not the whole browser runtime
19:21:00 <heat> checkmate atheist
19:22:00 <gog> hi
19:23:00 <heat> gog
19:24:00 <nikolapdp> you're right heat, there's also a separate node server running
19:32:00 <gog> heat
19:45:00 <heat> gog
19:45:00 <gog> heat
19:45:00 <heat> gog
19:45:00 <gog> heat what do you want
19:46:00 <heat> cookie
19:46:00 <gog> same
19:46:00 <gog> i should have grabbed one at the store
19:47:00 <heat> two*
19:47:00 <heat> one for me
19:49:00 <Mondenkind> gog
19:50:00 <gog> Mondenkind:
19:50:00 <Mondenkind> gog can you get me a cookie too
19:50:00 <gog> yes
19:51:00 <Mondenkind> yay
19:52:00 <heat> yay -Syu
19:53:00 <heat> my yay is fucked cuz i used pacman and it upped the libalpm's so version and now yay can't update itself and now i need to do it manually sometime
19:57:00 <Mondenkind> oh yeah that's annoying
19:58:00 <Mondenkind> .oO( arch is TRASH worse than windows level package management engineering )
19:59:00 <heat> i'm pretty sure pacman can track .so version dependencies
19:59:00 <heat> so i think yay's PKGBUILD is at fault here
20:00:00 <heat> or makepkg is doing the wrong thing for some reason
20:01:00 <Ermine> yay desktop linux
20:04:00 <geist> hmm, surprised there isn't a static version of yay
20:04:00 <geist> like that seems to be a generally good idea
20:05:00 <Mondenkind> ditto pacman, come to think of it
20:05:00 <Mondenkind> $ ldd =pacman|wc -l
20:05:00 <Mondenkind> 33
20:06:00 <geist> i remember in the old days when i would update freebsd by source they had static versions of all the essential tools for this purpose
20:06:00 <geist> netbsd has some tools in /rescue that i think may be for this purpose too
20:06:00 <Ermine> apk.static
20:07:00 <geist> ah i see /rescue in netbsd has a single hard linked 10MB binary that implements evertything
20:07:00 <geist> like 154 tools, i guess it literally has an uber linked rescue binary as part of the build process
20:07:00 <Ermine> having static busybox on a server is useful btw
20:07:00 <geist> that's kinda neat. busybox style, but in this case the real tools you get separately in /bin
20:08:00 <Ermine> because there's malware that can use LD_PRELOAD and fake syscalls
20:09:00 <geist> yah ldd shows zero external inkage
20:10:00 <geist> ah freebsd has the same thing. probably has for a long time, i just never noticed it
20:11:00 <Ermine> ldd should show that this is not a dynamic executable
20:11:00 <Ermine> at least it does so on linux
20:12:00 <heat> arch has pacman-static
20:12:00 <heat> worth noting that yay is not an essential system tool
20:12:00 <zid> does it have pacman tournament edition dx
20:12:00 <zid> steam does
20:13:00 <heat> yay is what some people use to install packages from the AUR (built from source, 3rd party stuff usually)
20:13:00 <geist> how much ISK does that cost?
20:13:00 <heat> thus this is not really a "linux desktop moment" because my mom should not be building packages from the AUR
20:13:00 <Ermine> heat: fwow static hello world is 3M with glibc and 76K with musl
20:14:00 <heat> yep
20:14:00 <Ermine> fwiw*
20:14:00 <Ermine> aur is unavoidable under arch linux
20:15:00 <heat> no it's not
20:15:00 <Ermine> it is if you want some actual software
20:15:00 <heat> i dropped the google-chrome aur package and moved to a flatpak, best decision of my life
20:16:00 <Ermine> e.g. i need hplip plugin for my printer
20:17:00 <heat> most desktop software has flatpaks, other software can usually be installed with a crappy installer or a tarball or something
20:17:00 <Ermine> and at some point I had libc++ for discord
20:17:00 <heat> i've grown to hate the AUR because you truly need to audit things
20:17:00 <heat> well, *should*
20:18:00 <Ermine> also lib32-gst-plugins-ugly for wine
20:19:00 <Ermine> It's like random repos from open build service when you are on opensuse
20:20:00 <heat> yes, or random ubuntu ppas
20:21:00 <Ermine> in my case i need ppas only for firefox and veracrypt
20:21:00 <Mondenkind> flatpak😱😱❌❌🤮
20:22:00 <Ermine> ^
20:22:00 <Mondenkind> i've grown to hate official package repositories because you truly need to audit liblzmas
20:22:00 <heat> god forbid software works without issues
20:22:00 <Mondenkind> well, *should*
20:22:00 <heat> i hate official package repos too
20:23:00 <heat> you realize arch linux devs can push whatever without any supervision right?
20:23:00 <heat> half-assed security process
20:50:00 <geist> fun ARM64 instruction i stumbled upon today: EXTR
20:50:00 <geist> it's a superset of ROR
20:51:00 <nikolapdp> is it short for extract?
20:51:00 <geist> yah
20:51:00 <geist> https://developer.arm.com/documentation/ddi0602/2022-06/Base-Instructions/EXTR--Extract-register-
20:51:00 <bslsk05> developer.arm.com: Documentation – Arm Developer
20:51:00 <Mondenkind> x86 did it first
20:51:00 <geist> oh?
20:51:00 <Mondenkind> shrd
20:51:00 <geist> i kinda doubt it
20:51:00 <geist> hmm, lets see
20:52:00 <geist> ah yeah, indeed
20:52:00 <geist> didn't know about that one on x86 either
20:52:00 <Mondenkind> .oO( so when x86 does something it's 'disgusting' and 'cisc', but when aarch64 does it it's 'cool' and 'fun'. we really do live in a society😔 )
20:52:00 <geist> wow. okay.
20:52:00 <nikolapdp> lol
20:55:00 <geist> trying to work around ths warning: https://gcc.godbolt.org/z/EofG4GvMr
20:55:00 <geist> but i can't figure out how to tell gcc to shut up about that
20:55:00 <geist> yes i know i'm cramming a 64 bit value in a 63 bit bitfield, but it's shifted over and i know that
20:55:00 <nikolapdp> or it with 0x7ff..ff?
20:55:00 <nikolapdp> sorry, and it
20:56:00 <geist> nope
20:56:00 <geist> doesn't work
20:56:00 <geist> nor does pre-anding it with 0xff....e
20:58:00 <nikolapdp> eh smells like a bug potentially
20:58:00 * Ermine RORs
20:58:00 <geist> Ermine: yah ARM apparently implements ROR as a pseudo instruction to this one
20:58:00 <geist> ARM64 that is, ARM doesn't have it
20:58:00 <Mondenkind> geist: in c you can cast to unsigned _BitInt(63)
20:59:00 <Mondenkind> but doesn't work in c++
21:00:00 <geist> yah
21:00:00 <nikolapdp> huh yeah it did compile it as cpp for some reason even though it was run with gcc
21:01:00 <geist> well, the language is picked up in the drop down
21:01:00 <Mondenkind> i just passed -x c
21:01:00 <nikolapdp> oh duh i am being dumb
21:01:00 <nikolapdp> i did too
21:01:00 <Mondenkind> because if you switch the language in the dropdown it gets rid of the code
21:01:00 <Mondenkind> anyway i would pragma push to get rid of the warning
21:01:00 <Mondenkind> or stop using bitfields :)
21:02:00 <geist> yah in this case it's precisely because i need to pack a bool and a 64 bit value in.
21:02:00 <geist> i guess i can just or the bool with the val and move on with life
21:02:00 <geist> it's a space saving thing basically
21:02:00 <geist> in this it's the TLB flushing routine in the kernel, it's building a list of pages to flush and if they're terminal or not
21:03:00 <geist> so i guess since the addresse are 12 bit aligned i can just or it in, was trying to be nicer about it
21:03:00 <geist> <shrug>
21:06:00 <Ermine> vs code doesn't show function parameters hints :(
21:15:00 <geist> yah fuck it i'll just do it manually: https://gcc.godbolt.org/z/G8YrPhxb4
21:15:00 <geist> bitfields are for chumps
21:21:00 <gog> hi
21:21:00 <geist> a gog!
21:21:00 <gog> s
21:21:00 <gog> when
21:32:00 <heat> google C++ geist with the nice pretty typesafety vs raw C geist with tha bitmaskz
21:32:00 <geist> i was actually optimizing it from the current version, whcih uses some gnarly templatey bitfield stuff that's rolled in house
21:33:00 <geist> when i looked at the codegen it was terrible, actually emitting mutliple 8 byte memcpys to modify the bitmap
21:33:00 <geist> so i was just trying to convert it to a plain bitfield
21:33:00 <heat> oh isn't that what you use for nearly everything hw reg with bitfields?
21:33:00 <heat> or am i thinking of the wrong thing
21:33:00 <geist> it was a different one: FBL_BITFIELD
21:33:00 <Mondenkind> memcpys aren't optimised properly?
21:33:00 <geist> it's kinda neat, but under the hood it uses a bit union, and the code can be in some cases terrible for Some Reason
21:34:00 <geist> Mondenkind: well, sure, but this is something that you dont need memcpies for
21:34:00 <geist> it's just packing a 52 bit address + a bool into a single 64bit value
21:34:00 <geist> (to save space on the stack)
21:34:00 <geist> anyway https://gcc.godbolt.org/z/qdYz135xh is what i have now
21:35:00 <heat> yeah that looks okay
21:35:00 <heat> but type safety is LAME
21:36:00 <Mondenkind> getters and setters
21:36:00 <geist> https://fuchsia-review.googlesource.com/c/fuchsia/+/1023620 specifically
21:36:00 <bslsk05> fuchsia-review.googlesource.com <no title>
21:36:00 <Mondenkind> geist actually in his java era
21:36:00 <geist> oh gosh no i haven't written java ever
21:36:00 <geist> and i intend on keeping that way
21:37:00 <heat> >ConsistencyManager
21:37:00 <heat> most definitely in his java era
21:37:00 <heat> TlbConsistencyManagerController
21:37:00 <geist> heh i actually didn't write the initial thing
21:37:00 <geist> but actually that design works great: at the top level when you start to drill into the mmu page table, pass a ref to this class which builds up alist of TLB things to do
21:38:00 <Mondenkind> AbstractTlbConsistencyManagerControllerFactoryBean
21:38:00 <geist> then RAII makes sure everything gets cleaned up on the way out
21:38:00 <heat> i have that yeah
21:38:00 <heat> https://github.com/heatd/Onyx/blob/master/kernel/arch/x86_64/mmu.cpp#L929
21:38:00 <bslsk05> github.com: Onyx/kernel/arch/x86_64/mmu.cpp at master · heatd/Onyx · GitHub
21:39:00 <geist> there's a new thing someone else added recently that acts as a cursor for the page walker as it goes through the levels
21:39:00 <geist> and also cleans up some of the walking code and lets it pick up where it left off
21:43:00 <geist> heat: https://fuchsia-review.googlesource.com/c/fuchsia/+/1021452 was the DSB + ISB thing. i ended up adding some logic to the consistency manager that causes it to ISB on the way out if it fiddled with a kernel page
21:43:00 <bslsk05> fuchsia-review.googlesource.com <no title>
22:06:00 <heat> >cpu cannot specualatively
22:07:00 <heat> literally unusable
22:07:00 <heat> Nacked-by: heat
22:08:00 <heat> couldn't you just take the spurious page fault?
22:08:00 <zid> heat are you specual
22:10:00 <heat> mommy always told me i was a specual boy
22:14:00 <zid> I'm specular, personally
22:14:00 <zid> but I am hoping to become phong
22:14:00 <heat> are you gouraud or not even that
22:15:00 <zid> matte is for disgusting perverts
22:25:00 <geist> heat: no we completely dissalow kernel page faults
22:26:00 <geist> didn't want to go down that rabbit hole of making it sometimes okay, sometimes not, so it's just hard NAKed
22:26:00 <heat> huh okay
22:26:00 <heat> even for riscv?
22:26:00 <geist> why would riscv be different?
22:26:00 <heat> cuz of needing to shootdown tlbs after mapping a page
22:27:00 <geist> shootdown the tlb
22:27:00 <heat> like any page
22:27:00 <heat> that sounds pretty awful
22:27:00 <geist> there are lots of things in riscv that are pretty awful
22:27:00 <heat> correct, this is one of them
22:27:00 <heat> it is as one habitual pisstaker here would say "pessimal."
22:28:00 <geist> note we do take page faults whiule running kernel code, but only when handling faults within user_copy
22:28:00 <geist> but general page faults int he kernel, we actually have a panic in the PF handler
22:28:00 <geist> but it does mean break-before-make is particularly difficult to deal with
22:58:00 <mcrod> wow
22:58:00 <mcrod> for some strange reason, when using clang on mac, -Og totally trashes even the simplest ubsan output
23:05:00 <mcrod> well to be clear
23:05:00 <mcrod> it doesn't TRASH it
23:05:00 <mcrod> but you lose a lot of information
23:06:00 <zid> >strange reason >mac >clang >ubsan
23:06:00 <mcrod> http://pastie.org/p/2EnY6qUCLG5Et3OHt6elHK
23:06:00 <bslsk05> pastie.org: Pastie
23:14:00 <mcrod> http://pastie.org/p/30Jc12jLV1S4JQu5T3dP0w for the simplest code
23:14:00 <bslsk05> pastie.org: Pastie
23:37:00 <geist> mcrod: iirc, -Og isn't real on clang? i think it may just alias to -O1 or something
23:37:00 <mcrod> it is on modern versions now
23:37:00 <geist> we dont use it in fuchsia for that reason. are you sure it's real?
23:37:00 <mcrod> i'm sure
23:37:00 <geist> or more like the switch is implemented?
23:37:00 <geist> hmm, interesting
23:38:00 <geist> maybe we just dont use it because it's bad, as you found out :)
23:38:00 <mcrod> of course, google is failing me
23:38:00 <mcrod> well it also shits the bed on -O1
23:38:00 <mcrod> and the clang docs say -O1 is ok
23:38:00 <mcrod> -Og is -O1 minus some features that can kill debugging experience
23:39:00 <geist> see the thing is the real docs say something like 'in the future it may...'
23:39:00 <geist> https://clang.llvm.org/docs/CommandGuide/clang.html#cmdoption-O0:~:text=%2DOg%20Like%20%2DO1.%20In%20future%20versions%2C%20this%20option%20might%20disable%20different%20optimizations%20in%20order%20to%20improve%20debuggability.
23:39:00 <bslsk05> clang.llvm.org: clang - the Clang C, C++, and Objective-C compiler — Clang 19.0.0git documentation
23:41:00 <geist> and that lines up pretty much with what the compiler folks at work are telling me
23:41:00 <mcrod> i swear to god
23:41:00 <mcrod> they implemented -Og to be closer to gcc -Og in later versions
23:41:00 <geist> sure, could be the docs are out of sync
23:42:00 <geist> i have no particular skin in this game
23:42:00 <mcrod> fair
23:42:00 <mcrod> but i'm bothered by the fact I can't find the post
23:43:00 <Mondenkind> i don't think -Og has ever done anything useful even in gcc
23:43:00 <Mondenkind> i mean like
23:43:00 <Mondenkind> i think there've been. a couple of occasions where it got rid of an <optimised out>? but broadly speaking i haven't found it to make a big difference
23:44:00 <mcrod> the manual says it's better than -O0
23:44:00 <mcrod> but that's what it *says*
23:44:00 <geist> i think in general not optimizing the flow of the code but removing all the extraneous stores to the stack would be a huge win
23:44:00 <mcrod> what it *does* is a different matter
23:44:00 <geist> and things like constant expression collapsing
23:44:00 <geist> -O0 is just so basic it's hard to use
23:45:00 <mcrod> i've had a time convincing one of the older embedded guys at work about code size with relation to gcc
23:45:00 <mcrod> you can't use -O0, to be clear
23:45:00 <mcrod> you have to use -Og or -O1
23:45:00 <geist> i think the idea is modern dwarf is pretty good at describing fairly complicated things, so just having to write everything on the stack is not really unnecessary
23:45:00 <geist> s/unnecessary/necessary
23:47:00 <Mondenkind> i mean i definitely think the debuggability:performance pareto frontier could be pushed way further
23:47:00 <Mondenkind> but gcc/llvm is bad at most things sooooo
23:54:00 <heat> mcrod: where's the bed shitting?
23:55:00 <mcrod> you must be blind
23:55:00 <mcrod> a whole bunch of information is clearly gone
23:55:00 <heat> the only difference is that ASAN isn't being triggered, because UBSAN already is
23:55:00 <heat> you know the null pointer was dereferenced
23:55:00 <heat> it *will* crash anyway
23:55:00 <mcrod> ok i guess
23:59:00 <heat> also omg mcrod question that doesn't involve psx emulator code and 3 layers of preprocessor macros