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=21&m=11&d=15
00:17:00 * Ameisen has been frustrated at work
00:18:00 <Ameisen> I've had to do benchmarks on some things that are productivity/related and they take a long time
00:18:00 <Ameisen> I cannot really do anything while they're running
00:58:00 <zid> whoopsie, my cpu fan is not spinning
00:59:00 <zid> also ow, 90C heatsinks are hot
01:02:00 <eryjus> no thermal break yet? a little surprised.
01:02:00 <zid> tjmax is 100
01:02:00 <zid> guess I need to reboot, I think I know what caused it at least
01:03:00 <klange> tjmaxx? I thought they went bankrupt or something (they did not)
01:05:00 <Ameisen> not only did they not go bankrupt, but their max temperature indoors is 100C
01:06:00 <gog> no wonder the "size 4" jeans i got from them felt more like 2's
01:09:00 <zid> fixed
01:09:00 <zid> took me a while because apparently my bios refuses to boot the OS if the cpu is too hot
01:09:00 <zid> so I had to wait for the (now working!) fan to cool it down
01:09:00 <gog> were you playing with pwmconfig
01:10:00 <zid> no I was messing with a driver to me me do "out" from userspace
01:10:00 <zid> and apparently it completely dicked speedfan over
01:10:00 <gog> whoopsie
01:11:00 <gog> i cooked a q6600 once but it didn't seem to care just kept on truckin
01:11:00 <gog> i think my old roommate is using it in a file server now
01:12:00 <zid> q6600 had proper thermal limits
01:12:00 <zid> I ran it at 90C all day :p
01:12:00 <gog> nice
01:12:00 <zid> gotta reconfigure speedfan I tried reinstalling it to get its driver working again :(
01:13:00 <zid> Apparently speedfan thinks my CPU is now -60C though for some reason
01:14:00 <zid> I un-genuined my windows too by moving my boot drives around
01:17:00 <zid> If they didn't want me to use windows loader to reactivate windows, they shouldn't have made me need to call microsoft, fixed
01:17:00 <Ameisen> maybe you've discovered a way to supercool devices passively
01:19:00 <zid> whatever, it can read the core temps correctly, I just made it track core 0 instead of package
03:02:00 <klys_> curious about something, the linux loopback interface required too much permission for someone's builds and so and so probably has a replacement for that by now
03:03:00 <klys_> specifically the partprobe thing
03:31:00 <zid> oh a ben eater vid
03:31:00 <zid> doesn't sound super interesting though
03:32:00 <Mutabah> It's the basics of timers
03:32:00 <Mutabah> Pretty simple if you're at our level, but not bad
03:32:00 <zid> I don't think he can demonstrate how sleep *actually* works, on a 6502 :P
05:32:00 <geist> was nice, but yeah
05:32:00 <zid> sleep is sort of a weird thing to do in general tbh
05:33:00 <zid> If you're in a micro you probably *do* want the idle loop, and if you're on a desktop you definitely want to block somewhere for something instead
05:33:00 <geist> well, what he ended up implementing is basically a fairly standard embedded system
05:33:00 <geist> replace the loop with a WFI if the arch implements it and you have somehting that doesn't burn a lot of power
05:35:00 <geist> actual multithreading on 6502 is pretty annoying in particular because you can't relocate the stack (it's always implicitly page 01)
05:35:00 <geist> though i think some implementations have a swappable hardware page there
05:36:00 <zid> For something like that I'd just set up a callback chain
05:37:00 <geist> sure
05:37:00 <zid> rather than "threads"
05:37:00 <zid> just a bunch of tasks that get ran on whatever frequency you want
05:37:00 <moon-child> https://www.youtube.com/watch?v=kRlSFm519Bo more interesting eater video about timers
05:37:00 <bslsk05> 'Astable 555 timer - 8-bit computer clock - part 1' by Ben Eater (00:27:50)
05:37:00 <moon-child> (at least, so I assume; I didn't watch the other one)
05:37:00 <zid> That's about signal generation
05:37:00 <zid> latest vid is about IRQs
05:37:00 <zid> and delay loops
05:38:00 <geist> actually dealing with multiplexing sw timers on top of hw timers is surprisingly not a topic that comes up here over the years
05:38:00 <geist> either lots of hobbyists dont get to it, or it's trivial enough that most folks that do just figure it out
05:38:00 <zid> most games are written like that tbh
05:38:00 <zid> it's very natural
05:39:00 <zid> you get some callback, like vsync, then you pump off a bunch of events that need to happen on that frame, and go back to sleep
05:39:00 <geist> yah and ifyou have more events for that frame to deal with you can choose to delay them till the nxt one, etc
05:39:00 <zid> yea interrupts just stay disabled
05:40:00 <zid> you end up doing your entire program in the interrupt handler
05:40:00 <geist> i like writing that sort of game engine code. it's very much like kernels when you think about it
05:40:00 <zid> and only ever go idle with interrupts enabled
05:40:00 <geist> that's actually pretty much what ARM sort of intends you to do with cortex-m class hardware
05:40:00 <geist> since they have this very sophisticated interrupt priority scheme
05:41:00 <geist> it's fairly clear they intend for you to just write embedded thigns where multiple tasks == multiple interrupt vectors
05:41:00 <geist> totally doable really
05:41:00 <zid> (The other method is just to do it all before vblank, and just leave everything 'pending' for the vblank callback to finalize, like you double buffer the entire game state, and vblank just does a complicated memcpy)
05:41:00 <geist> you can have a main thats literally for (;;) wfi;
05:42:00 <zid> That latter one is fairly common on gameboy, because of vram being locked at various times and cpu time being limited
05:42:00 <moon-child> sounds like a case where coroutines would work well
05:42:00 <geist> whomp whomp. my windows 10 box just blue screened with PAGE_FAULT_IN_NONPAGED_AREA
05:42:00 <zid> You end up doing "calculate where I want all the sprites to be for the next frame without actually doing any mmio" then vram just copies a data block over the mmio range
05:42:00 <moon-child> but I guess interrupts are not so expensive in embedded?
05:42:00 <zid> s/vram/vblank
05:43:00 <geist> moon-child: in the case of cortex-m on ARM they seemed to explicitly design it such that they aren't, yeah
05:43:00 <geist> and it's quite efficient about dispatching interrupts from other interrupts, etc
05:43:00 <geist> i dont particularly *like* it, because it sort of runs counter to a preemptive system, and sort of gets in your way
05:43:00 <geist> but, it's clear what they were going for
05:44:00 * moon-child nods
05:44:00 <moon-child> incidentally, I came up with a truly horrible scheme for writing signal handlers that call non-reentrant functions
05:45:00 <moon-child> examine call stack. If you find you're currently in a non-reentrant function you wanna call from your handler, figure out the stack entry for its return address. Stash it and overwrite with the address of your fault handler
05:45:00 <moon-child> will run once it's done
05:45:00 <geist> what is sorta interesting is years later after i started playing with ancient VAX hardware did i realize the cortex-m interrupt scheme is almost a direct clone of what VAX did in the 70s
05:45:00 <geist> someone at ARM was clearly a student of classic architectures
05:45:00 <moon-child> s/fault handler/int handler/
05:47:00 <zid> or just old
05:47:00 <geist> well, they're not mutually exclusive
05:47:00 <zid> Don't really need to be a 'student' of the modern era
05:47:00 <zid> Whatever you grew up with is the default and completely natural
05:48:00 <geist> sure
05:48:00 <zid> I bet some kids in 10 years are going to start designing things with bloody mailboxes ;)
05:49:00 <zid> because of the rpi
10:25:00 <jjuran> klange: Nice DX7 article. Kudos on the bugfix.
12:05:00 * enyc meows jjuran
12:58:00 <klange> Ugh, well, I can't quite pin down where this is being so slow, but at least it seems to be both stable and no longer locking everything up, so... new ata driver pushed, I guess.
12:59:00 <klange> I can install doom, I can play doom, I can reboot, and doom is still there
13:22:00 <mathway> Hey. Could someone please explain me how types of STDIN buffering, like line-buffering and full buffering, works? I've searched the net a little, but I can only found information about their existence, but not how to work with them and how they exactly work. How there can exist different types of input buffering, when it just issues the read syscall which can't say in advance how many characters
13:22:00 <mathway> there are in input file, or the location of a newline character in it?
13:23:00 <zid> Usually you care more about the reverse
13:23:00 <mathway> What do you mean?
13:23:00 <zid> output buffering
13:24:00 <zid> I can't think of any osdev related stuff that has input buffering
13:24:00 <Mutabah> terminals?
13:25:00 <Mutabah> Sounds like pty logic
13:25:00 <klange> input buffering is generally a tty thing; there's a layer in between smashing your keyboard in the terminal and what actually gets read by the receiving process
13:25:00 <zid> that's output buffering though, shit you write()
13:25:00 <Mutabah> No, it's input buffering.
13:25:00 <Mutabah> Usually raw or line (full buffering isn't really a thing for ptys)
13:25:00 <zid> fflush infact, only works on output streams :P
13:26:00 <mathway> in unix
13:26:00 <mathway> microsoft does specify the behaviour for fflush(stdin)
13:26:00 <zid> They're wrong then, fflush is C
13:27:00 <zid> f* gives it away, posix is read/write/etc, C is fread/fwrite/etc
13:28:00 <mathway> Mutabah, I think there a lot of buffering in the whole computing process
13:29:00 <Mutabah> Oh, there's a LOT
13:29:00 <zid> Yea, thankfully
13:29:00 * zid huges his caches
13:29:00 <zid> hugs* feck
13:29:00 <mathway> However, from the programming perspective, now we speak about buffering inside standard library in case of i/o
13:30:00 <klange> mathway: A tty is configurable, so you can select how it buffers (or doesn't) input. None of this happens in the standard library, the tty layer exists outside of your program.
13:30:00 <mathway> i see that there's different types of buffering when input is from pty, and from file
13:30:00 <zid> the only 'standard library' buffering is the output buffering on newlines from fwrite/puts/printf/etc, which you can configure with setvbuf
13:30:00 <zid> that isn't.. implementation specific, anyway
13:31:00 <zid> some will input buffer so that getch isn't slow as fuck
13:37:00 <mathway> as far as i understand, i cannot control anyway types of buffering of tty or pry inside my program?
13:38:00 <mathway> if i can setvbuf on an input stream, what is the reason?
13:38:00 <mathway> if you say that it has no meaning, since the place where input buffering occurs is inside host environment, not my program
13:42:00 <klange> mathway: highly recommend a read of this https://www.linusakesson.net/programming/tty/
13:42:00 <bslsk05> www.linusakesson.net: The TTY demystified
13:45:00 <mathway> Thanks, will go read it.
16:46:00 <heat> is there a better way to not deal with libgcc in x86_64 than multilib?
16:46:00 <heat> due to mcmodel and mno-red-zone issues
16:47:00 <zid> how does multilib help?
16:47:00 <heat> gcc builds all its libraries in all combinations of multilibs
16:48:00 <heat> if you tell it to use mcmodel=large and mno-redzone, it will build (normal, mcmodel=large, mno-red-zone, mcmodel=large & mno-red-zone)
16:48:00 <heat> for libgcc, libstdc++-v3, libsanitizer, etc
16:50:00 <zid> still not seeing how adding multilib helps
16:50:00 <zid> sounds like more libgccs to port
16:51:00 <heat> linking kernel code = links with mno-red-zone & mcmodel=large
16:51:00 <heat> linking user code = links with normal libgcc
16:52:00 <zid> you keep repeating the bit that doesn't explain anything
16:52:00 <heat> how the fuck does it not help?
16:52:00 <zid> why would having x86 libgcc available alongside your amd64 libgcc, help 'deal with libgcc in x86_64'
16:52:00 <heat> multilib != 32-bit
16:53:00 <heat> multilib = build whatever the gcc target tells you to build
16:54:00 <heat> if you tell gcc to compile all its runtime libraries with -m32, it will, but it also works with *any* other option
16:54:00 <heat> the compiler then links you to the correct library according to the options you pass it
16:54:00 <zid> multilib is whether -m32 -m64 and -mx32 work, in gcc speak, fairly sure
16:54:00 <heat> negative
16:55:00 <heat> lots of targets have different multilibs
16:55:00 <zid> for x86_64-*-linux* that's what it means
16:55:00 <zid> I didn't think sparc was relevent
16:56:00 <heat> riscv for example
16:57:00 <zid> rv32gc or rv64gc
16:57:00 <zid> for riscv
16:57:00 <heat> https://gist.github.com/heatd/83d8ef0abb0305b34c26972a8f50cc39
16:57:00 <bslsk05> gist.github.com: gist:83d8ef0abb0305b34c26972a8f50cc39 · GitHub
16:57:00 <heat> that's t-linux-multilib
16:58:00 <zid> yea, then multiply by total march's
17:01:00 <heat> anyway, I can fix the whole "kernel needs a compatible libgcc + crtbegin/end" problem by using multilib when building gcc, but it's not the greatest solution out there
17:01:00 <heat> do real OSes even link with libgcc?
17:02:00 <zid> real OSes just have a working libgcc port, see -linux-
17:03:00 <heat> not for the kernel
17:05:00 <zid> I've never actually tried to build linux for an arch where I'd expect it to need libgcc, but used an -unknown instead of a -linux, actually
17:05:00 <zid> x86_64 I wouldn't expect to need libgcc unless you did 128bit division or something funky, it does 64bit ops natively afterall
17:06:00 <heat> it sometimes does need it for builtins iirc
17:06:00 <heat> and most importantly, constructors
17:06:00 <sham1> And how would Linux do 64-bit division on i386+ without libgcc
17:06:00 <zid> looks like they don't, and hand-roll 64bit division
17:07:00 <zid> https://yarchive.net/comp/linux/libgcc.html this is 20 years old now though
17:07:00 <bslsk05> yarchive.net: libgcc (Linus Torvalds)
17:08:00 <heat> you have special 64-bit div functions irrc
17:08:00 <heat> iirc*
17:09:00 <zid> (I also just don't link against libgcc, when it bites me I'll decide what to do)
17:13:00 <sham1> Hmm, it could certainly make things easier for me as well if I just simply ignored libgcc and figured it out later
17:13:00 <sham1> Building gcc would be easier and require less patching of sources and builds at build-time
17:15:00 <heat> fuchsia seems to link in libgcc and compiler-rt though?
17:15:00 <heat> dunno how
17:22:00 <heat> actually no they seem to disable it with -nostdlib
17:23:00 <sham1> Maybe compiler-rt is more amicable towards mcmodel=kernel and such
17:23:00 <sham1> In that case, that'd be one more reason to stop doing gcc and going with clang instead
17:24:00 <heat> highly unlikely
17:46:00 <shan> does implementing multitasking require any sort of special hardware?
17:46:00 <j`ey> no
17:47:00 <shan> is there anywhere i could read a high level explanation of how it works?
17:47:00 <shan> does one just use timers and interrupts to make it happen (for pre-emptive multitasking?)
17:48:00 <eryjus> shan: https://wiki.osdev.org/Brendan%27s_Multi-tasking_Tutorial
17:48:00 <bslsk05> wiki.osdev.org: Brendan's Multi-tasking Tutorial - OSDev Wiki
17:48:00 <shan> eryjus: thank you
17:48:00 <j`ey> timers, interrupts, exits from syscalls
17:49:00 <shan> what do you mean, exits from syscalls o_o
17:51:00 <shan> also, i'm not actually writing an operating system, i was just curious how multitasking works
17:51:00 <j`ey> as in, after a syscall, as the kernel is going to enter userspace, it might reschedule
17:51:00 <shan> ohhhhh
17:51:00 <shan> that makes sense
18:05:00 <catern> it occurs to me that running all the tests of a large system under SCHED_FIFO would be a good practice both to 1. ensure there's no busy-looping in the system and 2. massively reduce test flakiness/nondeterminism
20:35:00 <riverdc> anyone have recommendations for x86 instruction encoding libraries? preferably in C
20:35:00 <riverdc> I'm not sure how to use just the instruction encoding from LLVM without commiting to using the LLVM IR
20:48:00 <geist> was gonna tell heat, fuchsia sidesteps the -mno-red-zone for the kernel by simply not linking in libgcc
20:48:00 <geist> otherwise wold have to have a multilib for it
20:48:00 <geist> or, as i was pondering the other day, forcing every x86 exception through an IST and then manually building a stack frame that's red zone aware
20:49:00 <geist> seems like it's very doable, but would just require extra work on every exception
20:55:00 <sham1> geist: do you also happen to not link against libgcc on i686+?
20:56:00 <geist> fuchsia does't run on x86-32
20:56:00 <sham1> Fair enough
20:56:00 <sham1> That side-steps the issue nicely
20:56:00 <geist> 64bit only. aarch64 and x86-64 are both pretty libgcc clean. you can more or less never worry about it and unless you're using lots of 128 bit math or whatnot you'll probably never hit it
20:56:00 <geist> or there's one or two functions you can just manually implement
20:56:00 <geist> riscv64 too
20:57:00 <sham1> I don't even know how you'd do 128-bit math, probably __int128
20:57:00 <Arsen> that's about right
20:57:00 <Arsen> doesn't libgcc also hold some stack walking things
20:58:00 <sham1> Of course one way to avoid all this nonsense is to have a unikernel not built in C
20:58:00 <sham1> Or well, any kernel not built in C
20:58:00 <Arsen> clearly, c++ solves this
20:59:00 <sham1> Or C++
20:59:00 <sham1> If we want to be knobs about it
20:59:00 <Arsen> though, seriously, how does the language impact this?
20:59:00 <sham1> Well the language affects it in therms of the compiler used
21:00:00 <sham1> You could always not use GCC and that might solve it
21:01:00 <Arsen> doesn't clang also do this?
21:01:00 <Arsen> I'm not aware of any compilers that aren't llvm or gnu and are a good choice
21:01:00 <sham1> With compiler-rt yeah, and I don't know how well that supports being used with mcmodel=kernel
21:09:00 <geist> sham1: yes __int128
21:25:00 <kingoffrance> riverdc, no but i have "instruction_decoder" "instruction_encoder" libraries for that purpose. just havent implemented any backends yet :D
21:26:00 <kingoffrance> i mean, i didnt really look, but i want such a thing eventually
21:36:00 <kingoffrance> the only thing i care about there is have a plaintext specification format (or "configuration file") so new things can be added without writing code. so..."yak shaving"
21:36:00 <kingoffrance> and then make other things use those libraries
21:37:00 <kingoffrance> e.g. assembler, whatever else
21:37:00 <kingoffrance> if i was going to copy something, i would just want to avoid hardcoding
21:37:00 <sham1> Those poor yaks
21:38:00 <j`ey> that's what LLVM (tablegen) and GCC (I forgot.., .md files I think)
21:39:00 <kingoffrance> ^^ yep, gcc had some kind of lisp-ish-inspired IIRC
21:39:00 <sham1> Ofc
21:42:00 <kingoffrance> i dont want to write a compiler, so i avoid it...but that seems simple, just drudgery mostly.
22:46:00 <riverdc> kingoffrance: looks like 'keystone' has assembler infrastructure but I don't think I want to depend on that either
22:47:00 <riverdc> I guess I'll succumb to my NIH syndrome and do it myself for now
22:53:00 <klange> wtf am i even doing https://klange.dev/s/Screenshot%20from%202021-11-16%2007-45-04.png
22:55:00 <j`ey> building your kernel in itself?
22:55:00 <j`ey> oh, no, block layer stats
22:59:00 <klange> Just trying to install gcc, it's now written about 7GiB of stuff, though it's only flushed out about 120MB to disk. I have no idea what it's actually doing.
23:01:00 <j`ey> uh oh
23:02:00 <klange> It's _probably_ an issue with the ext2 driver and not the disk driver? I've never actually tried to unpack this tarball through the ext2 driver and it is a _doozey_.
23:03:00 <klange> and it just failed to create a directory https://klange.dev/s/Screenshot%20from%202021-11-16%2008-02-52.png
23:06:00 <klange> or it tried to put too many files in that directory, lots of possibilities
23:11:00 <klange> I'm obviously doing something insanely stupid because it goes through like 600MB of writes... despite only having like 18MB of stuff to write at the end of the day when installing quake https://klange.dev/s/Screenshot%20from%202021-11-16%2008-09-13.png
23:36:00 <kingoffrance> riverdc, my problem is i more or less have a "marked up" "intermediate" C due to pragma madness :D but i dont want to write by hand. so if i ever did want a compiler, i need: 1) something to parse C to my "intermediate representation" 2) "IR" either can output more C (what i will do now, functionally-equivalent to macros essentially) or try to transform that to assembly, or maybe another IR between.
23:36:00 <kingoffrance> thats why i postpone that...i could maybe "join in the middle" but i'd need something to parse C first, i dont want to write "IR" by hand :D
23:39:00 <kingoffrance> if i get enough separate pieces maybe i can join them, but i have enough to do for now
23:40:00 <kingoffrance> so, an assembler, i would still be missing 2 pieces at least.
23:41:00 <kingoffrance> i'd like an assembler to assemble at run-time though :D it just doesnt get me all the way
23:47:00 <kingoffrance> and, i dont know, maybe go higher and just skip C altogether, other than "IR" form. i can leave that door open for now, dont know if i'll ever get that far
23:57:00 <kingoffrance> its ilke that lol [???] -> IR "C" -> ??? -> assembler
23:58:00 <riverdc> kingoffrance: I'm in a similar position, although more due to geting tired of writing out tagged unions by hand and doing pattern matching by hand than pragma madness
23:58:00 <kingoffrance> well what do you do, or you are still deciding ?
23:59:00 <kingoffrance> pragma is not really madness, its just...you can go #pragma magic_start ??? #pragma magic_end and go wild lol
23:59:00 <kingoffrance> you can stick any language between those you want