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=osdev&y=19&m=8&d=8
00:00:05 <ybyourmom> Evokes memories of CMake
00:00:19 <ybyourmom> Simple as long as you're doing standard C-like things
00:00:25 <zid> nice for normal C is make
00:00:27 <ybyourmom> As soon as you're not, it's really ugly
00:00:28 <zid> which is already installed and super easy
05:15:36 <ybyourmom> Learned about eventfds today
05:15:44 <ybyourmom> such a useful little feature I had no idea about
05:40:41 <ybyourmom> TFW I want to walk out of the office early, but I've only been here for like 6 weeks
05:40:51 <ybyourmom> Is it too early to walk out early
05:41:08 <ybyourmom> Literally unable to focus on anything right now lol
05:41:16 <adu> yourmom: just do it
05:41:23 <Matt|home> . may i have your job.?
05:41:45 <ybyourmom> u can have a job here, but u can't have *my* job D:<
05:41:58 <ybyourmom> imagine, this dude tryn to take my jerb right in front of me
05:43:19 <adu> I don't show up 4 days a week
05:44:13 <ybyourmom> That's me 6 months in after I've made it clear I'm useful and they wouldn't fire me for "working from home" multiple times a week
05:44:39 <adu> correction, the entire company rents office space 1 day a week
05:45:07 <ybyourmom> it's not as cool if you're not actually rebelling lol
05:45:20 <adu> the first way sounded cooler
06:02:54 <ybyourmom> K, one hour until work is over -- it's safe to walk out now I think
06:03:10 <ybyourmom> I'll try to leave without looking too conspicuous
06:55:31 <leelotungal> realworldtech says much about cayman arch, 16wide SIMD each is 4-5 alus, register file is partitioned as 16 1K entries for 128-bit vector. It means you execute stuff in async on for example 16rows, and communicate on inter-SIMD either with PV or shared registers (compute only are last) Some port restrictions apply for inter-alubundle though which come from the isa docs
06:56:32 <leelotungal> all i was saying was that indeed vliw is somewhat superior arch
06:57:01 <leelotungal> but i haven't got many of those chips available my own
07:10:02 <aalm> .theo
07:10:02 <glenda> Nope.
07:16:56 <leelotungal> 4096/4=16 regs for each bundle then
07:23:41 <leelotungal> I am not going to argue about this, vliws come with more resources for computation, and are superior on short-pipeline mode, they offer more parallelization on compression like offered
07:25:22 <klange> <leelotungal> four wheel drive abortion leftover
07:25:32 <klange> Charming fellow.
07:26:29 <Mutabah> Especially when kicked
07:27:00 <Mutabah> That said, quite original insults
07:27:31 <klange> Almost tempted to just pipe him to a file and see what he spits out over time.
07:28:09 <j`ey> anx then markov chain it
07:30:43 <zid> schizoprenia is basically a markov chain
07:32:50 <aalm> paranoid powers made him google for me so he found some irrelevant #linux-<soc-vendor> channel last time to come and reveal our invasion plans. :|
07:33:22 <zid> aalm: I still blame you, for not personally invading estonia
07:34:12 <klange> It's just so far away...
07:34:19 <zid> closer to finland than it is to either of us
07:34:37 <zid> klange: is your pimpwagon ready yet?
07:34:48 <klange> My pimpwagon doesn't arrive until next month.
07:35:44 <zid> sad, make sure you get pics with you draped over the front when it arrives
07:36:00 <aalm> what is it?
07:36:08 <klange> just a civic
07:36:18 <zid> It's a special civic
07:44:25 <zid> I'm probably too excited for someone else's car to arrive
08:11:38 <snowball> so... how is everyone?
08:15:54 <klange> Someone has gone off on a tangent in my issue reports about a non-implementation of access(2)
08:16:09 <klange> They started from a segfault because an app wasn't checking its arguments
08:17:39 <zid> heh
08:17:51 <zid> not sure I've ever used access
08:17:59 <zid> should I google for man access
08:18:17 <klange> it's like a stat without any of the features
08:18:25 <klange> just "can i frob this file with this mode"
08:20:07 <zid> sounds like it's tocttou as hell
08:20:29 <klange> totes
08:20:39 <zid> useful for like, a coloured `ls` that showed you if you *could* cat it or whatever
08:20:45 <zid> but pretty useless in actual programs
08:20:49 <zid> just see if open fails
08:20:56 <klange> I gave it enough for "does this file exist" which is all anything seems to have wanted it for
11:02:06 <iosys> is there anyone know any network/channel for virtualization? or the questions can go here?
11:39:26 <geist> well, you can try
11:39:38 <geist> though in general we're more about bare metal os and kernel development here
11:51:29 <_mjg> real osdev is done on bare metal
11:53:38 <geist> well, bare metal as in on real or virtualized hardware, but not on top of any other software stack
11:54:00 <geist> some folks talk about VMX or whatnot occasionally, and i think someone is working on a type 1 hypervisor somewhere
11:56:08 <_mjg> no, no. real osdev is always done on bare metal. everyone knows.
11:56:32 <_mjg> any form of virtualisation is for people who are too chicken to really test
11:56:57 <j`ey> is happy to be a chicken
11:57:51 <iosys> ok dont fight kids :P
12:01:49 <_mjg> j`ey: don't tell your parents
12:15:01 <geist> _mjg: now now be nice
12:15:31 <geist> we support both kinds of osdev here: floppy bootloader and real mode hello world
12:25:34 <Nuclear_> hahahaha
12:51:07 <bytefire> hi, on ARMv8, if we have software running in non-secure EL1 and EL0 with MMU enabled, and then we initialise stage 2 MMU in EL2, will that break EL1? assume that stage 2 MMU opens everything to EL1, just to eliminate stage 2 faults
13:04:14 <geist> the stage 2 EL2's mmu may also translate EL1, that's the stacking effect
13:04:37 <geist> note there are two mmu page table trees in EL2. one for EL2 software, and the other for EL1 and below to be translated
13:04:54 <geist> so you can for example run your el2 software without the mmu on if you want, but have a per guest translation
13:05:14 <bytefire> geist: yes, true. let's say stage 2 MMU identity maps IPA to PA
13:05:16 <geist> or have EL2 translated like any other kernel with a EL1 translation somewhat like a process
13:05:39 <geist> you can do that, though if you're just identity mapping then that's not a good use of the mmu
13:05:55 <geist> but yes, if you have a stacked mmu then when EL1 is running it'll translate through bothlayers
13:06:10 <bytefire> geist: so the question is if we slip in a stage 2 mmu, after stage 1 mmu has been set up and running, will that cause problems?
13:06:24 <bytefire> geist: i see
13:06:30 <bytefire> sorry didn't see your last message
13:06:49 <geist> nope, aside from if you mess around with the el2 mmu such that el1 gets its 'physical address space' that it thought it was running in moved out of the way
13:07:04 <bytefire> got it
13:07:12 <bytefire> thanks very much
13:07:26 <geist> it's a pretty elegant design, not a lot of funny business
13:07:42 <bytefire> i agree!
13:07:45 <geist> the only real downside is the double mmu translation is not free, but it's the price you pay for that sort of thing
13:07:58 <geist> if you use larger pages in EL2 it mitigates the TLB pressure a bit though
13:08:13 <bytefire> yes
13:09:11 <geist> it's unimplementation defined how the TLB translations work for 2 stage translation but from looking at existing cores they basically just toss both sets of TLB entries into the L2 tlbs, with a bit saying if it's stage1 or stage2
13:09:24 <geist> L1 TLB entries seem to generally be 'combined'
13:10:14 <geist> so they're a wider tag, but they single translate from {vmid, asid, virtual} to physical
13:11:26 <bytefire> i see, didn't know that
13:11:53 <geist> it doesn't really matter, but it's nice to know how it works under the hood somtimes
13:12:01 <geist> at least when trying to optimize for the way hardware works
13:12:41 <bytefire> sure :)
13:12:55 <bytefire> geist: you've worked on armv8 cores?
13:13:52 <geist> yah all the time
13:17:22 <j`ey> Im wondering if I should try build my kernel in position dependent for now. I tried to add some __bss_start = .; to my linkerscript, but then the linker complained about putting relocations in my read-only .text, and that I should re-compile with fPIC
13:17:32 <j`ey> but I thought I already had some equivalent of that enabled :/
13:18:22 <geist> j`ey: nah, dont, it's more complicated than you think
13:18:54 <j`ey> but then I will have to write something to apply the relocations?
13:18:57 <geist> you can't really make it truly position independent, PIC compiling (with C/C++) mostly just mitigates the number of runtime relocations and/or clusters them to one spot for efficiency purposes
13:19:07 <geist> no. dont make it virtually relocatable for now
13:19:25 <geist> worry about that later
13:19:39 <geist> that can come in a few years, if ever
13:21:01 <j`ey> Ok, so youre saying that you only need to apply the relocations if you want it to be virtually relocatable. is virtually relocatable different from making it run from the high half?
13:21:11 <geist> yes
13:21:44 <j`ey> Ok
13:21:54 <geist> as in you can pick the location to run it in (high half or not), compile it non relocatable, then as long as you have a piece of early code (generally written in assembly) that maps it to the virtual address, enables the mmu, bounces to it, then you're dont
13:21:58 <geist> same as x86
13:22:12 <j`ey> I still didn't figure out why Im getting the ELR0x0 thing, trying to think of things to try
13:22:15 <geist> key is if you do the early code in asm you can specifically write it to be position independent by being careful
13:22:31 <geist> because you're faulting on something and you never set the exception vectors
13:22:52 <j`ey> maybe I can try set the vectors then, see if that helps
13:22:52 <geist> the default exception vector table is at 0, so when you fault becaus eyou did something wrong it's branching into garbage (stuff at 0)
13:22:55 <bytefire> geist: that's great. hope to learn a lot from you :)
13:22:56 <geist> and then probably double faulting
13:23:15 <geist> easy to figure out if you just run with -d int and look at the *first* exception
13:23:17 <j`ey> geist: I dont get why qemu wouldnt print out the first exceotion!
13:23:28 <j`ey> that is the first one it prints out
13:23:30 <geist> with -d int?
13:23:43 <geist> well if you want a firehose you can also run with -d int,exec,cpu
13:23:44 <j`ey> yep
13:23:48 <geist> that gives you more or less a full trace of the cpu
13:23:52 <j`ey> I'll give that a try
13:23:56 <j`ey> (tonight)
13:23:57 <geist> maybe ou're just branching into 0
13:24:21 <geist> but really if you're not enabling the mmu and bouncing up there and you're trying to run any C code there are a lot of things you can get wrong
13:24:28 <geist> most of which result in an exception and then you're back to where you started
13:24:47 <geist> i tsuspect from your description that you're racing ahead a bit and haven't gotten things properly set up and/or linked
13:25:10 <geist> about to head out for a bit but i'll be back later in the evening and we can trace it if you'd like (still in UK, have a few days of slack)
13:26:16 <geist> though i would start with spending some time puzzling through a cpu trace to try to figure it out, just assume nothing. it's possible your code isn't loaded right, isn't linked right, etc
13:26:32 <lava> but i think "real world" OSes don't do that... <geist> the default exception vector table is at 0
13:26:41 <geist> lava: that's correct
13:26:47 <geist> you relocate the vector table right off the bat
13:26:51 <lava> yes
13:26:55 <geist> and point it to your own exception vectors
13:26:57 <j`ey> geist: for sure. I have jumped into rust pretty early
13:27:10 <geist> oh... that... complicates things a lot
13:27:13 <j`ey> geist: so there probably is some stuff setup incorrectly
13:27:18 <geist> you have a lot of rust codegen to deal with that i have frankly zero idea
13:27:38 <geist> you're gonna want to get your exception table set up pretty quick then
13:27:42 <geist> but debug this first
13:28:03 <j`ey> hoping the -d cpu option gives me some more ideass
13:28:16 <geist> yep
13:28:38 <geist> note that since qemu is a jitting compiler it can't trace every single instruction
13:28:59 <geist> it translates a run of instructions until it sees a branch or any other similar thing, so cpu,exec tracing gives you block level
13:29:05 <geist> but usually it's easy tosee what's going on
13:29:07 <j`ey> ah
13:29:23 <geist> it's usually only a handful of instructions at a time
13:29:27 <j`ey> I kinda know roughly where it goes wrong, but not why yet
13:29:52 <geist> also remember any vector instructions and whatnot will almost certainly generate a fault
13:30:02 <geist> as well as alignment traps if you haven't enabled themin the SCTLR
13:30:15 <geist> so dunno what rust codegen is doing there, may need to feed it some additional flags
13:30:18 <geist> anyway, bbiab
13:30:47 <j`ey> yeah, I have enabled the FPEN (I think it was) bit to enabled usage of SIMD
13:31:01 <j`ey> cos I think LLVM is a bit buggy and doesnt seem to be able to disable them
17:04:19 <program> hello
17:25:36 <j`ey> geist: that -d cpu,int,exec pointed me closer (I think). I can see the PC before the PC gets to 0x0
17:25:49 <j`ey> and a few instructions after that pc is a br x8, so Im guessing x8 has 0
18:51:30 <j`ey> I dont think my bss clearing is working, and Im not sure if it's the cause of my issues. it's not working, I thinwk because it's generating relocations for the __bss_start and __bss_size
19:01:10 <Nuclear_> j`ey: relocations? are you maybe overcomplicating it? (haven't read any of your previous messages on this, so I don't have much context)
19:01:37 <Nuclear_> j`ey: generally it's pretty simple. you generate a couple of symbols in the link script at the correct addresses, and use them to clear your bss
19:01:43 <j`ey> Im not trying to
19:01:58 <zid> If you're not using PIC it should be simple
19:02:03 <Nuclear_> let me see if I have an example
19:02:03 <j`ey> but for some reason it is making relocations for those symbols
19:03:14 <Nuclear_> here's a simple one from what I'm working on these days: https://github.com/MindlapseDemos/256boss/blob/master/256boss.ld
19:03:23 <Nuclear_> and then during startup:
19:03:48 <Nuclear_> https://github.com/MindlapseDemos/256boss/blob/master/src/startup.s#L34
19:04:32 <j`ey> yeah, I have something similar
19:04:43 <zid> is it PIC/PIE?
19:05:13 <j`ey> yeah
19:05:18 <Nuclear_> why?
19:05:20 <zid> well.. it has to be a relocation then
19:05:44 <zid> at least on some level, unless your .text and .bss are in the same PT_LOAD
19:05:55 <zid> and it can use an offset
19:06:04 <j`ey> I wonder if I mis understood what geist said earlier
19:06:49 <Nuclear_> PIC makes things much more complicated. that would be overcomplicating it, unless you have a particular reason to use PIC
19:06:52 <j`ey> https://paste.rs/px2 I read this as 'nah, dont disable PIC'
19:07:23 <j`ey> or rather, I read it as 'nah dont "build my kernel in position dependent"'
19:07:54 <Nuclear_> again I don't have much context, but do you have a specific reason why you need to use PIC?
19:07:57 <Nuclear_> if not, ditch it
19:08:30 <j`ey> I don't. I was just continuing with it, perhaps due to a misunderstanding :)
19:09:11 <Nuclear_> it adds an unnecessary degree of complexity
19:12:41 <j`ey> ok, it works fine now, nice
19:13:02 <Nuclear_> *thumbs up*
19:15:42 <j`ey> (kinda, some of the output is a bit garbled)
19:16:19 <geist> yah that's why i was suggesting not messing with pic right now
19:16:37 <geist> it's really for fairly advanced kernel stuff later, notably KASLR
19:17:15 <j`ey> geist: https://paste.rs/px2 here I thought your "no dont" was to me saying to build with pic-disabled
19:17:16 <Nuclear_> geist: apparently he misunderstood what you said as "don't remove PIC" instead of "don't mess with PIC"
19:17:39 <j`ey> but yeah, it means most of my other code is nearly correct :-)
19:18:00 <Nuclear_> j`ey: well... you know how it is, just because you solved one bug, doesn't mean there aren't others :)
19:18:22 <j`ey> -d int,exec,cpu,nochain,in_asm some other useful qemu debug flags
19:18:23 <Bitweasil> https://www.anandtech.com/show/14694/amd-rome-epyc-2nd-gen *jaw drops*
19:18:32 <Bitweasil> 64 cores, 128 threads, 256MB L3 cache on AMD's new server CPUs.
19:18:40 <geist> yah
19:19:02 <zid> Intel promised me 8GB of stacked ddr memory on their cpus
19:19:07 <Nuclear_> they used my toy raytracer to showcase the performance of their previous epyc processor :)
19:19:31 <Nuclear_> I wonder if they'll do it again
19:36:38 <j`ey> 'Taking exception 3 [Prefetch Abort]', that doesnt sound good
19:37:37 <zid> Sounds good
19:38:39 <geist> that's just a regular exception
19:38:59 <zid> I read that as regular expression and thought "Oh no, now he really IS in trouble"
19:39:02 <geist> it sounds gnarly, but it's basically a page fault because of bad interrupt
19:39:08 <geist> er bad instruction fetch
19:39:16 <geist> ie, you branched into memory that's not mapped
19:39:21 <geist> or a few other things that can cause it
19:39:48 <geist> it's 'bad' in that you probably dont want to do it, but it's one of the many exceptions you will eventually be familiar with
20:01:13 <CompanionCube> https://www.phoronix.com/scan.php?page=news_item&px=Google-Kexec-Windows-Linux what
20:02:37 <mquy90> when supporting executable program., i get stuck on how to create address space
20:04:26 <mquy90> I plan to create an idle process on kernel space, so when spawning new process, just coping from it?
20:08:53 <mquy90> cannot get clear picture how to do it
20:09:26 <bcos> mquy90: Do you need a full idle process (and not just an idle thread)?
20:10:54 <mquy90> I am not sure what I need actually, still confuse, from what I understand when reading understanding the linux kernel, it is like dummy process 0
20:11:03 <mquy90> without thread? I don't know
20:12:29 <mquy90> I haven't support process's concept in my kernel yet, just run kernel mode, switch user mode, do thread scheduling in kernel mode
20:14:22 <bcos> For processes; you'd construct a new virtual address space by allocating 1 page for a new page directory (or PML4 or whatever CR3 points to) and copying the entries corresponding to kernel space into it (so that kernel space is same in all virtual address spaces)
20:14:49 <mquy90> agree, but how about thread
20:15:04 <mquy90> do I need to create idle thread when creating a process?
20:15:11 <bcos> ?
20:15:43 <bcos> Usually the kernel uses its own internal "idle thread" when there's nothing for a CPU to do
20:15:50 <bcos> ..but that's
20:16:29 * bcos prefers not having an idle thread and just doing "if no threads { wait }" in the scheduler; because that's much easier to extend to support power management later
20:17:34 <zid> The main reason I can think for having an idea task/thread is that you just allocate a normal statistics struct for it
20:17:37 <zid> without special code paths
20:20:53 <mquy90> maybe, I skip idle thread and only check if there is any thread when scheduler is called
20:22:02 <mquy90> currently, my scheduler is called via pic
20:23:37 <mquy90> but still, should it have an idle process on kernel mode?
20:25:58 <bcos> You'd either have an idle thread (per CPU) in the kernel; or not (just scheduler doing the "oh, no tasks want the CPU, guess I'll wait" thing). I don't think "idle process" makes sense
20:27:01 <bcos> (although you could fudge things up so that it looks like there's an idle process for the purpose of statistics, even though there isn't actually any process)
20:27:19 * zid nods
20:32:21 <mquy90> thanks, when switching to user mode, should I create a process and thread to wrap codepath or it is not neccessary
20:32:24 <bcos> (note: for power management you sort of want scheduler to do "there's nothing for CPU to do now, but a task will wake from sleep in 1234 ms, so lets put CPU into low power state for 1200 ms and bring it back to full speed in time for that task to wake up")
20:33:08 <bcos> (plus the normal "deeper sleep states the more time you've been idle" thing)
20:33:54 <mquy90> I don't fully understand that, my scheduler is dead simply, just run via irq 32, and check if there is any threads (a lot things to improve :P)
20:34:16 <bcos> mquy90: I like to think of "process" as a containing that contains a virtual address space and at least one thread (where if the last thread terminates you terminate the process)
20:35:12 <bcos> mquy90: Yeah; that's part of why I've been a bit quiet - it's usually a mistake to think the scheduler has anything to do with interrupts
20:36:31 <bcos> mquy90: This might (or might not) help: https://wiki.osdev.org/Brendan%27s_Multi-tasking_Tutorial
20:38:08 <mquy90> I did bookmark that link months ago, I plan to improve my scheduler, but after process/thread get through
20:40:46 <mquy90> what is the correct way to do after switching to usermode? what I do now https://github.com/MQuy/mos/blob/master/src/kernel/system/user.c#L54
20:45:13 <bcos> Correct way is to finish the scheduler and get everything working nice (and test the daylights out of it to make sure it's working nice); then write code to create a virtual address space with kernel mapped into it, then write code that creates some kind of "process info structure" (that includes that virtual address space and an initially empty list of threads), then spawn a thread to add to the process that starts running some kind of executable file loader
20:45:44 <bcos> ...where the executable file loader parses headers and sets up the virtual address space (and maybe finds shared libraries and does dynamic linking and...)
20:46:38 <bcos> ..and then once everything is ready do a "return from new thread for new process that's running kernel code to same thread running user-space code"
20:47:40 <bcos> (which might just be a "RETF" or a "SYSRET" or whatever; and will probably involve fixing a few bugs with segment permissions; but is relatively trivial)
20:48:29 <bcos> Of course none of that really has anything to do with the scheduler (most of it is virtual memory management and file IO)
20:49:21 <bcos> Hmm
20:49:47 * bcos is assuming some kind of "spawnProcess()" - for "fork()" things are different
20:50:32 <bcos> (for systems that only support "fork()" you don't really create a new process - you always clone an existing one instead)
21:14:10 <j`ey> hm, it seems like Im jumping to 0x6100000061, which seems quite far outside of the range of my code
21:20:35 <zid> Can I recommend you not do that?
21:21:17 <bcos> "AA" as UTF-32LE
21:21:39 <bcos> D'oh. "aa" - them's lower case
21:21:46 <zid> I've set many a rip to aaaaaaaaaaaa
21:29:18 <j`ey> bcos: wait...
21:29:53 <j`ey> bcos: youre right, nice
21:30:01 <j`ey> 0x6200000062
21:30:07 <bcos> :-)
21:30:09 <j`ey> I changed my array from a's to b's...
21:30:49 <zid> hehe
21:31:05 <zid> how did you manage to get he contents of a random array into your instruction pointer
21:31:15 <zid> smashed your stack?
21:31:27 <j`ey> that's what I gotta figure out I suppose!
21:31:53 <zid> -W -Wall -Wextra -pedantic -Lotsoferrors
21:33:05 <bcos> Maybe instruction pointer is correct; and there was a minor accident involving "memcpy()" that replaced the code at the instruction pointer
21:33:41 <bcos> D'oh. That doesn't make sense for anything other than JMP instructions
21:34:08 <bcos> Maybe a minor accident involving "memcpy()" that replaced the data on the stack
22:11:26 <geist> klange: you're being very patient, kudos
22:12:38 <zid> link to this thread?
22:13:13 <geist> oh it's on github. klange has some bug reports
22:13:19 <zid> link?
22:13:25 <zid> presumably you have it open
22:13:30 <geist> email
22:13:33 <zid> ah
22:13:58 <zid> what's the # or title?
22:14:05 <zid> 187?
22:14:09 <geist> well, the github email thing of pull requests on the taorous (i can never spell it)
22:14:15 <zid> nah that's old
22:14:19 <klange> why are you receiving emails for that
22:14:27 <geist> following the project
22:14:32 <zid> add group id ?
22:14:37 <geist> you get emails for pull requests and whatnot
22:14:43 * zid cannot find a big argument
22:14:45 <klange> #192
22:14:47 <geist> you can actually respond to the emails, it's kind of slick
22:15:03 <geist> zid: it's not an argument, klange is just being patient with somone
22:15:06 <geist> i never said argument
22:15:10 <klange> I've found formatting gets weird when people reply to the emails so I often end up asking people to use the web interface.
22:15:19 <zid> ah it was closed that's why I couldn't see it
22:15:21 <geist> klange: oh sure there
22:16:37 <zid> hehe you mentioned toctou
22:17:24 <zid> I've had 2 pull requests on github, one was garbage like this, one was okay
22:17:47 <zid> I had to do a bunch of research to actually merge it though because it changed a bunch of tuning constants
22:19:49 <geist> toctau ftw!
22:25:42 <zid> go on then, what's an a u
23:02:22 <zid> geist: Want to sponsor my OSdev?
23:51:55 <bcos> zid: Wondering if you could lend me about $14000 for a pair of Epyc CPUs...
23:54:21 <zid> bcos: I'll have to ask geist, he handles purchasing