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=23&m=9&d=8
00:27:00 <heat> geist, is it possible to have a 512KiB flattened LTO function? lol
00:28:00 <geist> i guess so, there may be issues with various arches and their ability to branch within the same function with that size
00:28:00 <geist> since usually local branch reach is not that large
00:28:00 <heat> or for somehow a jump around in a "function" to be far away
00:28:00 <heat> i think i've seen GCC (or was it clang?) separate hot and cold parts of functions
00:29:00 <heat> in separate .text sections
00:29:00 <moon-child> pretty sure both will do that
00:29:00 <heat> i wanted to basically get around the double nop in riscv branch codegen
00:29:00 <moon-child> with pgo
00:29:00 <heat> but i dont think this is very reliable
00:30:00 <moon-child> (or cold)
00:33:00 <heat> oh fuck ew i'll need to reserve a register for this in asm
00:33:00 <heat> fucking hell
00:37:00 <geist> right the double branch always trashes a register
00:37:00 <geist> usually t0, but then the compiler can account for that
00:38:00 <heat> whoever thought of the jal imm format should seriously reconsider their career
00:38:00 <geist> nah, it's very straightforward
00:38:00 <heat> what?
00:38:00 <geist> the t0 register is literally there for that reason
00:38:00 <heat> i mean the jal imm format
00:38:00 <geist> oh yeah what's wrong?
00:38:00 <heat> | imm[20] | imm[10:1] | imm[11] | imm[19:12] | rd | opcode |
00:38:00 <heat> ?????
00:39:00 <geist> ah. yes. there's rationale for it, but the immediate packing in riscv is wonky
00:39:00 <geist> it's set up so that there's actually a minimum number of combinations. ie, when bits show up they show up in the same place in all forms of the instruction
00:39:00 <geist> thus keeping the nmumber of interna muxes down
00:39:00 <geist> and for example the sign extend bit is always in the same spot
00:44:00 <zid> and your jumps are super limited :P
00:44:00 <zid> 13 bits should be enough for anybody
01:09:00 <heat> print(hex(~0x100000 + 1))
01:09:00 <heat> >-0x100000
01:09:00 <heat> THANK YOU
01:09:00 <heat> VERY USEFUL PYTHON
01:11:00 <klange> python has unlimited precision for ints, what do you want it to do, infinitely loop printing Fs?
01:11:00 <heat> i just want an ez way to look at 2s complement of numbers
01:12:00 <moon-child> usually I just do 0xffffffffffffffffffffffffffff & whatever
01:13:00 <heat> oh, cool trick
01:13:00 <heat> i wanted to check if my jump ranges were correct, which i think they are now
01:14:00 <zid> heat you should learn C
01:14:00 <zid> It's way easier than making python do bits
01:15:00 <moon-child> apparently there is a thing in java where because it doesn't have unsigned integers, if you want to store an unsigned 8-bit integer, you have to store it as a signed 8-bit integer
01:15:00 <moon-child> so then to zero-extend you have to say 0xff & whatever
01:15:00 <moon-child> they also have a special unsigned right shift thing and I think some magic intrinsic functions for unsigned compares (since zero extend doesn't work for longs)
01:15:00 <heat> ]-1MB - 1, 1MB[ looks like my jump range
01:15:00 <moon-child> because 'unsigned integers will be confusion' -James Gosling
01:16:00 <heat> zid, i dont want to write a bunch of boiler plate for that
01:16:00 <heat> boilerplate*
01:16:00 <zid> 'boilerplate'
01:16:00 <zid> printf
01:16:00 <heat> moon-child, fun fact lots of important C++ people are explicitly disavowing unsigned
01:17:00 <zid> unsigned is pretty bad
01:17:00 <heat> and size_t for container sizes
01:17:00 <heat> they want fucking signed container sizes because who'd need a big container!
01:17:00 <moon-child> I disagree with them, but I can see the argument
01:17:00 <zid> It's basically the same as the 'char' problem, there's no way to signal error cases reliably, easy to confuse 0 for invalid or valid but == 0 etc
01:17:00 <moon-child> however I think even they would agree if you have a bunch of integers in [0 255] that you should store it in a uint8_t*
01:17:00 <moon-child> or fuck who knows std::vector<std::uint8_t>
01:17:00 <zid> the char problem being "you use int so that you have space for EOF"
01:18:00 <zid> yea it's *very* rare you're actually dealing with chars as uint8_t's in practice I feel though
01:18:00 <bnchs> moon-child: what are you doing
01:18:00 <moon-child> errr an std::vector<std::uint8_t>& ?
01:18:00 <zid> except for like, file parsers
01:18:00 <moon-child> bnchs: right now? I am wrestling with the fact that mach-o is a stupid piece of shit
01:18:00 <bnchs> what are you doing, no stop, oh god, no std::vector
01:18:00 <heat> std::vector is good
01:19:00 <heat> THE C GANG WRITES A REALLOC LOOP FOR THE 400TH TIME
01:19:00 <heat> Now With Reallocarray Included!
01:19:00 <bnchs> bro shut up and use talloc
01:19:00 <bnchs> talloc gang
01:20:00 <moon-child> did you know they put strings in .text?
01:20:00 <zid> now if only std vector didn't look like an alien fetus growing out the side of the head of the language
01:20:00 <zid> .rodata and .text are the same thing in most linux distros tbf
01:20:00 <heat> yep
01:21:00 <heat> GNU ld only got support for separate rodata and text *relatively* recently
01:21:00 <moon-child> yeah but it's about the principle of the thing
01:21:00 <zid> gotta piss with the cock you got
01:21:00 <moon-child> also because it's legitimately making my life slightly harder, because I don't know what's actually code and what's not
01:22:00 <heat> did you know PE file relocations literally just poke .text?
01:25:00 <moon-child> also elf has SHF_EXECINST
01:27:00 <moon-child> heat: oh yeah doesn't like every dll get a random preferred address, and they hope they never collide, and run fixups if they do?
01:28:00 <zid> yer
01:28:00 <zid> in practice it works kinda okay?
01:28:00 <zid> just means you can guess the base address of your dll, stick the 'normal' address into .rdata
01:28:00 <zid> and if it loads where it should, no need to rewrite all the pointers
01:32:00 <heat> geist: moon-child: aha, here's a funny fact: gcc does not split riscv functions into hot or cold
01:32:00 <heat> probably due to the range limits
01:32:00 <zid> how do you make it do that normally? gprof? annotations only?
01:33:00 <heat> i was just using a rando's __attribute__((cold)) text
01:33:00 <heat> s/text/test/
01:33:00 <moon-child> how many bits does riscv give you again? Could do alternating hot/cold pages if it's not too anemic
01:33:00 <bnchs> 1-bit
01:34:00 <heat> 20
01:34:00 <moon-child> oh that should definitely be enough for that then
01:34:00 <moon-child> does riscv let you do big pages?
01:34:00 <heat> alternating hot/cold would require linker support that does not exist
01:34:00 <zid> a megabyte is enough for anybody
01:34:00 <heat> yes
01:34:00 <zid> *stares in 50MB of .exe*
01:36:00 <moon-child> yet another example of stable binary formats holding us back. (Ok, you _could_ bolt this on in a backwards-compatible way, but the need to coordinate and mess around with serialisation formats adds a lot of unnecessary friction.)
01:43:00 <geist> moon-child: yes, re: big pages
01:43:00 <moon-child> how big do they go?
01:44:00 <zid> how big do you want bb
01:44:00 <moon-child> when it comes to pages, I'm a size queen
01:45:00 <zid> My pages go all the way from A to Z
01:45:00 <heat> moon-child, 512GB
01:46:00 <heat> seriously
01:47:00 <moon-child> oh, wow, ok. So unfortunately you'd have to stop at ~1mb pages
01:47:00 <heat> oh shit SV57 even has 256TiB pages
01:47:00 <moon-child> (+/- 0.5mb displacement, and always within 0.5mb of a cold page; put a trampoline in the cold path if necessary)
01:48:00 <zid> what if you need
01:48:00 <zid> a meg of bounce pages
01:48:00 <zid> in the middle of your binary
01:48:00 <zid> .textlow (some crap) .textbounce (some crap) .texthigh and you generate a bunch of calls from textlow to texthigh
01:48:00 <moon-child> otoh maybe you have one massive page for all your code, don't worry about itlb, and just do cache
01:48:00 <zid> what happens when you get to 3MB of bounces
01:48:00 <zid> do you need to go RECURSIVE BOUNCING
01:49:00 <heat> geist, how expensive are riscv nops on real hw atm? negligible?
01:49:00 <moon-child> FUUUUUSION
01:49:00 <zid> riscv is accelerated on hw?
01:49:00 <zid> I figured it'd take the same time as an add
01:50:00 <heat> the linux code is 1) wrong 2) doesn't handle > 1MB jumps
01:52:00 <moon-child> https://twitter.com/IanCutress/status/1696218657289052249
01:53:00 <moon-child> gah it doesn't show the replies if not logged in. https://twitter.com/IanCutress/status/1696218658765422996
01:53:00 <zid> oh is that where replies went
01:53:00 <zid> a fourth of an op, on the best possible cpu then?
01:54:00 <zid> also lol moonchild has an X account
01:55:00 <heat> i also have a shitter
01:56:00 <moon-child> zid: it is my second-greatest shame, after having a Libera.chat(tm) account
01:56:00 <zid> your ranking system is crazy
01:56:00 <zid> at least irc is only partially bots
01:56:00 <zid> (or right wing assholes)
01:56:00 <moon-child> irc is boomer
01:57:00 <moon-child> twatter is millenial
01:57:00 <zid> twitter is dead
01:57:00 <moon-child> yes because millenials are dead inside
01:57:00 <zid> twitter is the myspace of twitter apps
01:57:00 <zid> X is the habo hotel
02:05:00 <geist> https://chipsandcheese.com/2023/09/03/hot-chips-2023-sifives-p870-takes-risc-v-further/ is another thing on it
02:06:00 <geist> has a weird thing where it fetches 36 bytes instead of 32 for instruction decode but i'm guessing thats so it can fuse across a boundary
02:07:00 <geist> i think this and other riscv designs are very heavily tilting towards instruction fusing. kinda makes sense in a certain way: instead of having more specialized opcodes, fuse a lot of 2 instruction sequences, as if it were a kinda new instruction
02:08:00 <geist> heat: also re: real hardware. hahahaa
02:08:00 <moon-child> it makes sense when you impose a large number of very artificial design constraints that don't actually help move anything forward
02:08:00 <zid> well, it's more like
02:08:00 <zid> when you steal a free teaching ISA with a number of very artificial design constraints so to be teachable
02:09:00 <zid> and decide to try make it.. run code
02:09:00 <geist> i think the big argument now is whether or not the compressed instructions are a good idea going forward, since they chew up a sizable chunk of the opcode space
02:09:00 <geist> zid: i dont think that's particularly fair, a large number of the riscv decisions are explicitly *not* about teaching as much as building efficient implementations
02:09:00 <geist> and they definitely learned a bunch from past mistakes
02:09:00 <zid> geist: the people who have hold of it are massively changing it yea
02:09:00 <zid> but that's why they're having to do that
02:09:00 <heat> geist, i missed the joke
02:10:00 <geist> heat: that there is real hardware
02:10:00 <zid> because it was designed as a teaching arch, to be as orthogonal as possible to the detriment of all other things
02:10:00 <geist> to test nop performance on
02:10:00 <heat> i mean, you have one?
02:10:00 <zid> so a person could realistically learn it in a class
02:10:00 <zid> (I have a logisim riscv that fits on a piece of paper)
02:10:00 <moon-child> I haven't looked at the riscv encoding specifically; others have looked at it and found some good things and some bad things. Broadly speaking for a high-power thing you definitely want compact instruction forms, and I hear riscv-c generally gets pretty good density
02:11:00 <geist> sure but it being simple does not mean it's exclusively for teching purposes
02:11:00 <zid> No, you can do anything with anything
02:11:00 <zid> But that is why it was originally made
02:11:00 <moon-child> so I'm gonna hazard that riscv with compressed instructions is better than without
02:11:00 <zid> and why they're having to *adapt* it to other uses
02:11:00 <zid> with comittees and extensions
02:12:00 <geist> moon-child: it's all tradeoffs as to whgether or not the opcode space could be used more effectively, and whether or not the complexity of the compressed forms are worthwhile in the long run
02:12:00 <geist> especially since the compressed forms are more or less fixed now, there's not really any space to add more bits to it
02:13:00 <zid> I wannt know what happens if you design a huffman compressed cpu
02:14:00 <moon-child> I think that's been done
02:14:00 <moon-child> or something like that
02:28:00 <heat> it seems like llvm actively avoids splitting asm gotos and their targets on arm64
02:28:00 <heat> when doing machine function splitting
02:28:00 <heat> safe to say it's not a problem I think
02:52:00 <geist> this zuluscsi board seems to work great
02:52:00 <geist> pop some files on an sd card formatted fat32 or exfat named hd0.img, cd1.img, etc and pop it in a scsi host
02:52:00 <geist> picks it right up as a bunch of scsi drives
03:04:00 <kazinsal> neat
03:04:00 <kazinsal> will have to get one if/when I get this vax working again
03:05:00 <kazinsal> relegate the scsi2sd to the macintosh I also need to recap
03:25:00 <kof123> what are the macintosh specifications? i mean cpu/ram/etc.
03:25:00 <kof123> what i really mean is does it run beos <runs>
03:30:00 <geist> noice, yeah i have another scsi2sd that works great on my mac plus
03:31:00 <zid> Would anybody like some cursed knowledge?
03:33:00 <moon-child> of course
03:33:00 <zid> Jello isn't boneless.
03:41:00 <kazinsal> the one I have that needs the caps for the sound area redone (and maybe the floppy controller, or I could just have a bad batch of disks that won't format) is a classic ii
03:41:00 <kazinsal> fun little machine, though it would have been nice to have gotten an SE/30 instead for the PDS slot
03:57:00 <kof123> all this fusing talk already made me decide to allow, for an interpreter, 1) chaining multiple operations that have similar operands 2) allow chaining operations with arbitrary operands (not sure this serves any purpose, 1) is slightly more succinct) and 3) basically a for loop instruction that just chains other instructions for the 4 positions (the former 2 fusing things are allowed)
03:57:00 <kof123> so...i hit my cursed quota for the day
03:58:00 <kof123> compilers are not needed, just make an instruction set that handles each operation
14:24:00 <heat> ChavGPT, has anyone tried a dtrace implementation that *isn't* the dtrace codebase itself?
14:24:00 <heat> at least the kernel bits
14:24:00 <heat> is it a stupid idea?
14:27:00 <Ermine> Lack of MADV_DONTFORK is another proof of bsd pessimality
14:27:00 <heat> hah did you read the discussion yesterday in #musl?
14:28:00 <Ermine> Yeah, though I don't understand it fully
14:28:00 <Ermine> Imo it's a nice study case
14:28:00 <heat> process does fork(), pages get mapped CoW
14:29:00 <heat> parent touches pages again, they get uncowed, you get minflts
14:29:00 <heat> even if they're not getting shared anymore, you still take page faults
14:31:00 <heat> oh i should add tracepoints for that in onyx
14:31:00 <Ermine> Yeah, but I wonder how did skarnet measure minflts (perf?) and what minflt and maxflt are
14:32:00 <heat> those are bad measuring thingies in getrusage
14:33:00 <heat> he struggled so hard /because/ getrusage is such a shit perf analysis tool
14:36:00 <gog> meoww
14:36:00 <zid> moop
14:36:00 <gog> i'm OK at my job
14:36:00 <zid> nice
14:36:00 <zid> it's weird how your evaluation changes hourly, but this is a good hour
14:36:00 <gog> i have bipolar disorder
14:36:00 * gog fingerguns
14:36:00 <zid> pew pew
14:37:00 <zid> https://media.discordapp.net/attachments/510999161387089940/1143505458490003517/unknown-42-1.png
14:37:00 <gog> ¯\_(ツ)_/¯ i seriously do though, it actually has been a severe hindrance in my life
14:37:00 <Ermine> gog: may I pet you
14:37:00 <gog> yes
14:37:00 * heat hug gog
14:37:00 * Ermine pets gog
14:38:00 * gog prr
14:38:00 * gog hug heat
14:38:00 <zid> it's pronounced bipular
14:38:00 <gog> bipurrlar
14:38:00 <gog> i could be ur angle or ur devil
14:39:00 <zid> unregistered hypercam 2
14:39:00 <zid> oh sorry I thought we were reading our tattoos
14:39:00 <gog> hhhh
14:39:00 <gog> that'd be a great tat to get
14:39:00 <zid> omg did I not show you
14:39:00 <zid> https://pbs.twimg.com/media/F4YD5neXkAA5LNR.jpg
14:47:00 <zid> literally killed gog
14:50:00 <Ermine> You mean tatoo? Tatoos bad (unless they can be removed)
14:51:00 <gog> hhhhhhhhhhhhhhhh
14:51:00 <zid> or they say unregistered hypercam 2
14:51:00 <Hammdist> I made some progress on my golang environment today. a simple program that reverses a linked list in a loop by creating new elements ala purely functional programming (thus causing gc work) seems to run OK now
14:52:00 <zid> I'm just sad I missed out on my childhood dream
14:54:00 <heat> Hammdist, nice
14:54:00 <heat> btw please explain your kernel
14:54:00 <heat> im very curious
14:54:00 <heat> how many pieces did you bring in? how hard was it?
14:55:00 <zid> chimeraos
14:55:00 <heat> chimera at least keeps linux intact
14:56:00 <zid> depends if you consider having your head cut off and grafted to another animal
14:56:00 <zid> 'intact'
14:57:00 <Hammdist> my main .c file that I wrote myself is around 1300 lines so it's pretty compact. it cuts a lot of corners, doesn't implement anything by the book but only minimally what is needed to load and run go programs. so for example pages can only be unmapped or mapped rwx. I pulled in some utility functions from other projects like cache flush etc those
14:57:00 <Hammdist> are in other files. so far the golang environment only works in QEMU next step is to get it running on the actual hardware
14:58:00 <heat> wait, you can load go programs in 1.3K lines?
14:58:00 <heat> that's pretty impressive
14:58:00 <zid> pfft my OS can load gameboy programs in that
14:58:00 <zid> you neer fawn over me though
15:00:00 <nikolar> does anyone here know how to create a device file for a disk
15:00:00 <zid> losetup + mount
15:00:00 <nikolar> i made the tinyiest linux "disto" i could but i don't know how to access the drive
15:01:00 <heat> oh
15:01:00 <heat> mount devtmpfs
15:01:00 <nikolar> i have it
15:01:00 <nikolar> it's unpopulated
15:01:00 <heat> did you enable devtmpfs??
15:01:00 <Hammdist> mknod can "make" the device file if you know the magic numbers
15:01:00 <heat> in your kernel config
15:01:00 <nikolar> yes
15:01:00 <heat> it should not be unpopulated
15:01:00 <heat> that's pretty bizarre
15:02:00 <nortti> did you compile it with storage drivers?
15:02:00 <nortti> aiui you need at least scsi on modern linux to do anything
15:02:00 <zid> Oops, it looks like something's gone wrong! Would you like to submit a crash report to Al Viro?
15:03:00 <zid> side note, it's kinda weird how partitions get devices
15:03:00 <zid> in linux
15:03:00 <nortti> (the ATA option is a trap, it's for the old /dev/hd* stuff. the modern one goes through SCSI)
15:03:00 <nikolar> oh right
15:03:00 <nikolar> i don't have scsi i think
15:03:00 <nikolar> and by unpopulated i meant by disk devices
15:04:00 <heat> lol
15:04:00 <heat> you absolutely need SCSI
15:04:00 <zid> not having the bus driver kind stops the bus working quite effectively
15:04:00 <heat> how do you not have /dev/null btw?
15:04:00 <heat> oh ok
15:04:00 <heat> yeah you need scsi and libata
15:04:00 <zid> heat who makes dev/sdb1?
15:05:00 <nikolar> udev ?
15:05:00 <zid> ah
15:05:00 <heat> hm?
15:05:00 <heat> who makes /dev/sdb1 in what sense?
15:05:00 <zid> it has to be created via scanning the real device, /dev/sdb
15:05:00 <zid> and finding partitions
15:05:00 <heat> the kernel does
15:05:00 <zid> huh
15:05:00 <heat> there's even a funny ioctl for partition rescanning
15:05:00 <zid> I mean, I guess it makes sense, but it just 'feels' like the wrong layer
15:06:00 <nortti> are you surprised that in linux, kernel does stuff?
15:06:00 <nikolar> kek
15:06:00 <zid> I'm more surprised when there isn't some arcane project required for a thing to work
15:08:00 <nikolar> rebuilt with scsi, still only tty/pty devices in /dev
15:08:00 <zid> ahci?
15:08:00 <nikolar> am i supposed to mknod /dev/sda or something
15:08:00 <zid> pci-e?
15:09:00 <heat> check dmesg
15:09:00 <heat> dmesg | grep sd
15:09:00 <nikolar> nope
15:09:00 <nikolar> nothing
15:09:00 <zid> nothing scsi got seed then, pci-e?
15:10:00 <zid> if your scsi controller is on a pci-e bus, that's sort of required too, ofc
15:10:00 <nikolar> is pci-e required for sata?
15:10:00 <nikolar> i am testing in qemu btw
15:10:00 <heat> ... yes
15:10:00 <nikolar> oh right yeah
15:10:00 <zid> yes
15:10:00 <zid> 5418:00:00.0 SCSI storage controller
15:10:00 <zid> need one of these
15:10:00 <zid> to actually talk to the drives with
15:11:00 <zid> "Good news, I now speak SCSI" "Great, what's the place we're sending the SCSI commands?" "What do you mean?"
15:13:00 <nikolar> well addind pci doesn't help
15:13:00 <nikolar> dmesg says it's initializing some pci devices
15:13:00 <nikolar> no mention of scsi/sata
15:13:00 <zid> lspci?
15:14:00 <zid> e779:00:00.0 SCSI storage controller: Red Hat, Inc. Virtio 1.0 console (rev 01)
15:14:00 <zid> Kernel driver in use: virtio-pci
15:14:00 <heat> did you add libata too?
15:17:00 <Hammdist> now after a small fix it's working on the physical board too ... but it takes 22s for the program to run on the board versus only 14s in QEMU. I thought it would be faster on the hardware (maybe not by a lot but still faster), oh well
15:18:00 <heat> depends on the code and the board
15:18:00 <heat> but it should be faster yeah
15:19:00 <zid> Pretty sure I can emulate riscv faster than a riscv can run
15:19:00 <zid> like, maybe even 10:1
15:20:00 <Hammdist> well there is room for optimization in my code, for example I currently do full tlb flush for every modification
15:31:00 <nikolar> yeah no disk devices
15:39:00 <nikolar> pci and scsi are initialized on boot though
15:51:00 <zid> is there a possibly that i'm pegrent?
15:52:00 <gog> pregonte
15:52:00 <gog> pregonate
15:55:00 <heat> proger
15:55:00 <pog> pogonate
15:55:00 <heat> Ermine, hey you made me find a bug in perfetto
15:58:00 <heat> Ermine, apply https://gist.github.com/heatd/0b0cadcc897ba59fa2e02b8f49e058a7 on top of current master and do trace /bin/testprog on make ci-test-qemu
15:59:00 <heat> you'll get a nice json trace of vm events that you can plop into ui.perfetto.dev
15:59:00 <heat> in the meanwhile i'll report le bug
16:18:00 <heat> pog: pog
17:10:00 <Ermine> heat: I've opened the trace in perfetto, what should I do now?
17:11:00 <heat> look at fork and see the page faults around it
17:12:00 <heat> if you switch to vfork and look around for share_mm you won't see any copy_on_write's after it
17:15:00 <Ermine> There's one fork_mm call on thread 1 followed by copy_on_write
17:15:00 <Ermine> On thread 2, there are several copy_on_write's, fork_mm and then some more copy_on_write
17:16:00 <heat> since we're faulting 4 pages you'll see fork_mm and then *at least* 4 copy_on_write
17:17:00 <heat> it's kinda annoying that enabling page fault atm slightly breaks everything
17:17:00 <heat> because it'd be more explicit
17:19:00 <Ermine> There's only 1 cow on thread 1
17:20:00 <Ermine> https://imgur.com/a/wCCkjW0
17:21:00 <Ermine> Oh, better this: https://i.imgur.com/IP1brgy.png
17:22:00 <heat> yeah, thread 1 is the /bin/trace program forking off
17:22:00 <heat> thread 2 is what you're supposed to look at
17:23:00 <heat> /bin/trace does "enable trace events, fork() + exec(), keep collecting traces"
17:23:00 <heat> so what you're seeing there is a fork_mm of that fork() + the CoW of the stack page for the exec
17:23:00 <Ermine> and thread 3 is testprog's child?
17:24:00 <heat> no, those threads are CPUs
17:24:00 <heat> you're looking at CPU timelines
17:24:00 <heat> so you gave it 3 threads
17:24:00 <Ermine> okay
17:27:00 <heat> ChavGPT, the fuck is up with DIF?
17:27:00 <heat> it's a super hello world format that is completely interpreted
17:27:00 <heat> no one bothered to write a JITter for this??
17:48:00 <sham1> hi
17:51:00 <zid> no
17:53:00 <Ermine> Fuck it, I'm going to build onyx without prebuilt toolchain
17:54:00 <ChavGPT> mon
17:54:00 <heat> why
17:54:00 <heat> wtf does mon mean mate
17:54:00 <ChavGPT> did you know dtrace is basically a demo
17:54:00 <heat> monday??
17:54:00 <ChavGPT> fuck if i know
17:54:00 <ChavGPT> i picked it up at some point,
17:54:00 <ChavGPT> it is sprobably an equivalent of "dawg"
17:54:00 <ChavGPT> so now i'm rolling with it, sue me
17:54:00 <heat> no, im not american mon
17:55:00 * ChavGPT burps
17:55:00 <ChavGPT> dtrace internals are rather primitive MATE
17:56:00 <ChavGPT> if you want a real loller check their zero cost sdt probe support
17:57:00 <heat> i kinda want to like, erm, rip the whole kernel thing out and try and implement it on my own
17:57:00 <heat> just using their userspace because fuck that
17:58:00 <heat> i've looked at bpftrace but i'm not confident of its utility or easyness to port to anything
17:58:00 <heat> i think it even needs llvm or some shit
17:58:00 <ChavGPT> it literally can do the same things as dtrace and more
17:58:00 <ChavGPT> so if you are not convinced of *utility*...
17:58:00 <heat> yeah it needs fucking clang
17:58:00 <heat> well, utility *to me*
17:59:00 <ChavGPT> as for porting effort for all i know it is a loller
17:59:00 <ChavGPT> are you convined of dtrae utility MON
17:59:00 <heat> dtrace is at least self contained
17:59:00 <heat> no fucking clang deps
18:00:00 <ChavGPT> because they did not have lcang
18:00:00 <Ermine> Love tarballs put in .zip
18:00:00 <ChavGPT> :X
18:00:00 <gog> hi
18:00:00 <Ermine> hi gog
18:00:00 <gog> i'm having a weird internet problem
18:01:00 <gog> my latency is like in the tens ouf thousands of milliseconds
18:01:00 <Ermine> weirdo internet
18:01:00 <gog> but it's otherwise working
18:03:00 <ChavGPT> someone probably plopped in openbsd as one of the routers
18:11:00 <gog> oops
18:21:00 <Ermine> Apparently build_toolchain.sh doesn't handle downloading mpc/mpfr/gmp
18:27:00 <heat> it does not
18:32:00 <Ermine> I don't see gh workflow file doing anything about this
18:35:00 <heat> scripts/ci/install_ubuntu_deps.sh
18:35:00 <heat> and the macos equivalent
18:36:00 <Ermine> Ah, so it's enough to have them installed on the build system
19:00:00 <heat> dtrace's codebase is fucking horrendous
19:00:00 <heat> there, i said it
19:00:00 <Ermine> gcc failed to build itself :(
19:00:00 <heat> it's just hacks on top of hacks
19:00:00 <heat> fucking freebsd pretends to be solarizzzzzzzzzz
19:00:00 <Ermine> https://paste.sr.ht/~ermine/a640d9b5adbc56569718fdb9fb65070ad5730e17
19:00:00 <heat> what gcc are you on Ermine ?
19:01:00 <Ermine> gcc (GCC) 13.2.1 20230728 (Red Hat 13.2.1-1)
19:01:00 <heat> and it can't build 12.2?
19:01:00 <heat> that's bizarre?
19:02:00 <heat> i also have a 13.2.1
19:02:00 <heat> let me try locally
19:02:00 <Ermine> I'll try with skarnet's 12.x toolchain then
19:04:00 <heat> tripadvisor mirrors suck asssssssssssssss
19:13:00 <Ermine> de wat
19:15:00 <heat> tripadvisor mirrors some gnu software
19:15:00 <heat> if you run build_toolchain enough times you might get them
19:18:00 <Ermine> I will rate gnu software on tripadvisor
19:19:00 <kof13> gcc 11.1 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100345
19:22:00 <heat> Ermine, builds here
19:26:00 <Ermine> *shrug*
19:26:00 <Ermine> Are you on arch btw?
19:27:00 <heat> yes
19:29:00 <heat> gosh this is exhausting im going to write kernel code
19:30:00 <heat> dtrace and the d stands for dogshit
19:32:00 <Ermine> Well, I'll try on arch as well
19:33:00 <Ermine> Time to remove dust off it
19:33:00 <heat> i have 0 idea why your build is going tits up
19:33:00 <heat> ubuntu works, macos works, arch works
19:36:00 <Ermine> RH messed up patching it probably
19:46:00 <dzwdz> hi
19:47:00 <dzwdz> so the osdev wiki recommends probing io ports for serial ports
19:48:00 <dzwdz> how risky is that beyond com1?
19:48:00 <dzwdz> i'm thinking that if one of those ports was reused for something else, bad stuff could happen
19:48:00 <dzwdz> maybe
20:12:00 <sham1> Sometimes the osdev wiki has dubious advice. That's one such piece of dubious advice
20:15:00 <heat> the osdev wiki is full of dubious advice but that really isn't it
20:15:00 <heat> like, the PC platform has several ranges that are mostly reserved
20:15:00 <heat> that is one such range
20:15:00 <sham1> I dunno, I'd rather check the info given by the firmware with AML
20:15:00 <heat> if you touch it, you might get garbage, you might get an actual serial port
20:16:00 <heat> yes, but you may want debug output before the ACPI tables can be parsed
20:16:00 <sham1> Do you need COM2 for that?
20:16:00 <heat> oh
20:16:00 <heat> i didn't read the beyond com1 part
20:16:00 <heat> yeah don't do that
20:16:00 <heat> just check with firmware for the proper PNP devices
20:17:00 <heat> don't assume, check
20:17:00 <heat> although in this case it's very unlikely to break anything
20:19:00 <Ermine> So it failed on arch, but in the different way
20:20:00 <sham1> Well that's Arch innit
20:20:00 <Ermine> The directory that should contain system headers does not exist: ...
20:20:00 <Ermine> and that ignored SYSROOT as well
20:21:00 <heat> because SYSROOT isn't real, i told you that
20:21:00 <Ermine> Ah, not even that real
20:21:00 <heat> ./toolchain/scripts/build_toolchain uses CWD/sysroot
20:21:00 <Ermine> I thought that it works with build_toolchain when you told it to me
20:22:00 <Ermine> dumb me
20:52:00 <Ermine> Well, this time it worked. So, fedora, fuck you! linus_showing_finger.jpg
20:52:00 <ChavGPT> fedora?
20:53:00 <Ermine> Or redhat maybe, if fedora's gcc turns out to be rhel's gcc
20:53:00 <heat> ChavGPT wouldn't know anything, he uses freebsd
20:53:00 <heat> right??
20:54:00 <heat> hold on... no one uses freebsd? really?
20:54:00 <heat> huh
20:54:00 <Ermine> I don't use freebsd and know less than ChavGPT
21:07:00 <ChavGPT> Ubuntu 22.04.3 LTS \n \l
21:07:00 <ChavGPT> :X
21:11:00 <ChavGPT> heat can we be excellent to each other for a change
21:11:00 <ChavGPT> taking apage from linux' code of conflict
21:11:00 <heat_> yes
21:12:00 <heat_> hi how are you
21:12:00 <ChavGPT> hello friend im fine thanks
21:12:00 <ChavGPT> how is onyx going
21:12:00 <heat_> its going ok
21:12:00 <ChavGPT> only ok? sorry for asking
21:12:00 <heat_> i messed around with dtrace but screw that
21:12:00 <heat_> now im doing some vfs page cache refactoringggggggggg
21:13:00 <ChavGPT> trace events in vm?
21:13:00 <ChavGPT> trace_vm.json?
21:13:00 <heat_> yeah i did that just cuz
21:13:00 <ChavGPT> what is going on here
21:13:00 <heat_> wdym
21:14:00 <heat_> i describe events in a json format and have a python script to unfuck that into generated header+source files as part of the build
21:15:00 <heat_> it is *horrendous* but im kinda proud of it anyway
21:15:00 <ChavGPT> noice
21:15:00 <ChavGPT> better than no tracing
21:15:00 <heat_> linukz does some sort of weird C preprocessor tricks that i do not understand
21:15:00 <heat_> multi-stage header parsing
21:15:00 <heat_> it's really fucked up
21:16:00 <ChavGPT> no bad mouthing linukx
21:16:00 <Ermine> Finally, built onyx once again
21:16:00 <ChavGPT> imagine if a linuks develoepr was on the channel
21:17:00 <Ermine> You both commit to linux, no?
21:17:00 <ChavGPT> what
21:17:00 <Ermine> what
21:17:00 <heat_> funnily enough i've never committed to linux
21:18:00 <ChavGPT> i have some patchen but i would not reduce myself to a rank of a linux dev
21:18:00 <heat_> i've sent patches but they never got merged
21:18:00 <heat_> it's kinda annoying
21:18:00 <ChavGPT> freel free to call heat a linux dev
21:18:00 <ChavGPT> really?
21:18:00 <ChavGPT> not even one?
21:18:00 <heat_> yeah
21:18:00 * ChavGPT chekkz
21:18:00 <Ermine> lol
21:18:00 <bl4ckb0ne> inb4 heat is the bcachefs dev
21:19:00 <Ermine> Not even that one which got highlighted on lwn?
21:19:00 <ChavGPT> that was reworekd
21:19:00 <heat_> one was some elf bug fix that kees thought was too refactory and scary, second was a fix to an obscure acpi interface that the maintainer never got merged so i assume they give 0 fucks, third was the O_DIRECTORY bug that they rejected into "WAIT, LETS BREAK ALL RULES AND BREAK USERSPACE"
21:19:00 <ChavGPT> by vfs maintainer
21:20:00 <Ermine> facepalm.gif
21:20:00 <heat_> it's like fucking, erm, annoying
21:20:00 <heat_> but oh well
21:20:00 <ChavGPT> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=9737ff46f7dc16753d7f276c476d0211d1ac33c1
21:20:00 <ChavGPT> there you are mofer
21:20:00 <heat_> OH
21:20:00 <heat_> there you go!
21:20:00 <ChavGPT> ^^^ linux fucking developer
21:20:00 <ChavGPT> LMAO
21:21:00 <heat_> hi, famous kernel hacker here
21:21:00 <heat_> blow me
21:21:00 <heat_> you obnoxious c-words
21:21:00 <ChavGPT> WHOA THERE YOU ARE NOT LINUX TORVALD YET
21:23:00 <heat_> i would not dare to place myself as high as mr linux himself
21:25:00 <zid> Just saw a fred dibnah clip being passed around, now I'm sad cus he's dead
21:25:00 <Ermine> Does build_toolchain.sh need kernel.config? Workflow file makes it for toolchains
21:25:00 <heat_> Ermine, may need it for install-headers? i'm not sure
21:28:00 <Ermine> Okay, will check tomorrow
21:30:00 <ChavGPT> heat_: change your cloak
21:31:00 <heat_> @kernel/obnoxious_cunt/heat
21:38:00 <ChavGPT> ok mjg@
21:38:00 <heat_> wait, this is mjg??
21:38:00 <heat_> wtf
21:39:00 <ChavGPT> HAHA BAMBOOZLED
21:39:00 <ChavGPT> this is joel spolsky
21:39:00 <heat_> hi joel what do you think about software
21:39:00 <ChavGPT> thank you for an excellent question
21:39:00 <ChavGPT> i think software is solved by stackoverflow
21:40:00 <kof13> solved as in fixed
21:40:00 <kof13> fixed as in neutered
21:40:00 <heat_> closed as in duplicate
21:40:00 <ChavGPT> or a bad question
21:44:00 <Ermine> heat_: made a draft PR, you may want to stop CI as this PR is about docs
21:47:00 <heat_> i don't care about stopping CI
21:47:00 <ChavGPT> OH
21:47:00 <heat_> may big tech forever dwell in building my system many times
21:49:00 <Ermine> Well if they don't limit hours...
21:50:00 <heat_> they do not
21:50:00 <heat_> for public projects
21:51:00 <heat_> i'd be broke when nightly's LLVM needs to rebuild
21:51:00 <ChavGPT> by wasting their time you are convincng them to start dong it
21:51:00 <heat_> those builds enable LTO which means 8-10h
21:52:00 <netbsduser`> does anyone have any resources on netware's architecture? other than the useNix paper from 94
22:35:00 <geist> netware as in the classic version?
22:42:00 <kazinsal> mmmm, IPX
22:43:00 <geist> i remember running it a few times as part of a testing job. classic network was somewhat like banyan vines, IIRC, in that you booted into DOS and then ran the netware.exe that took over the computer
22:44:00 <geist> was't that interesting on the console, just had a status screen without much to say
22:44:00 <geist> but what i dunno is what it did internally, as you were probably asking. was it multithreaded? mostly a big while loop? dunno
22:44:00 <kof13> the usenix paper more or less covers that
22:44:00 <geist> did it use protected mode, 32bit mode, mmu?
22:44:00 <kazinsal> iirc the original netware server implementation was what we would today call an appliance
22:45:00 <kazinsal> just a beige m68k box that booted straight into a custom server OS
22:46:00 <geist> yeah didn't know that but makes sense
22:48:00 <kof13> that is how the paper describes the x86 stuff too. a network operating system, a file server, not general purpose/etc. later versions you could even use gcc to target though, and had bash and such IIRC
22:48:00 <kof13> i mean, i like the software idea, just seems straightforward to me. pretend it is 1980 lol
22:49:00 <kof13> no split between kernel and userland. no such thing as a "process" per se, just "threads" . this sounds like me lol
22:50:00 <kazinsal> there's a book I have that's another good resource for old network OS stuff, lemme dig it out and find a link
22:52:00 <kazinsal> https://www.amazon.com/Inside-Software-Architecture-Professional-Development/dp/1587058162
22:53:00 <geist> yah at somewhere they got ahold of the unix license and started making unixware, etc
22:53:00 <kazinsal> the version I have has a different cover but it's the same book as far as I can tell
22:53:00 <kazinsal> the picture on the hardcover option matches
22:54:00 <netbsduser`> i had assumed before that netware was dead simple but based on what little i've been able to find it became considerably more sophisticated
22:54:00 <netbsduser`> and cheers kazinsal that should be interesting
22:55:00 <kazinsal> keep in mind it's mostly about 90s cisco gear
22:55:00 <kof13> everything i have heard people say is it had its niche. and ...i think the main q is what else had multiplatform clients, and what was the cost, etc.
22:56:00 <kof13> this is just to say, there was surely "non-technical" factors influencing people as well
22:56:00 <kof13> that doesn't answer the question, just ...to take you back to 1990
23:01:00 <kazinsal> https://www.alcatron.net/Cisco%20Live%202015%20Melbourne/Cisco%20Live%20Content/Enterprise%20Networks/BRKARC-2350%20IOS%20Routing%20Internals.pdf also kinda neat, a mid-level overview slide deck on Cisco router architecture from 2015
23:01:00 <kof13> vageuly related, later on (since the paper talks about "rpc" and i think a footnote said similar to corba, and mentions auto-generated "stubs/wrappers" similar to prototyping functions) ...next had their "distributed objects" stuff which people raved about...but what was the licensing cost at the time? <runs>
23:01:00 <kazinsal> often Cisco will publish slide decks from Cisco Live a year or so after the convention they're from
23:02:00 <kof13> *vaguely
23:02:00 <heat> ChavGPT, why does linux think only reg and dir files need atomic seek?
23:02:00 <kazinsal> fun fact: classic Cisco IOS and the IOSd process that runs IOS tasks on Linux are actually cooperative multitasking
23:03:00 <kazinsal> with interrupts allowing for a virtual reschedule in case of a higher priority task coming into the queue
23:04:00 <ChavGPT> heat: you do realize everyone gets atomic seek
23:05:00 <ChavGPT> heat: except for the funky special case of the underlying file being sneakily duplicatd from under you by pidfd
23:05:00 <heat> scratch that
23:05:00 <heat> "All of the following functions shall be atomic with respect to each other in the effects specified in POSIX.1-2017 when they operate on regular files or symbolic links:"
23:05:00 <heat> wait wdym?
23:06:00 <heat> only regular files and dirs get atomic seek
23:06:00 * cloudowind greets everyone
23:06:00 <ChavGPT> i thought you were talking abut the recent hack
23:06:00 <ChavGPT> i'm guessing the rest is not seekable?
23:06:00 <ChavGPT> modulo devices
23:07:00 <heat> i'm looking at 6.5.2
23:07:00 <heat> i guess
23:07:00 <heat> POSIX only requires reg files
23:07:00 <heat> and symlinks, but those are not seekable
23:09:00 <heat> what will-it-scale did you use to test the single-threaded impact?
23:10:00 <ChavGPT> read
23:10:00 <heat> kk thx
23:10:00 <ChavGPT> except if you bench linux you need to watch out for your kernel config
23:10:00 <ChavGPT> there is massive pessimizations going in stemming from gcc being bad
23:10:00 <heat> no im not benching linox
23:15:00 <zid> Bloody wordle cheaters
23:15:00 <zid> I messaged to my friend I had to guess a 1/6 to have gotten it in 3, so I felt very fortunate
23:16:00 <zid> he replies that he got it in 3 too and showed me
23:16:00 <zid> He hit a 1/102 chance.
23:36:00 <heat> ChavGPT, mr mjg i need immediate URGENT HELP
23:36:00 <heat> https://elixir.bootlin.com/linux/v6.5.2/source/fs/read_write.c#L916
23:36:00 <heat> how the fuck does this not crash
23:37:00 <heat> hold a fucking moment this is braindead
23:37:00 <heat> * If the array pointed to by *@iov is large enough to hold all @nr_segs,
23:37:00 <heat> * then this function places %NULL in *@iov on return. Otherwise, a new
23:37:00 <heat> * the caller may call kfree() on *@iov regardless of whether the small
23:37:00 <heat> * array will be allocated and the result placed in *@iov. This means that
23:37:00 <heat> * on-stack array was used or not (and regardless of whether this function
23:37:00 <heat> * returns an error or not).
23:37:00 <heat> ... i guess it works
23:37:00 <heat> fucken weird
23:38:00 <ChavGPT> klassik linux
23:39:00 <heat> hey at least its in a comment
23:39:00 <heat> could be in a 2007 commit msg
23:41:00 <heat> uiomove is kinda neat btw
23:42:00 <ChavGPT> this totally did not have to be linuxed
23:43:00 <ChavGPT> they could have a macro to roll with the idiomatic array on stack + iov pointer
23:43:00 <ChavGPT> and then a paired macro for freeing which checks
23:43:00 <heat> or R A I I
23:44:00 <heat> ~iovec_guard()
23:44:00 <heat> if (vec != inline_vec)
23:44:00 <heat> {
23:44:00 <heat> }
23:44:00 <heat> kfree(vec);
23:44:00 <ChavGPT> fuck off c++
23:44:00 <heat> this is so powerful it might need to run on POWER
23:44:00 <ChavGPT> you reminded me of rust
23:44:00 <ChavGPT> i watched a lol youtube video where fucking guy was comparing go vs rust in osme lolcode
23:44:00 <ChavGPT> multithreaded
23:44:00 <ChavGPT> he found rust sucks
23:45:00 <ChavGPT> 0 profiling
23:45:00 <ChavGPT> someone told him he has lol contnetion all over
23:45:00 <heat> ok bud
23:45:00 <heat> C++ is not rust
23:45:00 <ChavGPT> then fucking guy started complainig how hard it is to do rust
23:45:00 <ChavGPT> fearless concurrency
23:45:00 <ChavGPT> i am aware. i just said raii reminded me of rust
23:45:00 <ChavGPT> and the above loller
23:53:00 <heat> actually the more i look at uiomove the less i like it
23:53:00 <heat> it gets kinda branchy innit
23:54:00 <ChavGPT> bro
23:54:00 <ChavGPT> b in bsd stands for branchfest