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=3&d=7

Tuesday, 7 March 2023

00:03:00 * kof123 quietly puts on shades to avoid blink of death
00:05:00 <heat> gog
00:24:00 <heat> damn left me on read huh
00:33:00 <zid> left you on unread
00:52:00 <heat> gog's favourite dark souls boss is capra demon
01:07:00 * moon-child tries to pet gog, but hands pass harmlessly through the air
01:10:00 * sakasama emits ionising radiation.
01:13:00 * moon-child pets sakasama
01:14:00 * sakasama 目からビーム's moon-child.
01:18:00 <bnchs> mew mew mew
01:18:00 <bnchs> heat: there's nothing wrong than the entire channel going silent as you say something utterly retarded
01:19:00 <bnchs> nothing worse*
01:29:00 <geist> heat: word. re tianocore riscv
01:29:00 <geist> who was doing the work? I wouldn't be surprised if some of the new server riscv startups are starting to get serious about it
01:29:00 <geist> ie, aint got not time for no uboot on a server
01:30:00 <heat> ventana micro
01:31:00 <heat> i think they've been doing good work all over the low level stack on riscv
01:31:00 <heat> now Intel is in on it, so was HP
01:33:00 <geist> ah yeah ventana. yeah they're one of the ones that are going to try to make Big RiscV
01:35:00 <heat> "EDK2 for qemu virt is booted in S-mode as a payload for M-mode FW"
01:39:00 <NicePotato> I am struggling to figure out where to start when implementing a GDT and a IDT I have followed the meaty skeleton thing, and added to it (currently all of the sample inline assembly functions and pcspeaker) I have looked at the GDT and GDT tutorial pages on the wiki, but I am not understanding it. I have looked at others implementations, but I
01:39:00 <NicePotato> still have no idea how they work. Any easier to understand (not simpler) tutorials?
01:40:00 <NicePotato> I have a github of my source if thats wanted
01:41:00 <heat> what part do you not understand?
01:41:00 <geist> also it will sound a bit like a broken record, but the intel and AMD manuals do describe what the IDT and GDT are for and what the bits mean
01:41:00 <geist> not that they're necessarily any clearer
01:41:00 <geist> but you should be able to cross reference what the wiki and whatnot are against the manual
01:41:00 <NicePotato> I don't know where to start implementing it into my kernel. I understand what they do, but not how to implement them into my operating system
01:42:00 <Mutabah> The GDT should just be a hard-code and forget thing really
01:42:00 <NicePotato> Am I supposed to use asm files, or add them to some of those .S files?
01:42:00 <geist> well, in the abstract you need to have at least a starting GDT, can have it precomputed, and load it once atkernel start
01:43:00 <geist> ah. well you can do it any number of ways, including defining and loading them in C
01:43:00 <Mutabah> `.S` is the extension for the gnu assembler
01:43:00 <geist> the only piece of ASM tou actually need is the lgdt and lidt instruction
01:43:00 <Mutabah> `.asm` is traditionally nasm/fasm (anything that uses intel syntax natively)
01:43:00 <NicePotato> I used NASM before when I tried creating my system in real mode
01:44:00 <geist> think of it as just a in memory data strcutre that has to be 'loaded' into the cpu
01:44:00 <heat> if you understand what they do, what part do you not understand?
01:44:00 <geist> ie, you create this table somewhere in memory (hard coded is fine) and you use the lgdt instruction to point the cpu at it
01:44:00 <geist> you can do that in either asm or C. lots of examples will use asm, which is fine
01:44:00 <heat> whether they are in a .S or in .c or in .cpp or .rs or whatever is just an implementation detail
01:44:00 <NicePotato> Do I just plop this into a header and include it in my kernel (plus load it of course)?
01:44:00 <NicePotato> https://wiki.osdev.org/GDT_Tutorial
01:44:00 <bslsk05> ​wiki.osdev.org: GDT Tutorial - OSDev Wiki
01:45:00 <geist> well, depends on if that does what you want
01:45:00 <geist> does it have the segments you need?
01:45:00 <heat> how about you write your own code?
01:45:00 <NicePotato> I'm not sure what parts I need for my system :P
01:45:00 <NicePotato> what is that emoji eww
01:46:00 <heat> ok you need a null segment, a code segment for ring 0 ("kernel mode"), a data segment for ring 0 ("kernel mode")
01:46:00 <heat> anything else will come later
01:46:00 <geist> okay, so then question: are you writing 32 or 64 bit?
01:46:00 <heat> must be 32 geist, you need a GDT to jump to 64
01:46:00 <NicePotato> 32-bit, but plan on adding 64-bit support in the future
01:46:00 <geist> okay, then yeah you need just 3 entries as heat point out
01:47:00 <geist> there are example ones in the wiki page
01:47:00 <heat> if you understand what traditional segmentation is, consider that in anything remotely relevant you just set up "flat" segments (that span the whole memory)
01:47:00 <geist> under the flat-example thing
01:48:00 <NicePotato> Those are assembly, I'm not sure where I need to put them?
01:48:00 <geist> just somewhere in memory
01:48:00 <geist> can just be part of your kernel, doesn't matter. a global variable
01:48:00 <geist> as long as your kernel is loaded the table is just somewhere in memory by definition
01:48:00 <heat> again, how about you write your own
01:49:00 <heat> you say you understand it, so get to it
01:49:00 <NicePotato> I don't fully understand it
01:49:00 <geist> heat: it's fairly obvious they dont at all, but wasn't going to bust their chops about it
01:49:00 <heat> then get to that first
01:49:00 <NicePotato> I meant I understood what its for
01:49:00 <NicePotato> sorta
01:49:00 <geist> meh, frankly i'm not so sure it's a huge value to grokking it before using it
01:49:00 <NicePotato> maybe I dont
01:49:00 <geist> because it's just legacy nonsense
01:49:00 <geist> you'll eventually want to know it, but frankly it's just a necessary step at this point
01:50:00 <NicePotato> I want to add disk support and keyboard support next. I do need both the GDT and IDT for these, correct?
01:50:00 <heat> I think it's important to free yourself from the shackles of "copying tutorials"
01:50:00 <heat> yes
01:51:00 <geist> agree, but certain things are just boilerplate on x86 frankly
01:51:00 <geist> shit you gotta do to get to the useful stuff
01:51:00 <geist> that you can fill in later
01:51:00 <geist> i dont think this wiki page helps either, because it goes out of its way to try to explain the theory of everythingm and then show these complicated ways to construct it
01:52:00 <geist> vs 'here's a fuckin table for those that just need the same dumb ass table everyone has to build'
01:52:00 <geist> i'd point you at my table but i'm not sure it'll help, since i also do it in a kinda convoluted way that'll just be more confusing
01:53:00 <heat> https://github.com/heatd/Onyx/blob/master/kernel/arch/x86_64/boot.S#L624
01:53:00 <heat> enjoy
01:53:00 <bslsk05> ​github.com: Onyx/boot.S at master · heatd/Onyx · GitHub
01:53:00 <Mutabah> https://github.com/thepowersgang/rust_os/blob/master/Kernel/Core/arch/amd64/start.asm#L671-L678
01:53:00 <bslsk05> ​github.com: rust_os/start.asm at master · thepowersgang/rust_os · GitHub
01:53:00 <Mutabah> Darn, got ninja'd
01:53:00 <heat> from 624 to 628
01:53:00 <heat> no, you got AUTOCONF'd
01:54:00 <geist> bingo, thats what you want
01:54:00 <Mutabah> Why two gdt blocks?
01:54:00 <geist> https://github.com/littlekernel/lk/blob/master/arch/x86/gdt.S#L35 is mine
01:54:00 <bslsk05> ​github.com: lk/gdt.S at master · littlekernel/lk · GitHub
01:54:00 <NicePotato> Wait, I'm confused, how are these loaded into the GDT with those asm functions?
01:54:00 <heat> rtfm
01:54:00 <geist> lgdt
01:54:00 <Mutabah> none of these are functions, they're data
01:54:00 <geist> look at the manual for how lgdt works
01:55:00 <heat> Mutabah, second gdt is for 64-bit stuff. I don't have 32-bit kernel segments in the 64-bit gdt
01:56:00 <Mutabah> Ah. You could probably do with comments on the first one that it's 32-bit only?
01:56:00 <Mutabah> Although, you do you
01:56:00 <heat> first is just the bare minimal for bootstrapping myself into a defined protected mode (or into it at all, if coming from SMP wakeup)
01:56:00 <heat> yep, probably
01:57:00 <heat> all that code is slowly getting improved over time
01:57:00 <Mutabah> mine is labelled `smp_init_gdt` - much clearer :)
01:57:00 <heat> yeah
01:58:00 <NicePotato> what is the linear base address?
01:58:00 <geist> hmm, maybe this is easier to grok: https://github.com/travisg/3x86/blob/master/x86/x86.c#L30
01:58:00 <bslsk05> ​github.com: 3x86/x86.c at master · travisg/3x86 · GitHub
01:58:00 <geist> loaded in C later with https://github.com/travisg/3x86/blob/master/x86/x86.c#L92
01:58:00 <bslsk05> ​github.com: 3x86/x86.c at master · travisg/3x86 · GitHub
01:58:00 <heat> old files such as this one have been through heaven and hell and various amounts of author proficiency
01:59:00 <Mutabah> NicePotato: Linear addresses are after segmentation, but before paging
01:59:00 <geist> that does the GDT stuff in C entirely
01:59:00 <heat> sometimes even frakensteined from various tutorials. which bit me, which is why I'm so anti tutorial
02:01:00 <NicePotato> geist: so that also has implementation for the IDT?
02:01:00 <geist> yes
02:01:00 <heat> the IDT is not "silly x86"
02:01:00 <geist> note that this code assumes it's already in 32bit protected mode. because otherwise it couldn't be in C already
02:01:00 <heat> it's important to understand that one
02:01:00 <geist> correct. GDT is silly x86. IDT is important
02:02:00 <geist> the main reason you see a lot of GDT stuff in asm is lots of code is setting it up before it gets to protected mode, bvecaus eyou need it to
02:02:00 <geist> or to get to long mode. but if you came out of a bootloader like grub that already started the cpu in protected mode
02:02:00 <geist> then you can use C to switch to 'your' GDT and 'your' IDT
02:04:00 <geist> NicePotato: please do not just copy this code, i'm trying to help you by giving you another eample to look at and try to understand
02:04:00 <geist> since clearly the asm part was tripping you up
02:04:00 <geist> the IDT you'll really need to grok, and you *really* need to grab the intel and/or AMD manual and have it ready
02:04:00 <mrvn> NicePotato: And it's highly recommended that you go to 64bit directly. Forget about 32bit. There is no need to learn all the obsolete bits just to have to relearn gdt/idt/tss again for the long mode bits.
02:04:00 <geist> you cannot rely on the osdev wiki for this stuff
02:04:00 <NicePotato> geist: yes, I won't shamelessly copy and paste, I have looked through almost all of the meaty skeleton and made changes as needeed (like adding cursor support and newline support)
02:05:00 <geist> umm. okay.
02:05:00 <NicePotato> mrvn: I want to support older computers before 64-bit
02:06:00 <mrvn> NicePotato: older like 3 decades old? Anyone that uses one of those should get a new "old" computer, you get them for free basically.
02:06:00 <NicePotato> That's true, I'll look into it
02:08:00 <NicePotato> It took me like 3 hours to figure out the kernel wasn't compiling because of a missing newline character in one of the make.config files (why???)
02:08:00 <geist> you aint seen nothing yet, if you want to build a kernel from scratch
02:09:00 <heat> i remember my couple of days just straight up debugging random heisencrashes under load
02:09:00 <NicePotato> You're correct, i'd count on it. I have been working on my os for over 6 months, and restarted twice
02:09:00 <heat> "geist: that sounds like a tlb issue"
02:09:00 <heat> it was indeed a tlb issue
02:09:00 <heat> :^)
02:10:00 <NicePotato> what's a "heisencrash"
02:10:00 <heat> well it's like a heisenbug but crashes instead
02:10:00 <heat> trademark me, 2023
02:10:00 <NicePotato> well then whats a heisenbug?
02:12:00 <heat> bing it
02:12:00 <NicePotato> I could just look it up
02:12:00 <heat> >what's a bing
02:12:00 <NicePotato> search engine
02:13:00 <geist> heat: oooh yeah? what was it?
02:15:00 <heat> my stack deallocation wasn't doing the TLB shootdown correctly, because the invlpg inline asm had a wrong constraint (so it was shooting down the address of a local variable...), which made subsequent stack allocations on other CPUs pick up the bad TLB entry, which crashed with stupid stacks
02:17:00 <NicePotato> I just realized I have no idea what a struct is in c, no wonder I have no idea what I'm looking at
02:18:00 <geist> heat: ahhh yeah that'll do it. years ago i had a similar TLB issue with reusing virtual slots where a stack was and it is a real heisenbug
02:18:00 <geist> lots of times if i see a odd failire like that around a lot of thread teardown my thought is immediately this problem
02:18:00 <heat> __asm__ __volatile__("invlpg %0"::"m"(addr));
02:18:00 <geist> since kernel stack deletion is one of the few places that usually stress out TLBs in the kernel
02:19:00 <heat> find the bug :/
02:19:00 <heat> yep
02:19:00 <NicePotato> So is a c struct kind of like a lua table?
02:19:00 <heat> erm
02:19:00 <heat> you should figure out your C/C++
02:20:00 <NicePotato> ?
02:20:00 <heat> asking us what a C struct is and trying to compare with lua tables is not the most productive use of everyone's time
02:21:00 <klange> The answer to "is a c struct kind of like a lua table" is "oh boy, you sweet summer child..."
02:21:00 <heat> at that point you're way better off by picking up the k&r book and going through it
02:21:00 <NicePotato> I wasn't asking what a C struct is, I've just never had to use one before
02:21:00 <heat> "I just realized I have no idea what a struct is in c,"
02:21:00 <geist> right, what folks are saying is you really should stop and learn some more basic C stuff before continuing
02:21:00 <NicePotato> It looks quite similarly structured to a lua table
02:22:00 <geist> since you're about to get into the super deep end of needing to know a *lot* about the inner workings of C
02:22:00 <geist> like this is just the tip of the iceberg. you'll need to hav ea good grasp of how C allocates memory, where it puts things, how functions are called, how the stack is used, etc
02:23:00 <geist> static vs global vs local variables, that sort of thing. you really need a solid understanding of that before getting too far
02:23:00 <NicePotato> I have somewhat of a grasp on those
02:23:00 <NicePotato> Not sure how well though
02:23:00 <heat> you just told us you've never used a struct before
02:23:00 <geist> somewhat of a grasp that you dont know how much is correct is insufficient
02:24:00 <NicePotato> yea, I've never had to use a struct
02:24:00 <heat> so chances are your C knowledge is very limited
02:24:00 <NicePotato> probably :/
02:24:00 <geist> anyway, this is fine. you have to start somewhere. just be aware of your limitations and endeavor to correct them first
02:24:00 <geist> go through a full C set of tutorials, books, whatever. make sure you are at least aware of all of the C basic stuff
02:24:00 <geist> thankfully it's a fairly simple language, by modern standards
02:25:00 <heat> k&r boooooooooooooooooooook
02:25:00 <geist> but you'll need to be very proficient with all types of pointers and all of the concepts of memory management behind it
02:25:00 <geist> and we're telling you this so you dont waste a bunch of your time in teh future. trying to dive into osdev without a basic understanding of C is just a waste of your time. it's not productive
02:26:00 <NicePotato> What do you mean by types of pointers?
02:26:00 <geist> exactly.
02:26:00 <NicePotato> like address vs variable pointers?
02:26:00 <heat> if you had a solid grasp of this stuff you'd know what you just said makes no sense
02:26:00 <geist> like, i'm not going to teach you C right now.
02:27:00 <NicePotato> I know, I'm not going to make anyone here teach me C
02:27:00 <geist> 'all types of pointers' is a kinda silly way to say it but wha ti mean is you need to get really proficient on how to use pointers in C. and i mean more fundamenal than 'put a * in front if it' sort of stuff
02:28:00 <geist> and when you learn it you'll realize what i'm talking about. it's more subtle than it looks
02:28:00 <heat> the k&r book was typeset using a whole pipeline of unix commands, including troff
02:28:00 <heat> very retro, I love it
02:28:00 <geist> but this is all good anyway, because learning C is a valuable thing anyway. or at least for the purposes of writing your kernel, assuming you want to do it in C anyway
02:29:00 <heat> I think every C standard pre C23 was also typeset using troff ofc
02:30:00 <NicePotato> Null Pointer, Void Pointer, Wild Pointer, Dangling Pointer is what you mean by types of pointers I'm assuming? https://www.simplilearn.com/tutorials/c-tutorial/pointers-in-c
02:30:00 <bslsk05> ​www.simplilearn.com: Pointers in C: A One-Stop Solution for Using C Pointers
02:30:00 <heat> no
02:30:00 <NicePotato> oh
02:31:00 <NicePotato> whats that k&r book you mentioned?
02:31:00 <heat> bing it
02:32:00 <NicePotato> https://kremlin.cc/k&r.pdf
02:32:00 <geist> what the hell, that tutorial you linked is so stupid
02:32:00 <heat> please don't link to high seas content in the channel
02:33:00 <NicePotato> hmm?
02:33:00 <geist> it's like written by an AI
02:33:00 <geist> with the whole 4 types of pointers nonsense
02:33:00 <NicePotato> ah
02:33:00 <geist> keep in mind that a lot of random crap you find on the net is garbage
02:33:00 <geist> also what heat was saying is dont link to pirated stuff
02:34:00 <NicePotato> I didn't know it was pirated, shoot
02:34:00 <NicePotato> sorry bout thqt
02:34:00 <heat> wdym, the first result is an amazon link
02:34:00 <heat> unless you actually bing'd it and bing is THAT bad
02:35:00 <geist> heat: you should check out that tutorial they linked.it's totally random
02:35:00 <geist> it goes off on some like weird shit about dangling pointers being a 'type' of pointer
02:38:00 <heat> Pointers are like special utilities used by web developers to make it easy to map around in a program code.
02:38:00 <heat> I develop exclusively using C to WASM
02:41:00 <heat> this is somehow worse than geekstogeeks stuff
02:48:00 <NicePotato> I have glanced over the entire of chapter 5 on that k&r book and I still don't understand what you mean by types of pointers. What I thought a pointer was is just a variable with an address in RAM inside.
02:48:00 <heat> please read the whole book
02:49:00 <NicePotato> oh god
02:49:00 <heat> also"'all types of pointers' is a kinda silly way to say it but wha ti mean is you need to get really proficient on how to use pointers in C. and i mean more fundamenal than 'put a * in front if it' sort of stuff"
02:49:00 <heat> it's just an expression
02:49:00 <heat> it's a small book, 200 pages
02:49:00 <NicePotato> "small"
02:50:00 <heat> yes
02:50:00 <NicePotato> What books do you normally read?!?!
02:51:00 <heat> right now im looking at 2 maths books with >700 pages each, obama's book is also 800 pages long, etc
02:52:00 <heat> the intel cpu manuals are like 4000 all together
02:53:00 <NicePotato> ._.
03:05:00 <geist> NicePotato: yeah again i told you 'all types of pointers' is the wrong phrase
03:06:00 <geist> dont search the exact specific thing. that's entirely the problem. you're tryign to learn the language by just web searching for specific topics
03:06:00 <geist> you really need to sit down and read a book or something that tries to teach you the whole language, topic by topic
03:06:00 <geist> building on previous ones. taht's what books do
03:06:00 <NicePotato> I'm reading through that k&r book
03:06:00 <geist> random tutorials or searching the web for little topics doesn't do taht
03:06:00 <geist> good
03:06:00 <NicePotato> Maybe I'm taking types of pointers too literally?
03:08:00 <geist> you are 100% taking it too literally
03:08:00 <geist> i told you like 3 times to not take it too literally
03:08:00 <geist> it was a typo when i wrote it out
03:08:00 <NicePotato> I'm not sure how not taking it literally would be
03:08:00 <geist> ...
03:08:00 <geist> alright, i'm doing more damage then good here
03:08:00 <geist> i'm going to just shut up
03:09:00 <NicePotato> ok ;-;
03:10:00 <Mutabah> This isn't a C support channel (there's ##c for that :D), but really - pointers are just the address of something, wrapped up in some compiler abstraction
03:11:00 <NicePotato> Yes yes, sorry for going off-topic
03:30:00 <NicePotato> Now that I understand how structs work, I can understand the GDT stuff better
03:31:00 <heat> read the whole book
03:31:00 <NicePotato> I did
03:31:00 <NicePotato> glanced over everthing
03:31:00 <Mutabah> heat: Re-read their comment :)
03:31:00 <heat> ...
03:32:00 <Mutabah> Oh, wait, are you questioning how quickly they read it... yeah, that was fast for a full read
03:32:00 <NicePotato> I already have a good grasp on some other parts of C, I understood basically all of chapters 1-4
03:33:00 <heat> https://www.youtube.com/watch?v=IqzMUn90tMg
03:33:00 <bslsk05> ​www.youtube.com: The fastest Reader in the world - YouTube
03:33:00 <heat> you sure do mr "i've never used structs"
03:37:00 <voidah> heh ,osdev is not about reading speed, it's about quality writing
03:37:00 <NicePotato> heat: where did you find that video of me
04:48:00 <mats1> NicePotato: https://cdn.discordapp.com/attachments/1068960929447948358/1082508593762414722/tMYQSlQ.mov
04:49:00 <NicePotato> mats1 excuse me???
04:50:00 <NicePotato> why? why here? why me?
04:54:00 <Mutabah> NOBODY click on that link, it's not something you want to see
05:31:00 <geist> Mutabah: thanks
05:33:00 <geist> i guess +1 for discord where you can go back and delete a line, huh
05:33:00 <Mutabah> yeah... although that video was uploaded to discord... so they lose a point for making it so easy to host that alongside completely benign content?
05:59:00 <geist> -1 discord
06:12:00 <sham1> Discord is cringe
10:05:00 <zid> oops, installed my steam client backwards, now I have a bunch of meat everywhere.
10:24:00 <gog> zid: better than installing it anagramatically and getting teams
10:26:00 <theWeaver> lmao
10:26:00 <theWeaver> gog is funny :>
11:09:00 <kof123> mario kart, castle level: "oh look, free pots, i could use some of those!" <drives into lava> get out of my 8 year old head zid
11:33:00 <sham1> Never
14:06:00 <heat> gog
14:06:00 <heat> gog
14:06:00 <heat> gog
14:07:00 <heat> LITERALLY ghosted
14:07:00 <heat> smh my head
14:07:00 <sham1> Let's not get too heated about this
14:08:00 <heat> you're a sham sham
14:09:00 <sham1> Yes
14:10:00 <heat> csgo source 2 coming out omg omg omg
14:10:00 <heat> i'm hyped for anything valve
15:20:00 <FireFly> source 2 was released 9 years ago
15:20:00 <heat> that's like yesterday in valve time
15:22:00 <mjg> bur
15:22:00 <heat> omg its richard from richard and mortimer
15:22:00 <mjg> which one is rick
15:23:00 <heat> mortimer obviously
15:23:00 <mjg> iremember trying to watch the first episode some time ago and could not get past first efw minutes
15:23:00 <mjg> "drunk acting" is my pet peeve
15:23:00 <mrvn> What do you mean? *hicks*
15:24:00 <heat> i liked it
15:24:00 * mjg stumbles
15:24:00 <heat> but now it's pretty much dead so
15:24:00 <mjg> heat: genz i take it
15:24:00 <heat> yes it's very gen z
15:24:00 <mjg> is the schtick there that the 2 main characters are in fact the same person?
15:25:00 <heat> no
15:25:00 <mjg> both happy and disappointed
15:25:00 <heat> mjg, why are you not big into non-flamegraph tracing
15:25:00 <mjg> who said i'm not
15:25:00 <heat> i remember I showed you a whole system trace example and you were like "meh"
15:25:00 <mjg> you do realize all *sampling*, while most useful, can only get you so far
15:25:00 <mjg> that was presumably a comment on the thing at hand, not the concept
15:26:00 <heat> ui.perfetto.dev
15:26:00 <mjg> anyhow, tracing or not, one funamdnetal limitation of just collecting some data across the entire run
15:26:00 <mjg> is that you have no idea how it spreads over time
15:26:00 <heat> click "Open Android Example"
15:26:00 <heat> yea
15:30:00 <mjg> does not open
15:30:00 <mjg> lemme try on chrome
15:31:00 <mjg> do you know how big is it?
15:32:00 <heat> yes, it's large
15:32:00 <heat> but loads pretty smoothly here
15:32:00 <heat> so, erm, freebsd moment? nah jk you use linux
15:33:00 <mjg> linux moment
15:33:00 <mjg> oh there you go, got a progress indictaor: 59%
15:33:00 <mjg> so this thing reports stuff over time?
15:33:00 <nikolar> it took a while to load for me kek
15:33:00 <mjg> *that* is not particularly new
15:33:00 <mjg> aight it loadded
15:33:00 <mjg> now lets shit on it
15:35:00 <heat> well the thing you're looking at is a system wide trace of android
15:35:00 <heat> including kernel stuff and other shit higher up the stack
15:36:00 <mjg> good grief the thing i'm compiling psassed -DNDEBUG 4 times
15:36:00 <mjg> so how do i get user/kernel traces from there?\
15:36:00 <heat> there = what?
15:37:00 <mjg> https://github.com/Netflix/flamescope there you go
15:37:00 <bslsk05> ​Netflix/flamescope - FlameScope is a visualization tool for exploring different time ranges as Flame Graphs. (172 forks/2778 stargazers/Apache-2.0)
15:37:00 <mjg> > FlameScope begins by displaying the input data as an interactive subsecond-offset heat map. This shows patterns in the data. You can then select a time range to highlight on different patterns, and a flame graph will be generated just for that time range.
15:37:00 <mjg> 's what i'm talking about mate
15:38:00 <heat> that's cute
15:38:00 <mjg> you want cute here is an idea
15:38:00 <mjg> lock contention flamegraph
15:38:00 <heat> anyway the point is that you can set up the traces how you want them to
15:39:00 <mrvn> mjg: each lock burns hotter the more contention it has?
15:39:00 <heat> the native chrome trace format has support for stack frames attached to random events, etc
15:39:00 <heat> i've been prototyping some tracing stuff locally
15:39:00 <mjg> mrvn: the point is to have "stacktrace" of locks held as you contend on something
15:40:00 <mrvn> so you see where the lock request comes from?
15:40:00 <mjg> here is something which is answerable by "hand", and which could be sorted out by tooling
15:40:00 <mjg> say you took a lock
15:40:00 <mjg> and someone else is waiting for it
15:40:00 <mjg> but you do something expensive
15:40:00 <mjg> there should be an ez way to show what are you "really" waiting for, instead of just saying "the lock mate"
15:40:00 <mjg> in this case, it would show what the owner is doing
15:41:00 <mjg> as a continutation of the flame bar
15:41:00 <mjg> moreover, you could annotate that given thing is done with this or that lock held by having it appear as part of stacktrace
15:42:00 <mrvn> So you want the lock holders stack. That would be a problem for me because the lock holder is always another core and it might change page tables while you try to get the stack trace.
15:42:00 <heat> mjg, anyway I want a nice event timeline graph thing
15:42:00 <mrvn> ==> The current core has to map the stack stack of the other cores process to safely access the stack and that gets expensive.
15:42:00 <mjg> heat: looks like flamescope is the thing mate
15:42:00 <heat> particularly as a way to see how much time I'm spending under preempt-off/irqs-off
15:42:00 <mjg> heat: i have not used it yet though
15:42:00 <heat> no, this is the thing
15:43:00 <mjg> off cpu time profiling does not require specific progression tracing
15:43:00 <heat> https://docs.google.com/document/d/1CvAClvFfyA5R-PhYUmn5OOQtYMH4h6I0nSsKchNAySU/edit#heading=h.nso4gcezn7n1
15:43:00 <mjg> you can go the easy route and get a total count for the workload
15:43:00 <bslsk05> ​docs.google.com: Trace Event Format - Google Docs
15:43:00 <heat> you should take a look at this format
15:44:00 <heat> perfetto can load it and so can chrome://tracing
15:44:00 <mjg> i need the tstacktraces mate, it does not show them
15:44:00 <heat> it can do that, yes
15:45:00 <heat> in fact you can also literally just use this as a thing where you plop your function timings too, ez
15:45:00 <mjg> i'll look into it in the elusive foreeseable future
15:46:00 <mjg> meanwhile i got the slab alloc data from netflix with persmission to share
15:46:00 <heat> noiiiiiice
15:46:00 <heat> do show
15:47:00 <mjg> https://dpaste.com/3YLCWBPDF
15:47:00 <bslsk05> ​dpaste.com <no title>
15:47:00 <mjg> there is a debugging option which multiplies slabs for malloc
15:47:00 <mjg> and they did not turn it off
15:47:00 <heat> ok I can't read this
15:47:00 <mjg> by admission of the guy, he did not get around to it
15:47:00 <mjg> ops lost the header
15:47:00 <mjg> lemme repaste
15:48:00 <mjg> https://dpaste.com/F6MAQ88EZ
15:48:00 <bslsk05> ​dpaste.com <no title>
15:48:00 <mjg> the machine has up time of almost 11 days
15:51:00 <heat> i want a nice histogram mr mjg
15:51:00 <heat> ;_;
15:51:00 <mjg> then make one
15:51:00 <heat> seems like malloc-128 is the key slab here?
15:51:00 <mjg> hehe... he
15:51:00 <heat> yeah totally let me install microsoft excel first
15:52:00 <heat> i'll give you all sorts of pie charts after that
15:52:00 <mjg> you may want to awk first
15:52:00 <mjg> splice to one
16:10:00 <heat> i have no idea how to awk
16:11:00 <heat> awk is definitely a unix geezer utility
16:11:00 <mjg> OOH
16:11:00 <heat> it just is
16:11:00 <mjg> did you know dtrace was modelled after awk
16:11:00 <mjg> genz was a mistake
16:11:00 <heat> awk + vim is the one two UNIX HACKER punch
16:12:00 <heat> yes, I know the language is similar to awk
16:12:00 <mjg> you are the boomers of 2000s
16:17:00 <mjg> heat: i expect a power point presentation hre
16:38:00 <heat> mjg, either all tracing buffers are percpu and userspace knows it (and fetches each CPU's buffer) or I'll have a large global buffer and smaller percpu buffers that dump to the global one
16:38:00 <heat> I don't know which one is the best
16:48:00 <mrvn> heat: if you can pin tasks to cores the per core data is much more valuable.
16:48:00 <mjg> userspace should know about per-cpu because per-cpu may be of importance
16:48:00 <mjg> for example i got memset traces for each one
16:48:00 <mjg> which i can replay as they happened on the particular cpu
16:48:00 <mrvn> e.g. pin all proccesses away from a core except the one you want to trace
16:53:00 <heat> but if you tagged every tracing event with the cpu number wouldn't that have the same effect?
16:54:00 <zid> heat are you a full amd fanboi
16:54:00 <zid> can you give me any tips
16:54:00 <mjg> heat: you would *neeD* to do it, which adds to trace size
16:54:00 <mjg> as is you have this bit for fre
16:55:00 <mjg> i'm not saing it is a deal breaker, but i would totes go with full understanding, so to speak
16:55:00 <mjg> make the ulib + kernel compotent a tight dep and hide the split by default for example
16:56:00 <mjg> also note there is a funny problem trying to determine time ordering between events, if you need one
16:57:00 <mjg> perhaps a globally increasing (and serializing :X) id would do it
16:58:00 <heat> zid, i've never had amd hardware in my life, why
16:59:00 <heat> mjg, why is it hard?
16:59:00 <heat> doesn't the monotonic counter work here?
16:59:00 <mjg> it does work but it serializes
16:59:00 <mjg> no problemo on laptop scale
17:00:00 <mjg> oh you mean cycles counter?
17:00:00 <mjg> that still gives some ambiguity so to speak, but that would work for the most part
17:00:00 <heat> why does it serialize?
17:01:00 <heat> rdtscp does serialize the instruction stream but if you don't then I'm fairly sure you can't really have reliable timing there
17:01:00 <heat> like rdtsc alone doesn't work
17:01:00 <mjg> i meant a global counter serializes
17:02:00 <mjg> grabbing rdtscp would not, but you have problem with "ties"
17:02:00 <heat> do I?
17:02:00 <mjg> you can get literally the same value, which one is considered first then
17:02:00 <heat> CPU0 has an event at ts 10, CPU1 has an event at ts 10
17:02:00 <heat> both separate streams of data
17:03:00 <mjg> so if you were to linearize the entire thing, which one happened first
17:03:00 <heat> none
17:03:00 <heat> pick 1 randomly?
17:04:00 <mjg> defo not *randomly*
17:04:00 <heat> but is linearizing the whole thing useful anyway?
17:04:00 <mjg> you want reliable generation from the set
17:04:00 <mjg> sure it is, when you dn't care where someone was running, but what happened across the load
17:05:00 <mjg> for example there is this dtrace script to dump all execs
17:06:00 <heat> this is where I ask you what dtrace does
17:08:00 <heat> like, erm, if the nanosecond timestamp matches up exactly, how is order even relevant there?
17:08:00 <heat> events surely didn't influence each other
17:08:00 <mjg> you take the timestamp when you take the timestamp
17:08:00 <mjg> which is not strictly when the event at hand has happened
17:09:00 <mjg> as in there may be arbitrary delay
17:11:00 <mjg> so i don't know what dtrace is doing there
17:11:00 <mjg> note they had to work with sparc
17:11:00 <mjg> which likely influenced some of the internals
17:12:00 <heat> why is there arbitrary delay?
17:13:00 <heat> doing rdtsc, etc should be done with irqs off
17:14:00 <heat> like: "cli; rdtsc(); write_event(); restore_IF"
17:15:00 <heat> in this case even if you introduce a global counter it won't solve any issue. doing the atomic_fetch_add is still subject to jitter and stuff
17:15:00 <mjg> it is, but you get *some* ordering
17:15:00 <mjg> foo(); bar(); ..... report_that_we_got_here();
17:15:00 <mjg> after bar and before report_that_we_got_here you may get all sorts of shit
17:16:00 <mjg> similarly: report_that_we_got_here(); ... ; foo();
17:16:00 <mjg> there may be eons before you get to foo
17:16:00 <heat> yes
17:17:00 <heat> i understand the problem, but I'm not sure if it matters
17:17:00 <mjg> i'/m saying you want a reliable to way to agree with yourself what the order is
17:17:00 <mjg> even if it happens to be inacurrate in reality
17:17:00 <mjg> so in particular "random in case of a tie" is out
17:20:00 <heat> yes but that atomic_fetch_inc will only be done when writing the event right?
17:20:00 <heat> like, erm, at that point you're just subject to jitter for that right?
17:21:00 <heat> i genuinely can't tell if using a simpler criteria would be better (order by name in lexicographical order)
17:21:00 <mjg> whether you atomic add or cli(); ... or call a webservice, there is said arbitrary delay
17:21:00 <heat> cuz if the exact timestamp matches up, irqs off, and you're racing another CPU for a cache line, sounds like a crap shoot to me
17:22:00 <mjg> dude there may be literally millions of cycles before the event and getting the id/timetsamp/whatever the fuck
17:22:00 <heat> yes, I understand that
17:23:00 <heat> but getting the ID would be part of writing an event here
17:23:00 <mjg> so i'm sayin make sure you got some form of reliable ordering, pretending whatever identifier you got matches relative ordering to others
17:23:00 <mjg> burp
17:23:00 <mjg> look mate, just get something which works
17:23:00 <mjg> i think openbsd has a tracing framework :s
17:24:00 <mjg> they tried to kind-of reimplement dtrace from scratch i think
17:24:00 <heat> oh fuck yeah
17:25:00 <mjg> take a look at this mofer
17:25:00 <heat> my idea is still to add eBPF support and bpftrace my kernel
17:25:00 <mjg> sounds good
17:25:00 <mjg> dtrace -n 'fbt::memset:entry /arg2 > 256/ { @[arg0 & 0xf] = quantize(arg2); }'
17:26:00 <mjg> you get an equivalent operational and we call it even
17:26:00 <heat> but this is good for a generic trace gathering thing where I can also just insert random trace points and not worry with stupidly dynamic ebpf stuff
17:26:00 <heat> naw
17:26:00 <mjg> pft!
17:26:00 <mjg> i'm sticking to sortix then
17:26:00 <heat> you know that requires actual programmability
17:27:00 <mjg> for me that would be the fun part for this problem
17:27:00 <mjg> a dsl which works here
17:27:00 <heat> that would be fun yes, but at that point I would just add eBPF
17:27:00 <mjg> interesting bit: in dtrace they intentionally did not include loops to provably *always* finish probe execution
17:27:00 <heat> and if I add an eBPF interpreter, I'll also write an x86_64 eBPF jitter
17:28:00 <heat> note that I already have the cBPF equivalent but eBPF seems like a good bit of work
17:29:00 <mjg> uh?
17:29:00 <mjg> interestin
17:29:00 <mjg> port dtrace, a weekend project at most!
17:29:00 <heat> no
17:29:00 <mjg> trust me, i used it over the weekend
17:29:00 <mjg> maybe geeksforgeeks have a tracing framwork you can use
17:29:00 <mjg> that's the memmove dudez
17:30:00 <heat> i'm very well aware of what geeksforgeeks is
17:30:00 <heat> it's like w3schools
17:30:00 <mjg> i mostly was not :X
17:30:00 <mjg> are they related to tutorialspoint?
17:30:00 <mjg> i knew that one
17:30:00 <heat> oh yeah thats also a thing
17:31:00 <mjg> back when i used to post on stackoverfow, a victim asked about a problem and ilnked to tutorialspoint
17:31:00 <mjg> i responded saying how crap the site is
17:31:00 <mjg> and giving a better resource
17:31:00 <heat> a victim hahaha
17:31:00 <mjg> SOtwats gave me shit for doing it
17:32:00 <heat> also i don't know if you missed this shit: https://github.com/heatd/Onyx/blob/89e4d0e81e543cbd6c9a3978f546feddf8840e7f/kernel/kernel/spinlock.c
17:32:00 <bslsk05> ​github.com: Onyx/spinlock.c at 89e4d0e81e543cbd6c9a3978f546feddf8840e7f · heatd/Onyx · GitHub
17:32:00 <mjg> apparntely you either answer the question or stfu, opinions like the above are offtopic
17:32:00 <mjg> fucking idiots
17:32:00 <heat> vintage Onyx spinlocks
17:32:00 <heat> spinlock_t * lock omg omg the *
17:32:00 <mjg> wait that does not even work?
17:32:00 <heat> it's broken yes
17:33:00 <mjg> you can submit to tutorialspoint
17:33:00 <mjg> the bug aside, if (lock->lock == 1) -> while (lock->lock == 1) is primo stuff
17:33:00 <heat> if (lock == 1) { spin_and_yield(); } test_and_set();
17:34:00 <mrvn> mjg: opinions are expressed by down votes
17:34:00 <sham1> 👎
17:34:00 <sham1> Now that's a down vote
17:36:00 <mjg> SO, openbsd, netbsd and solaris are part of the stuff i no longer look at
17:36:00 <mjg> life's better
17:36:00 <heat> https://github.com/heatd/Onyx/blob/4bcc27fe7eae67fc473bf7a2ab94a749d962c60c/kernel/arch/x86_64/spinlock.S#L3 2017 is where I really started to get the hang of this osdev thing
17:36:00 <bslsk05> ​github.com: Onyx/spinlock.S at 4bcc27fe7eae67fc473bf7a2ab94a749d962c60c · heatd/Onyx · GitHub
17:37:00 <heat> 2015 and 2016 were just a crapshoot
17:37:00 <mjg> you *start* with pause?
17:37:00 <mjg> ffs man
17:37:00 <heat> PESSIMAL
17:37:00 <mjg> i think i had seen this anti-pattern before
17:37:00 <mjg> have you copied this from somewhere?
17:37:00 <heat> i don't think so
17:38:00 <mjg> xchg to unlock is also great
17:38:00 <mjg> ye ok mjg@
17:38:00 <heat> it's not good but it does the job innit
17:39:00 <mjg> the old unix maxim, innit
17:39:00 <mjg> "ultimately gives you the correct result so who gives af"
17:51:00 <mrvn> heat: do you really need the frame pointer?
17:54:00 <kof123> "intentionally did not include loops to provably *always* finish probe" <dispatches from another channel> wasm apparently says tail call stuff must use some limited resource that eventually exhausts, else people would depend on a platform that did not do this (at least how i read it)...
17:55:00 <mrvn> kof123: what platform uses up resources on a tail call? That's just a goto
17:55:00 <kof123> i dunno, long ago i remember a teacher talking about it, some compilers can do it, some ancient ones couldn't
17:55:00 <heat> bpf has historically been unable to jump backwards
17:56:00 <mrvn> kof123: sure. if your compiler does not do tail calls then you don't get tail calls.
17:56:00 <mrvn> kof123: That's a compiler feature, not a language feature.
17:56:00 <heat> i think current eBPF can, given it provably returns. not 100% sure though
17:56:00 <kof123> dont disagree, just the comment made me think of that
17:57:00 <mrvn> wasn't eBPF using llvm?
17:58:00 <kof123> for me you'd probe at run-time, or a constant, or whatever. "duck"-ish
17:58:00 <kof123> i mean, there is a point where i say "assume the developer has a clue"
17:58:00 <kof123> rather than try to dictate every little thing
18:02:00 <mjg> for some like kernel-side tracing with user-supplied prog it is a reliability issue
18:02:00 <mjg> here user == root
18:03:00 <mjg> invalid memory accesses are already caught
18:03:00 <mjg> instead of assuming the user clearly would not make a mistake
18:04:00 <kof123> certainly, i see the use of such things depending on the situation
18:05:00 <heat> mjg, security issue too
18:06:00 <heat> you can submit BPF programs as !root, you can also submit BPF programs as root on secure boot/locked down kernels
18:15:00 * kof123 .oO( unstable radioactive duck glowing different colors, there's surely a comic there )
18:17:00 <mrvn> Supermans Rubber-Ducky better not be made with Kryptonite.
18:22:00 <heat> gog
18:23:00 <sham1> How can it Kryptonite if it is rubber?
18:23:00 <mrvn> sham1: you think rubber-duckies are 100% rubber?
18:24:00 <sham1> Well the non-air portions, I'd hope to be rubber. Otherwise it's false advertising
18:24:00 <gog> heat
18:24:00 <mrvn> sham1: and what color does rubber have?
18:24:00 <heat> hi
18:25:00 <sham1> Oh so you'd put Kryptonite in the colours? Well that's douchy
18:25:00 <mrvn> how else do you get green, red and black?
18:27:00 <sham1> Probably by using something that isn't Kryptonite
18:28:00 <mrvn> https://illgetdrivethru.com/2022/07/29/what-are-the-different-types-of-kryptonite/
18:28:00 <bslsk05> ​illgetdrivethru.com: What are the different types of kryptonite? | I'll Get Drive-Thru
18:29:00 <gog> hi
18:35:00 <Ermine> hi gog
18:35:00 <gog> hi
18:35:00 <Ermine> may I pet you
18:35:00 <gog> yes
18:35:00 * Ermine pets gog
18:36:00 * gog pr
18:36:00 <heat> gog pull request
18:36:00 <gog> decline
18:36:00 <heat> heat has requested changes
18:36:00 <gog> decline
18:36:00 <Ermine> alias gog=git
18:37:00 <heat> gog push
18:37:00 <sham1> Oh my
19:00:00 <heat> mjg, what stops the CPU from detecting a e.g 4 64-bit load+store and doing it as a 32-byte one?
19:02:00 <mrvn> a 4 64-bit load+store?
19:08:00 <heat> yes, 4 64-bit load+stores
19:08:00 <heat> so 32 bytes in 8 byte chunk
19:08:00 <heat> chunks
19:12:00 <sortie> <mjg> i'm sticking to sortix then
19:12:00 <sortie> The safe choice, I applaud
19:12:00 <sortie> heat, you self-hosting yet?
19:12:00 <heat> no
19:13:00 <sortie> Such a shame
19:13:00 <heat> i'm busy bikeshedding sortie, leave me alone!
19:13:00 <sortie> What color u want teh man pagez
19:13:00 <mrvn> heat: and you think the CPU will do 8 32-bit load+stores?
19:13:00 <heat> yellow and pink
19:14:00 <heat> if it looks good, please do tell, so we can change that
19:14:00 <mrvn> oh wait, never mind. I read 32-byte as 32-bit.
19:15:00 <mrvn> I'm not sure what prevents that on x86/x86_64 but on ARM you specify that in the cache attributes. Write back, no write combine, etc.
19:18:00 <mrvn> I got my power adaptor and SSD today and now wanted to start playing with my Rock 5B. Now I notice that 1) I don't have an USB-C / USB-C cable and 2) neither the Rock 5B nor SSD came with the screw you need to hold it in the M2.key slot.
19:18:00 <mrvn> *schnief*
19:27:00 <mjg> heat: instruction contract, if you will
19:27:00 <mjg> heat: aligned 8 byte stores are guaranteed atomic
19:27:00 <mjg> heat: same goes for loads
19:28:00 <mrvn> mjg: combining them to 32-byte would still be atomic
19:28:00 <mjg> wait i misread, wtf is that question
19:28:00 <mjg> 32 *BYTE*?
19:28:00 <heat> yes
19:29:00 <heat> like the CPU would notice a 32-byte copy as a bunch of 8-byte ones and combine it all into a 32-byte op
19:29:00 <mrvn> Not sure how you get 32 byte. I assume that's some SSE256 operation.
19:29:00 <mjg> he mans the 4 * movsq loop i presume
19:29:00 <heat> yep
19:29:00 <mjg> for a case like that, i don't think anything prevents it
19:30:00 <mjg> but i don't know if any cpus do it like that either
19:30:00 <mrvn> Does it even matter? It will be combvined into a cacheline.
19:31:00 <heat> it would be a cheap win I think
19:31:00 <heat> AVX-but-without-AVX-and-rep-movsb
19:31:00 <mjg> i know enough about cpus to know that there are no clear wins mante
19:31:00 <mjg> when it comes to wtf is going on in the internals
19:32:00 <mjg> in fact i know enough to know i don't understand almost any of it
19:32:00 <heat> i wonder if there are limitations in the insn pipeline such that this is not practical
19:32:00 <mjg> a big wig from intel once said that cpu internally executes shit in an inherently random manner
19:32:00 <mjg> but people expect reliable results from it
19:33:00 <mjg> on that note you would think 'rep mov' et al would be a clear cut win
19:33:00 <heat> yeah
19:33:00 <mjg> you tell the cpu what you want to do, it can optimize however it is best
19:33:00 <heat> apparently not
19:33:00 <mjg> right
19:33:00 <heat> cpus are weird man
19:33:00 <nortti> isn't it optimized pretty well (some startup overhead, but quick copying speeds) on more recent core i?
19:34:00 <mjg> nortti: somewhat, but no
19:34:00 * heat holds mjg back
19:34:00 * CompanionCube waves at nortti
19:34:00 <mjg> tl;dr handrolling ops are not going anywhere anytime soon
19:34:00 <mjg> fsrm or not
19:35:00 <heat> moderately-recentish rep movsb is fast-ish at higher speeds but it still has weird limitations, like on my kabylake where it seems to use SSE2 stores internally
19:35:00 <heat> and is slow as molasses for small sizes
19:35:00 <heat> i think FSRM reduced the turtle-speed sizes to < 64 but I don't have hw to test that on
19:36:00 <mjg> here is homework for you heat: check pre-erms routines in various kernels
19:36:00 <heat> (FSRM being an even more recent optimization)
19:36:00 <mjg> it is all rep {m,s}tosq -> rep {m,s}tosb
19:36:00 <mjg> the back to back rep is so atrocious it is not even funny
19:36:00 <heat> my favourite instruction is rep mtosq
19:37:00 <heat> i mean, linux seems/'d to have a good handrolled manual loop originally
19:38:00 <mrvn> heat: maybe some cpu will see the 4 movq and fuse them into a single uops.
19:38:00 <mjg> no opinion
19:38:00 <mjg> they did move away from it
19:38:00 <mjg> so
19:38:00 <heat> yes because haha erms good
19:38:00 <heat> kneejerk reactions to intel claims
19:39:00 <mjg> er... molasses speed
19:39:00 <mjg> fun fuct is that intel claims rep stos + 4096 buf size + page-alignment rolls with some internal speed up
19:40:00 <mjg> i failed to measure any though
19:40:00 <heat> should do a tlb shootdown :v
19:41:00 <mrvn> mjg: any slowdown if you rep stos 4095 bytes?
19:41:00 <mjg> no idea, never tried
19:42:00 <mrvn> then what did you compare it to?
19:42:00 <mjg> rep stosq
19:42:00 <mjg> that above was b
19:43:00 <mrvn> you sure they ment stosb and not stos* in general?
19:43:00 <mjg> yes, it was one of the benfits of erms
19:43:00 <mjg> and intel even migrated linux clear_page to use it
19:44:00 <mjg> now you could assume stosq "translates" to erms internally if cpu supports the bit, but then see above
19:45:00 <mjg> it's all weird shit where basic ideas how things work fail
20:07:00 <moon-child> I wonder if it would be reasonable to have the dram hardware support page zeroing directly
20:08:00 <mrvn> moon-child: and if the ram is interleaved and you only want to zero half a page?
20:09:00 <mrvn> FYI: the hardware that does this kind of thing is called DMA engine.
20:30:00 <mjg> moon-child: except most of the time you ant the zeroed page to stay in cache, if already there
20:30:00 <mjg> so that would be an addition
20:31:00 <mrvn> mjg: the cache could have a "zero page" operation too
20:31:00 <moon-child> ideally you would just rename the cache lines
20:31:00 <mjg> so as i said ram thing would be an addition
20:31:00 <moon-child> azul cpus did this per allocation. But whole page at a time is more iffy
20:31:00 <mjg> to the core operation
20:32:00 <mjg> preferably the semantics would be: tell ram to zero, whatever lines from that page are in cache, zero them too. fuck the rest.
20:32:00 <mjg> as don't evict any of these lines, but don't bring in new lines either
20:33:00 <moon-child> if everything (or almost everything) is in cache, then you wouldn't want to bother telling the memory anything
20:33:00 <mrvn> I was about to suggest it bring in new lines if it doesn't have to evict anything. But when would that ever happen?
20:33:00 <mjg> sure
20:34:00 <mrvn> moon-child: telling the ram to zero a page in a single bus transaction would be better than having the cache write back 4k zeroes
20:34:00 <moon-child> that's why I said 'IF everything (or almost everything) is in cache'
20:34:00 <mrvn> You tell the ram to zero the page and the cache to zero out any cache entries present and mark them as not-dirty.
20:35:00 <mrvn> The alternative would be to evict any cache entries and later read back zeroes. That would be wasteful.
20:36:00 <moon-child> if there's only one cache line not in cache, you're better off just telling the ram to zero that one cache line, since otherwise it would waste a bunch of work zeroing the rest of the page
20:36:00 <mrvn> moon-child: haeh? You still have to zero the ram anyway
20:36:00 <moon-child> yes but, like mjg said, the thing that are already in cache you want to keep there
20:36:00 <moon-child> since you're goign to use them
20:36:00 <mrvn> but you don't want to have to write them back to ram
20:36:00 <moon-child> and most likely write something other than zeroes
20:37:00 <moon-child> before you flush them again
20:37:00 <moon-child> the contents of the cache are different from the contents of memory. when something is in cache, the version of it that is in cache is the canonical version, and the version in main memory may be stale. That's how memory works
20:38:00 <mrvn> and my way would have both cache and ram in sync.
20:38:00 <heat> wasn't there a cache line zeroing insn on arm64?
20:38:00 <moon-child> mrvn: yes and there's literally no reason to do that
20:38:00 <moon-child> it's wasted work
20:39:00 <mjg> heat: amd has one (clzero) but it is using nt stores
20:39:00 <mrvn> moon-child: there is every reason for it. You can not leave the old contents in the cache. So the choice is to evict the cache line or zero it. And if you don't tell the ram about it then the cache has to mark the cache line as dirty and eventually writes it back. Then you have gained nothing over just writing zeroes to the page.
20:39:00 <mjg> so it's liek, cool story bro
20:40:00 <moon-child> mrvn: yes you did
20:40:00 <moon-child> you zero the page
20:40:00 <moon-child> then you hand the page to the user
20:40:00 <moon-child> the user writes some stuff which is not zero to the page
20:40:00 <moon-child> all this without touching main memory, ever
20:40:00 <moon-child> then finally it gets evicted, writing out to memory the user's new data
20:40:00 <moon-child> not zeroes
20:40:00 <mrvn> moon-child: maybe he does, maybe he doesn't. That's later.
20:40:00 <moon-child> but you bet that he does, because that's faster in practice than betting he doesn't
20:41:00 <mrvn> moon-child: and you lost nothing by having the ram cleared the page and the cache entries marked clean.
20:41:00 <moon-child> yes you did
20:41:00 <moon-child> because the ram has to do extra work
20:42:00 <mrvn> yes, draw the zero-page line high on the page for one cycle. Big deal.
20:42:00 <mrvn> That's as much work as writing out one cache line.
20:44:00 <gog> hi
20:46:00 <heat> mjg, if amd got something completely new in ryzen it's probably because there's an arm64 equivalent
20:46:00 <heat> https://developer.arm.com/documentation/ddi0595/2021-03/AArch64-Instructions/DC-ZVA--Data-Cache-Zero-by-VA
20:46:00 <bslsk05> ​developer.arm.com: Documentation – Arm Developer
20:46:00 <heat> there it is
20:47:00 <mrvn> moon-child: One use case for this would be mmap, paging in filesystem data. So a security conciencus kernel would zero the page before telling the FS to read data into it so no information leaks. Keeping the zeroes only in cache would mean having to write them all out.
20:50:00 <mrvn> Actually my dream operation would be: zero page in ram, evict cache lines and shootdown the TLB (across all cores).
20:51:00 <mrvn> unmap(page) in hardware
20:52:00 <moon-child> nah I want lazy shootdowns
20:52:00 <mrvn> what makes it lazy?
20:53:00 <moon-child> for standard posix munmap, you have to actually munmap right away, since acceses that happen after have to fault
20:53:00 <moon-child> but for most applications you don't actually need this
20:54:00 <moon-child> so better is if you can let each core release the page when it feels like it
20:54:00 <mrvn> does it? isn't access after munmap simply UB?
20:54:00 <heat> i've thought about that for a good bit
20:54:00 <heat> doesn't work, huge security hole
20:54:00 <moon-child> if you're lucky, memory pressure is low, and all the cores release the page before you need it again
20:55:00 <moon-child> otherwise, you do the shootdown later when you need to reallocate the physical page
20:55:00 <heat> it would *in theory* work in a system with root and nothing else
20:55:00 <heat> oh, yeah, that's not my idea
20:55:00 <moon-child> heat: how so? I mean, I guess it makes some categories of use after free ever so slightly worse, but doesn't seem like a huge deal?--oh, ok :)
20:56:00 <heat> my idea would be to do lazy TLB shootdown such that munmap doesn't TLB shootdown but rather mark it as "MAY USE, BUT SHOOTDOWN FIRST"
20:56:00 <mrvn> moon-child: I could live with munmap needing an msync() before SEGV is guaranteed.
20:56:00 <heat> and then when you first get the chance to accidentally shoot it down (in a cr3 switch, etc), you ""shoot"" all those down in a batch
20:56:00 <moon-child> mrvn: well the other thing is
20:57:00 <heat> but locally only.
20:57:00 <moon-child> this would integrate naturally with a mechanism like io_uring
20:57:00 <moon-child> which is already async
20:57:00 <heat> so in theory there would be no need for a shootdown ever, but this doesn't work since even if you restrict it to root, it's a security hole in systems where root isn't all-powerful (Windows, anything with secure boot/lockdown)
20:57:00 <moon-child> ideally, if buffer size tuning is right, a program can go its whole life w/o waiting for mmap or munmap
20:58:00 <mrvn> moon-child: you could also reuse pages for the same process without unmapping.
20:58:00 <moon-child> yes! Was just about to mention that
20:58:00 <moon-child> can also skip zeroing, though you would need a new mmap flag to ask for it
20:58:00 <heat> there's a flag to skip zeroing in mmap
20:58:00 <heat> linux one at least
20:58:00 <mjg> heat: btw ppc also has a 'zero a ton of mem' instruction
20:59:00 <heat> it will just tell you to fuck off on systems without the CONFIG_BLAHBLAH_INSECURE or whatever they called it
20:59:00 <heat> mjg, ppc best arch
20:59:00 <mjg> itanium does not? HEHE
20:59:00 <moon-child> heat: hmmm looks a bit different though?
21:00:00 <mjg> skip zeroing in mmap?
21:00:00 <mjg> ll
21:00:00 <moon-child> manpage says 'because of the security implications', so presumably it doesn't do it only if it's your memory
21:00:00 <mjg> not only that's not secure, but software actively rleies on it being 0
21:00:00 <heat> MAP_UNINITIALIZED "Don't clear anonymous pages."
21:00:00 <mrvn> moon-child: I see in the manpage "The munmap() system call deletes the mappings for the specified address range, and causes further references to addresses within the range to generate invalid memory references." but where in POSIX does it say that access to unmapped memory generates an invalid memory reference at all?
21:00:00 <mjg> has to be some pretty serious corner case
21:00:00 <mjg> curious how that came to e
21:00:00 <mjg> then again, linux claims to run on systems without mmu
21:00:00 <heat> embedded
21:01:00 <mjg> that much i figured, but what exactluy
21:01:00 <heat> moon-child, what is "your memory"?
21:01:00 <moon-child> most of the time it's not actually useful to rely on its being 0. Usually you malloc something and then initialise it
21:01:00 <moon-child> heat: memory that your process recently unmapped
21:01:00 <mjg> jemalloc depends on it
21:01:00 <heat> well, yes, linux does not have that
21:01:00 <mjg> and glibc uses it optimize calloc
21:01:00 <heat> if you did add it, you already have a flag
21:02:00 <moon-child> mjg: sure, but proposal is if application asked to skip init, and was designed to work with that instead, you might go faster
21:02:00 <mrvn> malloc should use MAP_UNINITIALIZED while calloc should not (when allocating large blocks where you mmap directly)
21:02:00 <heat> and tbf adding this seems like a locking nightmare to me
21:03:00 <heat> hmm, maybe not so much
21:03:00 <heat> i guess it's a similar-ish operation to OOM-kill
21:08:00 <mjg> moon-child: not saying no
21:09:00 <mjg> maybe geeksforgeeks has a good page zeroing scheme
21:10:00 <mjg> for example it could start with memcmp over the entier thing, maybe it is already zero?
21:10:00 <mjg> for (i = 0; i < PAGE_SIZE; i++) if (page[i] != 0 /* fix that byte! */ page[i] = 0; }
21:10:00 <mjg> avoids dirtying lines which were already zero!
21:11:00 <mjg> maybe i should submit over there
21:16:00 <kof123> im pretty sure they would int i = 0; that's insecure to use something already declared
21:16:00 <kof123> encapsulation, ppl
21:19:00 <kof123> i? surely index or Index, it'll never pass the strict quality control standards
21:34:00 <kof123> *inDex if you want to climb the ladder quickly
21:42:00 <heat> INT mIndex = 0; mIndex < gPageSize; mIndex += 1
21:42:00 <heat> mjg, that's SMP-optimized memset
21:42:00 <heat> lgtm
21:45:00 <mjg> jokes aside
21:45:00 <mjg> it would make sense to add a debug option to pagezero
21:45:00 <mjg> to check if perhaps the page is already zeroed
21:45:00 <mjg> there may be a lol caller which for example gets a page guaranteed zeroed
21:46:00 <mjg> and then zeroes it again on its own
21:51:00 <heat> mjg, how good is dflybsd's smp performance?
21:51:00 <mjg> no
21:52:00 <heat> thank you
21:53:00 <heat> on a rando hn post: "DragonFlyBSD is slowly but steadily becoming more attractive as a Linux/FreeBSD alternative. 4.6 has good support for various newer Intel GPUs, hammer is stable and the SMP and Networking performance is stellar."
21:53:00 <mjg> to dfly credit, *some* stuff scales ok
21:53:00 <mjg> but most of the claim to fame is a 2012 benchmark
21:54:00 <heat> this was in 2016
21:54:00 <mjg> when people claim it scales, they reference the 2012 bench
21:55:00 <mjg> what dfly is doing better than freebsd is pmap
21:55:00 <mjg> and nullfs-equivalent
21:55:00 <mjg> past that i think it is all worse, markedly so at times
21:56:00 <mjg> https://people.freebsd.org/~mjg/freebsd-dragonflybsd-netbsd-v3.txt
21:56:00 <mjg> the shit i mostly worked on -- path lookup -- is way better on free
21:56:00 <mjg> and as noted some other times it even used to beat linux, until a recent change
21:57:00 <heat> why is there no openbsd in that comparison dear freebsd developer matthew garrett
21:57:00 <heat> are you hiding something
21:58:00 <mjg> i think i tried
21:58:00 <mjg> it was hitting the wall pretty hard
21:58:00 <mjg> their syscall handling used to have a scalability problem
21:59:00 <mjg> they had a global call counter
21:59:00 <mjg> :p
21:59:00 <mjg> to give you a glimpse
22:00:00 <heat> when you do you write your own OS for a performance showdown with me
22:01:00 <mjg> beat dfly and i'll think about it
22:01:00 <mjg> let's pick a bench
22:01:00 <heat> i think I can beat netbsd on most metrics except usefulness
22:01:00 <mjg> L]
22:01:00 <mjg> do you have any means of getting a machine to boot onyx on more than your laptop
22:02:00 <heat> probably boots on cloud but I really haven't tried
22:02:00 <heat> and should depend on the cloud provider
22:02:00 <mjg> you could use tmpfs to avoid any virtio problems
22:02:00 <heat> I can totally do GCP rn BUT I have no disk yet (no virtio scsi support)
22:03:00 <heat> I know amazon has weird amazon-specific devices I don't have docs to except the typical linux driver
22:05:00 <mrvn> heat: I have the fastest booting OS. The functionality is somewhat limited to saying "Hello World" but who cares? :)
22:12:00 <mjg> here is a very serious comment
22:13:00 <mjg> today i would not recommend anyone uses freebsd without a good reason
22:13:00 <mjg> not that there are many takers
22:13:00 <mjg> on that note, dragonfly is in ever worse position
22:13:00 <heat> have you told whoever's paying your bills that
22:14:00 <mjg> what if they have a good reason
22:14:00 <mjg> to use it :X
22:14:00 <heat> sounds like "we can't bother to upstream changes and/or do GPLv2 evasion"
22:14:00 <mjg> no
22:15:00 <mjg> majority is upstramed
22:15:00 <heat> actually modules can be proprietary so I ran out of good reasons
22:15:00 <mjg> and in fact any new work goes is encouraged to go usptream first
22:15:00 <mjg> erm
22:15:00 <mjg> s/goes//
22:15:00 <mjg> hell, the main product now tracks the dev branch
22:16:00 <mjg> so ye, plenty of reason
22:16:00 <mjg> but the point was, dawg, when people make comments about non-linux systems, they are bullshitting most likely
22:16:00 <mjg> put it in the same bucket as people romanticizing templeos
22:16:00 <heat> I romanticize FreeBSD and NetBSD as well
22:16:00 <mjg> at best, in certain corner cases, you are not actively behind
22:16:00 <heat> they are venerable, undermanned systems
22:17:00 <heat> no comment about the other one
22:17:00 <mjg> well i literally just now wrote a patch for freebsd vm
22:17:00 <mjg> and fuck me, how retarded that code is is beyond me
22:17:00 <heat> and truth be told my experience with FreeBSD has been positive
22:18:00 <mjg> here is a statement for you
22:18:00 <heat> except the fucking sysctl code, my man that is horrible
22:18:00 <mjg> anytime you meet someone who is hardcore on $system-of-choice
22:18:00 <mjg> they will have a story how $popular-alternative did now work for shit
22:18:00 <mjg> they switeched to $system-of-choice and it's been a smooth ride ever since
22:19:00 <mjg> both $system-of-choice *and* $popular-alternative could have been any of: free/net/openbsd, random linux distros
22:19:00 <heat> i'm hardcore on windows
22:19:00 <mjg> this is for < 2010
22:19:00 <mjg> i literally got people telling me a linxu router could not stay up
22:20:00 <mjg> they put openbsd in there
22:20:00 <mjg> et voila
22:20:00 <heat> have you ever struggled to install a controller's driver for 2 hours? yes? you're using linux
22:20:00 <mjg> worked like a charm
22:20:00 <heat> boot up windoze, connect the controller, open your game, have fun
22:20:00 <mjg> interestingly these stories are probably mostly true, but they ignore the later realities
22:20:00 <mjg> that the thing which probably worked great initially eventually also started crashing/whatevr
22:22:00 <heat> how old are you
22:22:00 <heat> you're either 79 or 30
22:22:00 * moon-child uses freebsd desktop
22:22:00 <mjg> 37
22:22:00 <mjg> moon-child: lol @ you mate
22:22:00 <moon-child> :<
22:22:00 <mjg> tbh i probably would if i did not need wifi
22:23:00 <mjg> and suspend
22:23:00 <mjg> :)
22:23:00 <moon-child> largely just works; some annoyances, but linux also pulled some fuckery
22:23:00 <mjg> right
22:23:00 <kof123> i used netbsd on a laptop for a long time because it was the only of the 3 i hadnt used before
22:23:00 <kof123> im not saying there was anything behind that decision
22:23:00 <mjg> moon-child: perhaps you would be interested in fixing automemcpy in llvm
22:23:00 <moon-child> desktop not laptop. I think my old laptop ran freebsd and wifi at least was ok, idk though. Current laptop is macbook
22:23:00 <heat> IF I DID NOT NEED NORMAL COMPUTER FUNCTIONALITY THAT HUMAN BEINGS NEED, I WOULD BE USING FREEBSD
22:23:00 <kof123> open had pf, but that got ported
22:23:00 <mjg> moon-child: and benching some code
22:23:00 <mjg> moon-child: to finally get a sensible simd memcpy for libc?
22:23:00 <heat> but eh freebsd path walking is fuckin mint lads
22:24:00 <mjg> kof123: that's liek 2005 news? :)
22:24:00 <mjg> kof123: what year was it
22:24:00 <kof123> :D
22:24:00 <mjg> heat: which one dwag. the *locked* code is pretty... not pretty
22:24:00 <moon-child> mjg: hmm maybe
22:24:00 <moon-child> ifunc somewhat sexier
22:24:00 <moon-child> can avx512 then
22:24:00 <mjg> who says no ifunc
22:24:00 <kof123> im just saying some of us are just .......when choosing the lesser evil, choose the one i havent tried before
22:24:00 <heat> freebsd has ifunc right?
22:24:00 <mjg> it does
22:24:00 <nortti> < mjg> tbh i probably would if i did not need wifi < mjg> and suspend ← my main computer around 2015 was an eeepc 701 running freebsd. recently booted it up again and realized I had no cpufreq on there lol
22:24:00 <heat> well there you have it
22:24:00 <moon-child> oh, it does? I thought it didn't
22:24:00 <mjg> moon-child: toes ifunc, but what to put in the ifunc
22:25:00 <mjg> nortti: solid
22:25:00 <nortti> (though unsure if that was just me not having enabled something I needed to enable)
22:25:00 <moon-child> oh GNU_IFUNC hits in rtld
22:25:00 <mjg> ifunc is actively used in rtld
22:25:00 <mjg> it's almost all there mate
22:25:00 <mjg> you find a good memcpy to use, i'll fix the missing bits
22:26:00 <mjg> the thing to do is to make sure pre-ifunc-resoultion code does not hang
22:26:00 <mjg> add rtld_memcpy_early et al to use instead
22:26:00 <mjg> which would use a "plain" variant
22:26:00 * moon-child nods
22:26:00 <mjg> really, the real work here is to get a defensible memcpy
22:27:00 <heat> freebsd ending up using llvm-libc's stringops would be the most lol moment ever
22:28:00 <heat> the UNIX oldies would have a stroke @ seeing C++ in libc
22:28:00 <mjg> why
22:28:00 <mjg> fair
22:28:00 <heat> it's also a complete bullocks roullette
22:28:00 <heat> will it generate good code? who knows?
22:28:00 <heat> if it doesn't, just patch the compiler like normal people do
22:28:00 <moon-child> isn't freebsd still using c89 mainly?
22:28:00 <mjg> heat: i totes don't want that state
22:28:00 <moon-child> can't decl where you want
22:28:00 <mjg> what i would want is to experiment, find the right routine
22:29:00 <mjg> and then ship the asm as found there
22:29:00 <mjg> moon-child: c99-ish in kernel, userspace is a hugely mixed bag
22:30:00 <mjg> and to be clear, while technically memcpys at generated in automemcpy may happen to contain the best overall variant
22:30:00 <mjg> they *lack* important cases
22:30:00 <moon-child> oh btw, the avx512 thing is kinda rubbish
22:30:00 <mjg> it probably is
22:30:00 <mjg> i think they focused on sizes < 128
22:30:00 <mjg> anything past that seems yolo'ed
22:31:00 <mjg> they have a jump table(!) for 1-3 which i'm confident is pessimal
22:31:00 <moon-child> if you do a full-width 512-bit op, it takes a few 100k cycles to warm up the 512-bit register file, during which time everything is emulated with 128-bit ops. And then on older hardware it clocks down
22:31:00 <moon-child> you can still get a speedup from avx512 with 128-bit ops
22:32:00 <moon-child> don't want to use the full-width ops for strings functions because it slows everybody down if the userspace app isn't otherwise using them
22:32:00 <mjg> i would say just avx2
22:32:00 <heat> "during which time everything is emulated with 128-bit ops. " LOL
22:32:00 <moon-child> but what would be nice is if you could use the 512-bit ops and tell it to emulate with 128-bit ops but _not_ spin up the 512-bit thing if it isn't already
22:32:00 <mjg> really, for a full setup, i woudl expect a win over sse2 first and foremost
22:32:00 <moon-child> as you still save on dispatch that way
22:32:00 <moon-child> mjg: avx2 same thing
22:32:00 <mjg> for the sizes < 256 or so
22:33:00 <mjg> really? that's super shit
22:33:00 <mjg> curious what's glibc is doing in that ase
22:33:00 <heat> avx2 same thing?
22:33:00 <moon-child> I think avx2 doesn't clock down
22:33:00 <moon-child> but it does take a while to spin up the register file
22:33:00 <heat> mjg, what case?
22:33:00 <mjg> look mate, if you get automemcpy operational, get some real memcpys to test
22:33:00 <moon-child> I think glibc just yolos it with wide vectors
22:33:00 <mjg> i can plug them int oa real workload and we will see
22:34:00 <mjg> but first i need candiates which at least look good in a bench
22:35:00 <mjg> so really, are you up to it or not
22:35:00 <sortie> $ curl -s --head https://sortix.org/ | grep -Ei 'server:'
22:35:00 <sortie> server: nginx/1.23.3 (Sortix)
22:35:00 <bslsk05> ​sortix.org: The Sortix Operating System
22:35:00 <sortie> ^^ I migrated the website to running natively on nginx :)
22:35:00 <heat> sortie, HEY SIR WHATS YOUR MEMCPY LIKE
22:35:00 <moon-child> meh probably not
22:35:00 <moon-child> tbh
22:35:00 <mjg> moon-child: :p fucker
22:35:00 <moon-child> I'm spreading myself rather thin lately
22:35:00 <mjg> same problem mate
22:36:00 <heat> WHAT? ITS JUST A CHAR* FOR LOOP?
22:36:00 <moon-child> :)
22:36:00 <mjg> that's my page zeor!
22:36:00 <nortti> heat: huh I thought it did 64-bit if stuff was aligned
22:36:00 <heat> oh wow
22:36:00 <heat> what is this
22:37:00 <moon-child> 64-bit it doesn't even matter if you're aligned or not
22:37:00 <heat> it's doing very funny type punning
22:37:00 <mrvn> The Rock 5B is a bigLITTLE cpu (RK3588 - 4x Cortex-A76 + 4x Corctex-A55). Is it normal they have the exact same features and bogomips? https://paste.debian.net/1273307/
22:37:00 <bslsk05> ​paste.debian.net: debian Pastezone
22:37:00 <sortie> heat: BYTES GO BRRR
22:37:00 <mjg> heat: URL
22:37:00 <heat> https://gitlab.com/sortix/sortix/-/blob/master/libc/string/memcpy.c
22:38:00 <bslsk05> ​gitlab.com: libc/string/memcpy.c · master · sortix / Sortix · GitLab
22:38:00 <sortie> My memcpy does try to do nice aligned copies :)
22:38:00 <heat> sortie, there's a may_alias attribute that does skip that
22:38:00 <sortie> What do you mean? may_alias?
22:38:00 <moon-child> 'Abort on overlapping memcpy' nice
22:38:00 <mjg> sortie: you can name your main routine "memcpy_slow"
22:38:00 <heat> yes, may_alias tells the compiler that you're type punning with that
22:40:00 <klange> sortie: SMP|aarch64|some-other-thing-I-have-because-my-priorities-are-different when?
22:40:00 <moon-child> sortie: aligned vs unaligned doesn't really matter for 8 bytes thingies
22:40:00 <moon-child> you're better off skipping the dispatch
22:40:00 <heat> mjg, reminder that you're not bantering me this time around
22:40:00 <heat> sortie, but that's UB
22:41:00 <heat> erm, moon-child*
22:41:00 <mjg> real q: can you write real-world libc without UB?
22:41:00 <moon-child> heat: it's also ub if they are aligned
22:41:00 <heat> atm I don't think so
22:41:00 <moon-child> just more ub if misaligned
22:41:00 <heat> moon-child, not with may_alias
22:42:00 <mrvn> What was the command under linux to output the device tree?
22:42:00 <mjg> lspci -v?
22:42:00 <mjg> or so
22:43:00 <mrvn> mjg: not pci, the device tree: proc/device-tree/ in usable.
22:43:00 <mjg> oh, sorry
22:43:00 <heat> sortie, actually I really think you're hitting UB in memcpy
22:43:00 <sortie> heat, mjg, moon-child: Yeah my memcpy is just meant to be well defined and not unreasonably slow. I have put in almost no effort in optimizing it.
22:44:00 <heat> your union type punning isn't really working here
22:44:00 <brunothedev> hey guys, for a generic gpu driver, what should i do? I don't want to implement a text-only mode driver, and i want a generic driver that works on every i686/x64 machine, should i implement a VGA driver or there is alternative?
22:44:00 <sortie> Yeah I think I later learned unions aren't actually defined like that (fuck you C)
22:44:00 <klange> There is no such thing as a generic GPU driver, and you will not write a GPU driver.
22:44:00 <heat> sortie, as it stands you're just doing type punning on the pointer and not the contents
22:45:00 <klange> This is a pedantic point, but a GPU is a very specific kind of device and should not be confused with a display controller.
22:45:00 <nortti> brunothedev: if you want modesetting, you're going to need to have card-specific drivers. depending on how you're booting your bootloader (or UEFI) may be able to arrange a framebuffer for you though
22:45:00 * sortie . o O (I can use memcpy to do the type prunin--- wait)
22:45:00 <sortie> klange: 1.2 :)
22:45:00 <klange> sortie: when's 1.1?
22:45:00 <heat> sortie, if you slap __attribute__((may_alias)) on your pointers it should be well defined
22:46:00 <sortie> klange: I'm finishing up 1.1, like, for real, it's happening, legit, tell your friends
22:46:00 <brunothedev> oh okay, just something that i can draw pixels at the screen to write something like the linux framebuffer console, any names, wiki pages, docs etc
22:46:00 <heat> but ofc a GNU C thing yadda yadda
22:46:00 <sortie> heat, oh neat, file an issue? Or send a MR?
22:46:00 <klange> sortie: i hear sortie's finishing up sortix 1.1!
22:46:00 <heat> i'll file an issue
22:46:00 <klange> sorry you may be my only friend
22:46:00 <sortie> klange: HE WHAT
22:46:00 <klange> here at least
22:46:00 <sortie> heat, sick burn
22:46:00 <sortie> klange is my friend too
22:47:00 <sortie> klange, unclear about the exact 1.1 timeline but maybe hoping for something late spring or early summer at this rate
22:47:00 <sortie> klange, I literally have just merged my network stack and ssh. Officially. Crazy, I know. Took 7 years.
22:48:00 <mjg> do you have smp yet?
22:48:00 <sortie> mjg, just spawn two Sortix VMs and load balance :D
22:48:00 <mjg> is that cloud multiprocessing?
22:48:00 <sortie> It sure is
22:49:00 <klange> ah but i have 24 cores, so I'll need to run 24 VMs
22:49:00 <sortie> klange, oh right, I do also have that GUI prototype of mine that I gotta make a little more functional, that also count as as a some-other-thing-I-have-because-my-priorities-are-different
22:50:00 <sortie> Probably will include that in 1.1
22:50:00 <sortie> Other Sortix news: The official Sortix nightly releases will also be built on Sortix every night as of tonight.
22:51:00 <mjg> o/
22:51:00 <sortie> That's possible now that I merged my ssh port
22:51:00 <mjg> how many oses go to fully slef-hosting stage?
22:51:00 <mjg> you joined the rank of templeos mate
22:51:00 <brunothedev> sortie: lol is it unix-like?
22:51:00 <klange> probably quite a few more that don't use gcc or llvm
22:52:00 <sortie> Fun fact operating systems like GNU/Hurd, Minix, Haiku, etc. don't self-host their websites last I checked
22:52:00 <mjg> fun fact: openbsd did not at some point either
22:52:00 <mjg> :)
22:52:00 <sortie> brunothedev, yeah, per sortix.org (running on a Sortix server) “Sortix is a small self-hosting operating-system aiming to be a clean and modern POSIX implementation.“
22:52:00 <sortie> OpenBSD is pretty good at self-hosting their infra these days tho
22:54:00 <brunothedev> sortie: i wanna to achieve a similar result too
22:54:00 <mjg> sortie: no idea, i would expect that
22:54:00 <mjg> the problem was way back in the day
22:55:00 <heat> sortie, it's GNU <space> Hurd
22:55:00 <klange> I updated my historic screenshot album with some new stuff. https://gist.github.com/klange/f427a551af5f2f8b3c9ef80687883fcf
22:55:00 <bslsk05> ​gist.github.com: 12 Years of ToaruOS · GitHub
22:55:00 <heat> it's a GNU project mr sortie
22:55:00 <heat> also, can it be considered an operating system?
22:56:00 <klange> GNU/HURD is the OS, GNU HURD is just a kernel ;)
22:56:00 <brunothedev> hurd is just the kernel
22:56:00 <heat> no, GNU is the OS, GNU hurd is the """kernel"""
22:56:00 <nortti> I think the platform triplet for it is i386-gnu, even
22:56:00 <heat> yep
22:56:00 <mjg> no, hurd is the shit
22:56:00 <sortie> Considering GNU is meant to be an operating system, THEY FORGOT TO BE AN OPERATING SYSTEM
22:56:00 <brunothedev> just call it gnu
22:56:00 <sortie> AND GNU.ORG IS DEFINITELY NOT RUNNING ON THE REAL GNU HURD OPERATING SYSTEM
22:56:00 <sortie> shame on them
22:56:00 <mjg> EEY
22:57:00 <mjg> does rms even visit gnu.org
22:57:00 <heat> who visits gnu.org?
22:57:00 <heat> I know I haven't
22:57:00 <sortie> THE BIG AND PROFESSIONAL SORTIX OPERATING SYSTEM OUTDOES THE HOBBY GNU+LINUX OS
22:57:00 <heat> ever
22:57:00 <sortie> heat, all the good shit goes down at ftp.gnu.org everyone knows that
22:58:00 <brunothedev> Average gnu/hurd fan vs. Average Sortix enjoyer
22:58:00 <sortie> klange, I love your screenshot collection
22:59:00 <sortie> brunothedev, if you're new to hobby OSes, do check out klange's toaru also. Super impressive work and very inspiring :)
22:59:00 <heat> if you're new to hobby OSes do check out FreeBSD
23:00:00 <sortie> Hey yeah FreeBSD is a nice thing to also check out if one only has tried Linux
23:00:00 <heat> yeah for some definition of nice
23:00:00 <sortie> Like for real, checking out various other ways of doing things is very inspiring
23:00:00 <mjg> the relentless bullying on this channel
23:00:00 <sortie> I am inspired a lot by Linux in my osdev
23:00:00 <heat> it's like a pilgrimage. really makes you appreciate linux
23:00:00 <brunothedev> heat: i would probaply tests some BSDs, but 2 problems: 1. NVIDIA 2. Wayland
23:00:00 <sortie> When Linux makes me sad I make Sortix better
23:00:00 <mjg> :)
23:01:00 <heat> not even BSD devs test BSD, don't worry
23:01:00 <heat> it's just a fake system everyone pretends to use
23:01:00 <brunothedev> heat: FreeBSD
23:01:00 <brunothedev> it seems tha OpenBSD test their os tho
23:01:00 <sortie> FreeBSD is really just macOS developers
23:01:00 <mjg> you got it backwards mate
23:01:00 <heat> shit, could be PayMeToUseItBSD
23:01:00 <brunothedev> sortie: imagine if linus taked the offer to work on macos
23:01:00 <mjg> it is macos users developing freebsd
23:02:00 <mjg> you go to a bsd confrence, you get mac gallore
23:02:00 <sortie> Yeah that's what I meant
23:02:00 <heat> if you go to a Linux convention you get a pentium4 thinkpad gallore
23:02:00 <sortie> I don't think anyone really managed to compile Sortix for real on a mac
23:03:00 <mjg> brah my first laptop was a thinkpad t30
23:03:00 <sortie> Certainly not with ports
23:03:00 <mjg> best thing ever
23:03:00 <nortti> I used a pentium III thinkpad (t20) without a screen like 10 years ago (before the eeepc)
23:03:00 <sortie> mjg, I actually made Sortix-on-Sortix the primary and official way to do it and cross-dev secondary (but well supported)
23:03:00 <sortie> nortti!
23:03:00 <brunothedev> my next gpu wont be nvidia, i cannot even run alpine because they dont compile their drivers against musl
23:03:00 <sortie> :9
23:03:00 <sortie> :)
23:03:00 <nortti> pretty good other than slowness and lack of ram, which, are pretty important
23:03:00 <heat> mjg, exactly, linux people use thinkpads
23:03:00 <brunothedev> sortie: llvm backend?
23:04:00 <sortie> brunothedev, nah modified gcc per https://wiki.osdev.org/OS_Specific_Toolchain
23:04:00 <bslsk05> ​wiki.osdev.org: OS Specific Toolchain - OSDev Wiki
23:04:00 <heat> mjg, fwiw i'm pretty sad you run Ubuntu and not RHEL
23:04:00 <heat> you're definitely a RHEL kind of guy
23:04:00 <brunothedev> want to talk about not running their own os? Have you heard of Plan9 forks?
23:04:00 <sortie> Technically all the Sortix devs use debian
23:05:00 <sortie> heat, what do you run normally btw?
23:05:00 <heat> arch
23:05:00 <heat> 2 out of 3 dentistssortix devs run debian
23:05:00 <brunothedev> sortie: tried debian, too much random bugs
23:05:00 <klange> I honestly do more dev under macOS now...
23:06:00 <sortie> brunothedev, it has stabilized for me now although last year had some annoying bugs
23:06:00 <heat> you should try fedora
23:06:00 <heat> seriously
23:06:00 <heat> good distro
23:06:00 <nortti> klange: can you use docker under macos, or is there another way to build toaru?
23:06:00 <sortie> Personally I just use debian to get a default experience that's good enough so I don't have to worry and tinker
23:06:00 <brunothedev> heat: wanna know what distro i am running ;)
23:06:00 <heat> not particularly but feel free to share
23:07:00 <brunothedev> if i ever get a amd gpu, i will distrohop to alpine linux
23:07:00 <klange> nortti: I have a native toolchain
23:07:00 <heat> sortie, thing is that I've experimentally verified that the farther you are from HEAD, the buggier it is
23:07:00 <sortie> heat, debian?
23:07:00 <heat> any distro
23:08:00 <sortie> I do run debian testing
23:08:00 <heat> which is why I tend to run bleeding edge only
23:08:00 <brunothedev> heat: lol i am running fedora too
23:08:00 <nortti> honestly what gentoo does with masking seems to be a pretty good approach
23:08:00 <heat> does work pretty well. my workflow has only been broken for a bit a few months back with a linux 6.1 bug
23:09:00 <sortie> I have like zero interest in maintaining a Linux distro just to make things work, when I wanna spend that energy maintaining my Sortix distribution
23:09:00 <mjg> :]
23:09:00 <heat> yeah?
23:09:00 <mjg> fwiw ubuntu works for me almost without a hitch
23:09:00 <heat> i don't do any maintaining here
23:09:00 <brunothedev> anyone have a simple, vga driver in C so i can read, it seems that there are no code on the osdev wiki
23:10:00 <heat> funnily enough the most maintaining I've done on linux systems has been in fucking debian derivatives
23:10:00 <mjg> brunothedev: how much a driver do you want to see
23:10:00 <mjg> as in are you trying to get letters on screen?
23:10:00 <sortie> I got an old desktop with like 8 GB RAM and it OOMs pretty much all the time which Linux is absolutely terrible at and everyone involved should be very ashamed of themselves
23:10:00 <mjg> if so, i have good news
23:10:00 <moon-child> haha
23:10:00 <heat> sortie, works well here
23:10:00 <mjg> sortie: i thought G recently merged some improvements
23:11:00 <mjg> heat: it works like shit on my lap
23:11:00 <sortie> At least the Linux kernel improved a bit or the systemd config did, and Firefox also now supports unloads, now it's just VLC leaking massive amounts of memory
23:11:00 <brunothedev> mjg: literally anything, i can bootstrap a way to make characters and create a console
23:11:00 <heat> yes, new MGLRU stuff
23:11:00 <nortti> sortie: tbh you are running an unsupported setup with no swap
23:11:00 <heat> there you go
23:11:00 <mjg> brunothedev: you just write bytes to a dedicated area and it magicallyshows up
23:11:00 <mjg> brunothedev: i'm sure this is described
23:11:00 <mjg> brunothedev: alternatively just google for a hello world kernel
23:11:00 <sortie> Everyone involved which swap should also be very ashamed of themselves
23:11:00 <heat> sortie, I've found that swapping works pretty well
23:12:00 <sortie> It's super slow on this harddisk and I **never want to swap**. I just want firefox to go nope when I oom and that's it
23:12:00 <heat> hi sortie did you know a corporation on which you have a considerable stock position does a lot of swap work
23:12:00 <brunothedev> mjg: most hello world kernels use text mode i think, i want to draw normally
23:12:00 * sortie . o O (stock swaps)
23:12:00 <heat> sortie, btw what's "nope" here? ENOMEM?
23:12:00 <klange> brunothedev: Are you writing your own bootloader?
23:12:00 <nortti> sortie: the weird thing is that I also run noswap debian unstable with firefoc on 8 gigs and the only time I've had it livelock was with webgl
23:12:00 <sortie> heat, just kill the damn firefox process
23:13:00 <brunothedev> klange: nope
23:13:00 <sortie> Or vlc
23:13:00 <sortie> Or whatever is fucking up
23:13:00 <klange> brunothedev: What bootloader are you using?
23:13:00 <sortie> Just don't blast radius everything else or livelock
23:13:00 <heat> sortie, OOM killer should do that AFAIK
23:13:00 <brunothedev> klange: gonna use grub
23:13:00 <heat> if you've got something big its OOM score will be high
23:13:00 <klange> brunothedev: Tell grub to set up a framebuffer.
23:13:00 <sortie> heat, I know all that, I'm saying, it works poorly. It worked very, very badly. It got better.
23:13:00 <heat> sure
23:14:00 <nortti> heat: if you lack swap, it ends up evicting currently hot code and then loading it off (in sortie's case, spinning rust) disk for a good while before it invokes oom killer
23:14:00 <heat> nortti, yes, because that's better usually
23:14:00 <nortti> aye
23:14:00 <nortti> just saying that sortie is not seeing oom killer trigger even
23:14:00 <heat> and no, should not be "hot code" AFAIK
23:14:00 <heat> AIUI it targets unused page cache stuff
23:14:00 <brunothedev> klange: would that make me denpendant on grub?
23:15:00 <sortie> The problem is reloading off the disk all the time behavior slows performance so much that it never makes any forward progress (perhaps because it's not keeping up) and the system livelocks
23:15:00 <nortti> heat: I've had the entire system lock up for 10 minutes while stuff fills up enough for oom-killer to launch. if that's not evicting hot code I don't know what's going on
23:15:00 <heat> right
23:15:00 <heat> that does sound like swapping out the wrong stuff
23:15:00 <klange> brunothedev: are you using multiboot to load from grub?
23:15:00 <brunothedev> klange: yes
23:16:00 <klange> brunothedev: you're already dependent on grub, then
23:16:00 <heat> i know there are cgroup workarounds for that stuff
23:17:00 <brunothedev> klange: it seems that the specification is offered by grub
23:17:00 <brunothedev> specification != implementation
23:17:00 <nortti> you are unlikely to use any other multiboot bootloader than grub
23:17:00 <klange> 1) Use a preconfigured framebuffer from your boot environment. In grub this means setting "set gfxpayload=keep" (if grub was already running in a graphics mode, otherwise "set gfxpayload=WIDTHxHEIGHTxBPP" how you want it) and getting the framebuffer info from the multiboot data.
23:18:00 <brunothedev> nortti: oh ok
23:18:00 <klange> 2) When you have that working, then write a modesetting driver for the Bochs virtual display adapter implemented by Bochs, QEMU, and VirtualBox.
23:18:00 <klange> 3) Once that's working, write one for VMware's slightly different thing.
23:19:00 <klange> 4) Stop. Any actual graphics hardware beyond this point will take you exponentially longer to write drivers for than the entire rest of your OS.
23:19:00 <heat> nortti, actually multiboot1 is wide-*ish*ly implemented
23:19:00 <klange> heat: there's only one other implementation of multiboot1 in an actual bootloader, and it's an incomplete one in a PXE loader
23:19:00 <heat> syslinux
23:19:00 <nortti> right but do you really want to ship your hobby os with extlinux?
23:19:00 <heat> also qemu
23:20:00 <klange> qemu isn't a bootloader, and also its implementation is horrendously incomplete
23:20:00 <klange> The most complete multiboot1 implementation outside of grub is probably _mine_.
23:20:00 <heat> also implementing a virtio gpu driver is not impossible and probably a decent idea
23:20:00 <heat> at least the modesetting bits are trivial
23:22:00 <brunothedev> gonna try vesa
23:22:00 <heat> no
23:22:00 <heat> use fucking grub
23:23:00 <nortti> brunothedev: you do not want to drop down to real mode and keep around the environment to allow that. your bootloader (= grub) will handle talking with vesa for you
23:23:00 <nortti> also I don't think if you uefi boot you can even use vesa, or can you?
23:23:00 <heat> no you can't
23:24:00 <klange> Absolutely do not do VESA unless you're writing your own bootloader.
23:24:00 <netbsduser> klange: limine also has complete multiboot1 and multiboot2 implementations
23:24:00 <klange> Still? I thought they removed them.
23:24:00 <klange> I think they also called everyone use them idiots, but that might have been a random passerby.
23:25:00 <mrvn> What's mising in qemus multiboot?
23:25:00 <klange> All the graphics stuff.
23:26:00 <brunothedev> soooooo "kernel/drivers/generic/grubfb"?
23:26:00 <netbsduser> it would be slightly unusual to target them if using Limine since there is a protocol which puts you immediately into long mode with a reasonable state, but they're certainly there
23:26:00 <nortti> what's limine?
23:27:00 <netbsduser> nortti: a bootloader which i favour
23:27:00 <mrvn> nortti: a bootloader that already went through 3 new boot protocols because the previous one they designed wasn't good enough.
23:27:00 <nortti> ah
23:27:00 <klange> limine does more than most people's operating systems
23:27:00 <klange> why even bother getting into the hobby at that point
23:28:00 <netbsduser> i thought grub was the one that did that
23:28:00 <netbsduser> i don't even have a zfs driver smh
23:28:00 <klange> grub barely even puts you into a working protected mode
23:28:00 <netbsduser> i count that a weakness
23:29:00 <heat> grub is huge, EFI is huge
23:29:00 <heat> they're all huge
23:29:00 <heat> but limine sucks
23:29:00 <klange> grub itself does a lot, but grub doesn't expose any of that to you
23:29:00 <heat> from that other guy's struggles with the boot protocol I did understand that it's remotely insane
23:29:00 <netbsduser> wrangling with the legacies of x86 is not osdev, it's cbt, and i don't mean cognitive behavioural therapy
23:29:00 <heat> lol
23:30:00 <heat> seriously man, it's not that hard
23:30:00 <heat> and it is part of osdev
23:31:00 <heat> the GDT is all described in the SDM and if you have a decent-ish grasp of segmentation you'll get it pretty quickly, the MMU you'll need to grok sooner or later, then you just toggle a few bits in some registers and there you go, 64-bit
23:31:00 <netbsduser> it's a part that exists only because of the long legacy amd64 sprang from, and a part i am happy to forget about
23:32:00 <brunothedev> lets just think about programming with proprietary ARM and device trees for a moment...
23:32:00 <klange> Grub does do too much, but we accepted it because you were going to have it installed anyway to boot Linux.
23:32:00 <brunothedev> grand unified has to mean something eh?
23:33:00 <heat> yes, the "grand" bit really does make sense
23:34:00 <mrvn> heat: truthfully that other guys problems had nothing to do with limine.
23:35:00 <netbsduser> the thinker guy, or whatever he was called?
23:35:00 <mrvn> brunothedev: yeah, lets talk about the device tree. How do I dump it to a file under linux?
23:35:00 <klange> With grub, I can tell people "just use grub until you get things working, then when you feel comfortable you can write your own bootloader" but with Limine it's like... guess you're screwed unless you want to spend a year replicating that functionality!
23:36:00 <mrvn> klange: what functionality? Other than long mode what does it do more than grub?
23:37:00 <brunothedev> bootloaders are bloat, store the kernel at 512 KiB /s
23:38:00 <nortti> brunothedev: https://github.com/shikhin/wodscipe
23:38:00 <bslsk05> ​shikhin/wodscipe - A bootable 512-byte insane IDE. (0 forks/16 stargazers/Unlicense)
23:38:00 <mrvn> brunothedev: 0x4000 for an Rock 5B
23:38:00 <netbsduser> well, there's the exact thing, i have no interest in writing bootloaders (multiboot struck the first blow against that necessity, grub gave the coup de grace, and limine does similarly for the amd64 age)
23:39:00 <mrvn> netbsduser: multiboot should really just add AMD64 as architecture.
23:39:00 <netbsduser> mrvn: yes, they are missing a trick there
23:40:00 <netbsduser> apparently multiboot does support MIPS of all things
23:40:00 <klange> mrvn: it does SMP bringup and has runtime services
23:40:00 <heat> netbsduser, yep the tinker guy
23:40:00 <heat> or thinker or whatever
23:40:00 <klange> Limine has more runtime services than EFI!
23:40:00 <heat> ewwwwwww
23:40:00 <mrvn> klange: oh, haven't seen them yet.
23:40:00 <netbsduser> the only runtime service i know of is the early boot console
23:41:00 <netbsduser> that and the SMP bringup assistant at a push of 'runtime service' definition
23:42:00 <mrvn> SMP bringup is actually something multiboot should have too. It would be really bad to support AMD64 but then for SMP you have to add 16 bit and 32 bit code yourself.
23:42:00 <heat> that's not a push, it's very much a runtime service
23:42:00 <heat> I don't want a runtime assistant for basic OS operation
23:43:00 <heat> not only do you deal with EFI bugs but now you have to deal with amateur bootloader dev bugs? hard skip
23:43:00 <netbsduser> limine deals with the efi bugs instead, which is nice
23:44:00 <netbsduser> they are more accountable than mobo manufacturers as far as bugs go as well
23:44:00 <brunothedev> how to get multiboot_tag_framebuffer, there is no info on the wiki, it seems to be about the multiboot header, on which i set it up on assembly
23:44:00 <klange> brunothedev: Are you using multiboot1 or multiboot2?
23:45:00 <heat> read the spec
23:45:00 <heat> netbsduser, how tf do they deal with the efi bugs?
23:45:00 <heat> that's either impossible or a completely overreach
23:45:00 <heat> complete*
23:46:00 <brunothedev> klange: i used the bare bones page as a reference
23:46:00 <netbsduser> in the sense that those which are relevant to booting should now be worked around by limine, rather than yourself
23:46:00 <klange> What barebones page?
23:46:00 <brunothedev> klange: the c one
23:46:00 <klange> What C one?
23:47:00 <klange> There are _three_ on the osdev wiki.
23:47:00 <heat> netbsduser, yes but how about *everything else*
23:47:00 <heat> and it's a very small bootloader too
23:47:00 <brunothedev> klange: https://wiki.osdev.org/Bare_Bones
23:47:00 <bslsk05> ​wiki.osdev.org: Bare Bones - OSDev Wiki
23:47:00 <heat> grub is much larger and still has hit multiple problems that cause real regressions in upstream EFI
23:48:00 <klange> brunothedev: That uses multiboot1. There are no "tags". The framebuffer information is at the bottom of the header, and you set one bit flag (0x4) to request it.
23:50:00 <klange> Also that barebones guide is missing most of the multiboot request header...
23:52:00 <brunothedev> klange: can i replace the assembly multiboot header with a c multiboot2 header as seen on the multiboot wiki page without much problem?
23:53:00 <heat> no
23:53:00 <klange> No, they are completely unrelated.
23:53:00 <klange> multiboot2 uses different commands in grub.
23:54:00 <klange> You probably _should_ use multiboot2, but there aren't as many example implementations floating around...
23:54:00 <cooligans> brunothedev: don't use multiboot1
23:54:00 <klange> I actually support both: https://github.com/klange/toaruos/blob/master/kernel/arch/x86_64/bootstrap.S#L22-L108
23:54:00 <bslsk05> ​github.com: toaruos/bootstrap.S at master · klange/toaruos · GitHub
23:54:00 <cooligans> I'd rather use the Linux proto rather than multiboot1
23:55:00 <cooligans> that's actually not a bad idea tbh
23:55:00 <heat> naw
23:55:00 <heat> the linux fucking boot protocol?
23:55:00 <cooligans> yes
23:55:00 <cooligans> Linux boot proto > multiboot1
23:55:00 <klange> The Linux boot protocol is not stable and Linux expects things to fuck it up and essentially reboots itself.
23:55:00 <heat> would rather have edward scissor-hands give me a backrub
23:55:00 <cooligans> how is it not stable
23:55:00 <cooligans> it runs on my computer, and it proably runs on yours too
23:55:00 <klange> I would rather pretend I didn't say any of the things I said for the last hour and tell people to use Limine.
23:55:00 <heat> haha
23:56:00 <klange> cooligans: It _changes_ with different kernels.
23:56:00 <klange> It is not a stable _protocol_.
23:56:00 <heat> that's not true klange
23:56:00 <cooligans> well yeah, limine proto beats all, im not that ignorant
23:56:00 <cooligans> the changes are minor
23:56:00 <heat> the linux boot protocol changes, as in "expands"
23:56:00 <cooligans> yeah
23:56:00 <cooligans> but it's backwards compatitble
23:56:00 <heat> but it's still backwards compatible to most relatively-recent bootloaders
23:56:00 <cooligans> yep
23:57:00 <brunothedev> found this: https://github.com/cloudblaze/multiboot2
23:57:00 <heat> probably not fucking 1998 LILO but oh well
23:57:00 <bslsk05> ​cloudblaze/multiboot2 - multiboot2规范的示例代码 (0 forks/1 stargazers/GPL-3.0)
23:59:00 <heat> that said, reverse engineering it is probably depressing
23:59:00 <heat> so if I really wanted to I would just take some inspiration from fuchsia, which already did a good bit of that work