klange changed the topic of #osdev to: Operating System Development || Don't ask to ask---just ask! || For 3+ LoC, use a pastebin (for example https://gist.github.com/) || Stats + Old logs: http://osdev-logs.qzx.com New Logs: https://libera.irclog.whitequark.org/osdev || Visit https://wiki.osdev.org and https://forum.osdev.org || Books: https://wiki.osdev.org/Books
netbsduser has joined #osdev
heat has quit [Read error: Connection reset by peer]
heat has joined #osdev
<kof673> mjg: i remember an article claiming some finance math was using stuff from QUANTUM MECHANICS
<kof673> "capital" got redefined circa 1920s at least in the u.s. to mean future potential profits, so that is totally accurate lol
eddof13 has joined #osdev
eddof13 has quit [Client Quit]
memset has quit [Ping timeout: 260 seconds]
memset has joined #osdev
gog has quit [Ping timeout: 252 seconds]
Gooberpatrol66 has quit [Ping timeout: 264 seconds]
krychu has quit [Ping timeout: 244 seconds]
Gooberpatrol66 has joined #osdev
vdamewood has joined #osdev
netbsduser has quit [Ping timeout: 260 seconds]
edr has quit [Quit: Leaving]
<bslsk05> ​www.youtube.com <no title>
<heat> "Tony Hawk's Pro Strcpy"
qubasa has joined #osdev
vdamewood has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
vdamewood has joined #osdev
heat has quit [Ping timeout: 258 seconds]
netbsduser has joined #osdev
Gooberpatrol66 has quit [Ping timeout: 252 seconds]
JupiterBig has joined #osdev
<geist> heh
<clever> geist: i assume youve heard about the rp2350 by now? i have plans to add LK to it once mine arrives
JupiterBig has quit [Ping timeout: 248 seconds]
<geist> yep! I ordered one too
<geist> it looks neat
<clever> the option of 16mb of psram is pretty crazy
<clever> for an MCU
<clever> and this will be a wonky situation of supporting both M33 and risc-v on the same platform!
netbsduser has quit [Ping timeout: 252 seconds]
Matt|home has quit [Read error: Connection reset by peer]
<kazinsal> hopefully the interconnect for the psram is faster than it was on the rp2040
<kazinsal> 8 megs on the 2040 was real nice but it was sloooow. iirc the picomem isa card that uses it is 6 wait states on an AT for any memory emulation that goes to the psram
<clever> kazinsal: its rigged up similar to the XIP flash, so its just in the address space normally, with cache
air has quit [Quit: Client killed by user]
<geist> my gues sis it's mostly useful for storing assets
<clever> the only downside i can immediately see, is that the flash and PSRAM share the same QSPI bus, and it just has 2 chip-selects
<geist> instead of working program memory
<geist> also the atomic global monitor doesn't work on anything but local SRAM
<clever> ah, good catch, i hadnt noticed that
<clever> so you could put a heap in external ram, but atomics dont work there
<geist> yah you might want to double check that but it was the first thing i looked at, could you build an actual SMP system with it
<geist> well the local monitor should work, so atomics with a single cpu will work, but if you're trying to implement actual SMP the atomics (which uses the globla monitor) wont work on anything but SRAM
<clever> i also noticed, the arm side, uses load/store exclusive, where you implement the retry in sw
<geist> yep, that's classic arm atomic
<clever> but the risc-v side, has all in one atomic opcodes, that retry on their own, and take 4 clocks per attempt
<geist> not entirely. riscv has a few single i nstruction ones, but also load/store exclusive
<clever> ah, maybe i missed those
<geist> basically there's only amo<alu op> and amoswap
<geist> but then to implement something like compare-exchange, you need the full lw/sw
<geist> lw/sd i think
<clever> page 290, lists how many clocks each opcode from the A extension can take
<clever> ah yep, your right, load-store exclusive are the first 2, and take 1 or 2 clocks, depending on what the next opcode does
<clever> and then page 291 has all of the amo opcodes
<clever> which are 4 per attempt
<geist> yah
<clever> i also noticed, the main RV32I branch opcodes, are 1 clock slower, if the destination is a mis-aligned 32bit opcode
<geist> yah that's fairly common. some of the big cores have that too
<clever> i think the i-fetch is always 32bit aligned
<geist> sifive cores, etc
<clever> and under normal conditions, it will fetch half of the next mis-aligned opcode, and sort of prefetch
<clever> but when branching, that prefetch guessed wrong
<geist> https://github.com/Wren6991/Hazard3 is the riscv implementation
<bslsk05> ​Wren6991/Hazard3 - 3-stage RV32IMACZb* processor with debug (26 forks/471 stargazers/Apache-2.0)
<clever> i'm not used to having access to the cpu source, heh
<clever> so i tend to guess from just what the docs leak
<bslsk05> ​github.com: Hazard3/hdl/hazard3_decode.v at stable · Wren6991/Hazard3 · GitHub
<clever> ah yeah, thats the load-exclusive
<clever> and i see the if's to just turn that into an invalid opcode when lacking A
arminweigl_ has joined #osdev
<clever> let me see if i can find the branch opcode in that file...
<geist> some logic there for getting the 4 cycles https://github.com/Wren6991/Hazard3/blob/stable/hdl/hazard3_core.v#L345
<bslsk05> ​github.com: Hazard3/hdl/hazard3_core.v at stable · Wren6991/Hazard3 · GitHub
arminweigl has quit [Ping timeout: 260 seconds]
arminweigl_ is now known as arminweigl
<clever> line 314 or decode, it looks like having `debug_mode` set, causes JAL to become an invalid opcode?
<clever> like they want to trap any change of PC?
<geist> yeah dunno
<clever> and i'm not sure where i-fetch occurs, this part of the code doesnt seem to deal with it
<geist> yeah that'll be in some other .v file i guess
<clever> it looks like its rigging the ALU up, to add an immediate to PC
<clever> feels like JAL is pc-relative
<clever> and its probably raw_branchcond that will do the actual branch, to whatever the ALU spits out
<clever> so all types of branching can just set raw_branchcond and rig up the ALU, then a common chunk of code can check the condition and maybe look at the result
<geist> that's odd, i thought JALR would be not PC relative becuse it just branches to the target reg
<geist> oh you know what that ADD PC stuff is? that's computing the *next* address
<clever> yeah, thats strange, its doing the same as JAL
<geist> to store in the RA
<clever> oh!
<clever> because of the L in JAL!
<geist> ALUSRCB_IMM is probably +4 or something
<geist> right, and the raw_rd is the target register
<clever> raw_imm = d_instr_is_32bit ? 32'h4 : 32'h2;
<clever> and then you have this
<clever> the immediate is 4 for 32bit opcodes, else 2
<geist> note the BEQ/etc ones above set the raw_rd to x0, so the dest is lost
<clever> so its reusing the immediate register, rather then decoding one from the opcode
<geist> also note that this is decoding 32bit riscv instructions, https://github.com/Wren6991/Hazard3/blob/stable/hdl/hazard3_instr_decompress.v synthesizes 32bit from 16 bit
<bslsk05> ​github.com: Hazard3/hdl/hazard3_instr_decompress.v at stable · Wren6991/Hazard3 · GitHub
<clever> ah, branch condition is an output wire from the decoder, something else then decides what to do with it
<geist> which is a property of riscv: each compressed instruction *must* be able to decode to a full one, so one can implement a c -> notc decoder precisely like this
<clever> the datasheet also warned, that opcodes from the C extension can translate directly 1:1 into 32bit opcodes
<clever> but opcodes from the Zcmp extension cant
<geist> ie, there can't be any special case C instructions that have no equivalent (like in thumb2)
<clever> a single Zcmp opcode, expands to multiple 32bit opcodes
<clever> its getting CISC in here!
<geist> oh? oh that's right. haven't dealt with those before
<geist> they're basically embedded only
<clever> the datasheet also mentioned, that if C is enabled, and you give it a compressible 32bit opcode, it will use the 16bit form automatically
<geist> ah yeah: https://github.com/Wren6991/Hazard3/blob/stable/hdl/hazard3_instr_decompress.v#L426 seems to give each zcmp instruction 4 uops of space to do its work
<bslsk05> ​github.com: Hazard3/hdl/hazard3_instr_decompress.v at stable · Wren6991/Hazard3 · GitHub
<geist> that's a property of the assembler yes. you can disable it with some assembler operative
<clever> but you can also use c.add, to force the compressed form, i assume assembling fails if the extension is off?
<geist> yeah
<clever> other then being slightly smaller in asm, i feel like its better to use compressible forms of the 32bit opcodes?
<clever> then it works best in both modes
<geist> yeah there's really no downside to using it
<clever> `c.add a0, a1` might be smaller, but `add a0, a0, a1` is more portable, and can still benefit from C if enabled
<geist> and compilers/assembly writers etc should be slightly aware of the situations that allow it to use the C version
<geist> and yes, you always write the uncompressible version and the assembler can replace
<geist> in practice it actually gets pretty good use of it, the code density of riscv + c is pretty close to thumb2
<clever> the VPU has something similar, where the assembler will auto-compress, and gcc has been told that r0-r15 are "fast", because opcodes using those can compress
<geist> and a lot better than arm654
<clever> that then causes gcc to prefer using the lower half of the regs
<geist> the main downside that iv'e seen some vendors that are implementing riscv cores (mostly ones that have previously done ARM) is the C instruction set chews up a sizable chunk of the opcode space
<geist> since 3 whole bits are basically fixed in stone when implementing a 32bit opcode
<geist> so i guess it chews up like 7/8th of the address space?
<geist> well bit space
<clever> one of the engineers also responded on the forums, about "why no usb2"
<clever> and they mentioned that a usb2 core, takes up more die space then both hazard cores combined
<clever> i dont know about risc-v, but the VPU variable length encoding, basically had a 1/2/3/4 bit flag in the opcode to indicate the size, something like if the first bit was 0, its a short opcode, so now you have 15bits left to play with
<clever> if the start is 0b10, then its a 32bit opcode, so youve got 30 bits left
<clever> so the more compressed the opcode is, the smaller the size tag is
<geist> yah riscv has a utf8 style thing in the base of the opcode that determines how much more opcode there is
<geist> 16 bit opcodes all start with 00,01,10
<geist> 32bit opcodes all start with 011, 48 bit opcodes start with 0111, 64 01111 and so on (iirc)
<clever> ah, thats a bit more complex
<clever> having 3 different prefixes for 16bit opcodes
<geist> at the moment none of the 48/64/etc space is defined
<geist> wel the idea is the 16 bit opcodes need the bits more than 32bit, so they gave 16 a bit more to work with
<clever> ah, thats why ive not heard of such fat opcodes
<clever> VPU instead went for a 1bit size tag, and 15 usable bits, so thats 2^15 or 32768 possible 16bit opcodes
<clever> while it sounds like risc-v has a 2bit size-tag, with 3 valid states, so 3 * 2^14 possible 16bit opcodes? 49152
<geist> yah
<clever> neat, they managed to get more opcodes, despite using a larger tag
<geist> but then chews off more space in 32bit world
<geist> but some of that is also not just because of the 16bit opcodes, but beause it allows for >32
<clever> but 32bit has a lot more room to spare
<geist> so one bit goes to 16, another goes to >32
<clever> what do you think about arm getting an fpu and risc-v lacking one entirely?
<geist> oh i didn't think about that
<clever> from what ive seen, the arm has a standard 32bit float co-processor, and then a custom 64bit co-processor
<geist> oh hmm, yeah i guess there is a difference. probably a sizable change too
<geist> the fpu is probably very large compared to it
<clever> the arm 32bit fpu is a standard block, so i think it has several float registers and all the usual float ops?
<geist> yah the register file is probably fairly substantial
fedaykin has joined #osdev
<clever> but then you have the custom 64bit co-processor, it only has add/sub/mult/div/sqrt, only 2 registers? and a 9bit status flag
<clever> the docs mention it being far more light weight, at the cost of needing more back&forth, but still being better then doing it in software
<geist> ah hmm, okay. that i guess keeps it fairly small
<geist> the register f32 will have i think 32 32bit registers, i think
<clever> yeah, thats basically doubling the register space
<clever> and if you had 32x64bit, that would double it again
<clever> i forget why, but you said something about the VPU's design not being good? where you just have 32 GP registers, all 32bits, and they can be int32 or float32
<geist> oh i dunno i dont think i was dissing it much
<clever> that seems far simpler to me, the normal function prologue and irq save/restore doesnt have to care about floats being unique
<geist> it's an ARC iirc, right? or a derivative at least
<clever> i forget what its based on
<clever> ah yeah, ARC is mentioned on the github with all of the docs
<clever> another slightly weird thing, the float64 co-processor, is doubled up, for secure and non-secure modes
<clever> ah, there it is, co-processor 4, maps to the DCP (double precision coprocessor) for the current security status, so its easy to access
<geist> oh side note, someone at work mentioned armv8-m (which the cortex-m33 is) has a built in stack-overflow detection mechanism
<geist> i need to look into it
<clever> while co-processor 5, maps to the non-secure DCP, and can only be used by secure mode, to save/restore when context switching between different non-secure guests
<clever> so when you transition from NS->S, you dont have to worry about the DCP being tainted
<clever> only if your S is context switching from one NS to another NS
<clever> RPF also added their own stack canary stuff, in the redundancy co-processor
pabs3 has quit [Remote host closed the connection]
<clever> at boot, it will generate a random seed, which is somehow used in generating and verifying stack canaries
pabs3 has joined #osdev
<clever> its intended to ruin return orientated programming
<clever> ah there it is, section 3.6.3.5, upon entry to a function, a canary is written to the stack frame, and its unique to both the boot (64bit random seed), and the function being entered (8bit tag)
<clever> and then upon exiting a function, it will verify the canary is valid
<clever> so you cant just jump into a random function, and then let its prologue pop a return addr from the stack
<clever> the canary would be entirely wrong, and it would hard fault
<clever> and the canary is different on every boot (the 64bit seed)
<clever> oh, interesting, only 24bits of the canary are used, the lower 8 bits are zero, so when you store it to ram in LE32 order, that becomes a terminating null
<clever> so a stray strcpy will die on the first byte (all nulls) of the canary, and not leak the canary itself!
<clever> and its now 2am, i should get some sleep!
<geist> no more Tony Hawk's Strcpy
<clever> :D
frkazoid333 has quit [Ping timeout: 260 seconds]
Gooberpatrol66 has joined #osdev
goliath has joined #osdev
ghostbusters2 has quit [Ping timeout: 252 seconds]
ghostbusters2 has joined #osdev
fedaykin has quit [Quit: Lost terminal]
ChanServ has quit [shutting down]
ChanServ has joined #osdev
masoudd has joined #osdev
<kof673> hmmm...game cube and xbox 360 are two things i might want that, but how much work would it be to track down a game and mem card and make a custom file/etc. :/ good to know anyways :D
air has joined #osdev
xvmt has quit [Remote host closed the connection]
xvmt has joined #osdev
<Ermine> what P means in PSRAM?
<Ermine> ... Pseudo
<Mondenkind> phallic
GeDaMo has joined #osdev
Yoofie646 has quit [Ping timeout: 245 seconds]
fedaykin has joined #osdev
netbsduser has joined #osdev
hwpplayer1 has joined #osdev
mavhq has joined #osdev
masoudd has quit [Ping timeout: 252 seconds]
op has joined #osdev
heat has joined #osdev
edr has joined #osdev
JupiterBig has joined #osdev
JupiterBig has quit [Client Quit]
raphaelsc has joined #osdev
JupiterBig has joined #osdev
someguy has joined #osdev
Rubikoid has quit [Read error: Connection reset by peer]
Rubikoid has joined #osdev
Dead_Bush_Sanpai has joined #osdev
<Ermine> I wonder how hard is it to deal with stale mount points
m3a has quit [Ping timeout: 252 seconds]
someguy has quit [Ping timeout: 244 seconds]
heat has quit [Remote host closed the connection]
heat has joined #osdev
<heat> Ermine, what's a stale mount point
<Ermine> heat: e
<Ermine> e.g. you mount usb drive, then plug it off without unmounting first
<heat> ok, then define "deal with"
<nikolar> heh
<nikolar> not much you can do then
<nikolar> dump all of the caches, report errors on accesses and disappear the mountpoint
<heat> pretty much yeah
<nikolar> i think for fat32 (or was it for removable drives) windows automatically does direct writes to the drive
<nikolar> no caching
<nikolar> so you have consistent data (or as close to it as possible)
<heat> what happens if you run zfs on a flash drive
<heat> will it catch fire?
<nikolar> literally nothing
<nikolar> it will just work (tm(
<zid> just not work*
<zid> a) flash drives never fucking work b) nothing can read zfs
<nikolar> nothing can read zfs???
<nikolar> a) fair point
<heat> aktshually i run illumos 🤓
<heat> nikolar, dude is zfs even compatible between solaris and openzfs?
<heat> do all systems run slightly different and incompatible versions of zfs
<netbsduser> they have Feature Flags now
<netbsduser> an advanced new feature pioneered by OpenZFS
<netbsduser> this application of the sun engineering ethos (even after the sunset) ensures robust interoperability between all the heritors of the solar legacy
<nikolar> heat: there's openzfs which should be compatible between linux and freebsd
<nikolar> if you mean the oracle solaris, that was proprietarized the moment oracle got their hands on it and is generally not compatible unless you restrict it to the lower common denominator
<nikolar> i am not even sure of that
Starfoxxes has joined #osdev
hwpplayer1 has quit [Remote host closed the connection]
Left_Turn has joined #osdev
JupiterBig has quit [Ping timeout: 260 seconds]
JupiterBig has joined #osdev
eddof13 has joined #osdev
JupiterB2g has joined #osdev
Turn_Left has joined #osdev
Left_Turn has quit [Ping timeout: 265 seconds]
eddof13 has quit [Quit: eddof13]
eddof13 has joined #osdev
<heat> two zfs? which one is the real one
<nikolar> openzfs of course
JupiterBig has quit [Ping timeout: 260 seconds]
<nikolar> even netbsd has a working openzfs port, though it's somewhat old
JupiterB2g has quit [Ping timeout: 272 seconds]
someguy has joined #osdev
eddof13 has quit [Quit: eddof13]
<heat> sorry, i'm a solaris loyalist
eddof13 has joined #osdev
<kof673> i think we have to like...threaten to execute solaris, and the real zfs will step in and stop it?
<kof673> something like that
<nikolar> lol
<isabella> king solarismon?
[Kalisto] has quit [Read error: Connection reset by peer]
[Kalisto] has joined #osdev
JupiterB1g has joined #osdev
JupiterB2g has joined #osdev
someguy has quit [Ping timeout: 260 seconds]
<mjg> nikolar: it's NOT an openzfs port motherfucker
<mjg> it's one true zfs directly from the freebsd port, which was directly made from illumos
<mjg> that's from before openzfs became stable
<nikolar> oh is that so
<heat> doesn't freebsd also use openzfs?
<nikolar> they do now
JupiterB2g has quit [Ping timeout: 244 seconds]
JupiterB1g has quit [Ping timeout: 244 seconds]
JupiterB1g has joined #osdev
JupiterB2g has joined #osdev
FreeFull has quit [Quit: rebooting]
FreeFull has joined #osdev
Dead_Bush_Sanpai has quit [Quit: Dead_Bush_Sanpai]
JupiterB2g has quit [Ping timeout: 252 seconds]
JupiterB1g has quit [Ping timeout: 260 seconds]
op has quit [Remote host closed the connection]
hwpplayer1 has joined #osdev
freakazoid332 has joined #osdev
Left_Turn has joined #osdev
vdamewood has quit [Read error: Connection reset by peer]
spareproject has joined #osdev
vdamewood has joined #osdev
Turn_Left has quit [Ping timeout: 260 seconds]
Turn_Left has joined #osdev
Left_Turn has quit [Ping timeout: 252 seconds]
xenos1984 has quit [Ping timeout: 248 seconds]
xenos1984 has joined #osdev
eddof13 has quit [Quit: eddof13]
eddof13 has joined #osdev
xenos1984 has quit [Ping timeout: 258 seconds]
gog has joined #osdev
gorgonical has quit [Ping timeout: 252 seconds]
xenos1984 has joined #osdev
eddof13 has quit [Quit: eddof13]
gog has quit [Ping timeout: 260 seconds]
eddof13 has joined #osdev
X-Scale has joined #osdev
MiningMarsh has quit [Quit: ZNC 1.9.1 - https://znc.in]
MiningMarsh has joined #osdev
X-Scale has quit [Ping timeout: 256 seconds]
vdamewood has quit [Quit: Life beckons]
netbsduser has quit [Ping timeout: 252 seconds]
Left_Turn has joined #osdev
mavhq has quit [Quit: http://quassel-irc.org - Chat comfortably. Anywhere.]
netbsduser has joined #osdev
Turn_Left has quit [Ping timeout: 244 seconds]
mavhq has joined #osdev
Turn_Left has joined #osdev
Left_Turn has quit [Ping timeout: 272 seconds]
Turn_Left has quit [Ping timeout: 265 seconds]
Left_Turn has joined #osdev
eddof13 has quit [Quit: eddof13]
hwpplayer1 has quit [Remote host closed the connection]
Gooberpatrol66 has quit [Quit: Konversation terminated!]
Gooberpatrol66 has joined #osdev
hwpplayer1 has joined #osdev
fedaykin has quit [Quit: Lost terminal]
eddof13 has joined #osdev
eddof13 has quit [Client Quit]
Matt|home has joined #osdev
hwpplayer1 has quit [Quit: ERC 5.5.0.29.1 (IRC client for GNU Emacs 29.4)]
hwpplayer1 has joined #osdev
the_oz has joined #osdev
<the_oz> Been missing a loooooong time. But, hello!
hwpplayer1 has quit [Remote host closed the connection]
<zid> how'd you get a colon and a number in your host
<the_oz> /ns register
<the_oz> shorthand for /msg nickserv register
<zid> yea I know how irc works
<zid> you infact, have to be registered to join this channel it's +r
<the_oz> I never made the jump to libera.chat until just now. The number was given to me not of my volition
<zid> afaik those cloaks were tied to org and an ircop had to do it
<zid> never seen one with a colon number
<the_oz> Thank you for verifying your e-mail address! You have taken steps in ensuring that your registrations are not exploited.
<the_oz> * You are now logged in as the_oz -NickServ- You have been given a default user cloak. -NickServ- Your account name cannot be used in a cloak directly. To ensure uniqueness, a number was added.
<the_oz> * user/the-oz:26077 :is now your hidden host (set by services.) -NickServ- Information on the_oz (account the_oz): -NickServ- Registered : Aug 16 19:48:56 2024 +0000 (1m 38s ago)
hwpplayer1 has joined #osdev
xenos1984 has quit [Read error: Connection reset by peer]
<the_oz> I dunno, maybe it's got an old registration, maybe back on freenode or oftc? I forget where this was
valerius_ has quit [Quit: ZNC 1.8.2+deb3.1 - https://znc.in]
<zid> ah it was a disambiguation automagic!
<zid> mystery solved
<zid> I'venever used an org cloak, I just register funny reverse dns hosts
<the_oz> snowflake tidbit, my very own hash
valerius_ has joined #osdev
Starfoxxes has quit [Remote host closed the connection]
gog has joined #osdev
GeDaMo has quit [Quit: 0wt 0f v0w3ls.]
hwpplayer1 has quit [Quit: ERC 5.5.0.29.1 (IRC client for GNU Emacs 29.4)]
xenos1984 has joined #osdev
hwpplayer1 has joined #osdev
memset has quit [Remote host closed the connection]
memset has joined #osdev
Gooberpatrol_66 has joined #osdev
Gooberpatrol66 has quit [Ping timeout: 252 seconds]
hwpplayer1 has quit [Quit: ERC 5.5.0.29.1 (IRC client for GNU Emacs 29.4)]
the_oz has quit [Quit: Leaving]
hwpplayer1 has joined #osdev
Arthuria has joined #osdev
spareproject has quit [Remote host closed the connection]
eddof13 has joined #osdev
eddof13 has quit [Client Quit]
the_oz has joined #osdev
eddof13 has joined #osdev
netbsduser has quit [Ping timeout: 252 seconds]
masoudd has joined #osdev
eddof13 has quit [Client Quit]
memset has quit [Remote host closed the connection]
memset has joined #osdev
memset has quit [Remote host closed the connection]
memset has joined #osdev
eddof13 has joined #osdev
eddof13 has quit [Client Quit]
netbsduser has joined #osdev
randm has quit [Remote host closed the connection]
randm has joined #osdev
netbsduser has quit [Ping timeout: 258 seconds]
Arthuria has quit [Killed (NickServ (GHOST command used by Guest684531))]
Arthuria has joined #osdev
hwpplayer1 has quit [Quit: ERC 5.5.0.29.1 (IRC client for GNU Emacs 29.4)]
masoudd has quit [Quit: Leaving]
Left_Turn has quit [Read error: Connection reset by peer]
radens has joined #osdev
m3a has joined #osdev
JupiterBig has joined #osdev
JupiterBig has quit [Ping timeout: 248 seconds]
heat has quit [Read error: Connection reset by peer]
heat has joined #osdev