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=22&m=5&d=23
00:01:00 <heat> geist, i just think their thing is broken
00:01:00 <heat> case in point: https://github.com/dspinellis/unix-history-repo/tree/BSD-4_3_Reno-Snapshot-Development/usr/src/sys/netinet vs https://minnie.tuhs.org/cgi-bin/utree.pl?file=4.3BSD-Reno/src/sys/netinet
00:01:00 <bslsk05> github.com: unix-history-repo/usr/src/sys/netinet at BSD-4_3_Reno-Snapshot-Development · dspinellis/unix-history-repo · GitHub
00:01:00 <bslsk05> minnie.tuhs.org <no title>
00:07:00 <heat> ah I see, you need to use the tags and not the branches
00:55:00 <gamozo> geist: Yeah, a lot of it re: rust code size, is probably that I don't use any third party libs in my big projects
00:56:00 <geist> yah totally. i dont think the base language itself generates lots of code, except from what i can tell it's kinda templately? ie, not so much a template, but it uses a lot of customized variants of routines
00:56:00 <gamozo> Same thing with build times. I genuinely don't know what causes such slow Rust build times? I've never really had bad build times on my own programs. I don't really know what the paradigm that causes issues is tbh
00:56:00 <geist> so hypoethetically a shared module that operates on lots of different data types may end up getting stamped out a lot?
00:56:00 <gamozo> I haven't observed that too much myself, but Rust is my first templated language and I'm maybe a bit more cautious about it
00:57:00 <geist> yah not that that's intrinsically bad, but it may end up driving you towards particular patterns where code is effectively inlined and expanded a lot
00:57:00 <geist> as tends to happen with C++ and lots of templately lib stuff
00:57:00 <Mutabah> The slow builds are a mix of emitting a LOT of IR for LLVM to churn down, and some popular libraries being very generic (template) heavy
00:57:00 <geist> which isn't intrinsically bad, just a thing
00:57:00 <gamozo> Absolutely. I think that's kinda in the back of my mind when writing templates. I grew up hating them in C++
00:58:00 <gamozo> For sure
00:58:00 <geist> right, i think rust effectively implicitly relies on LTO to sort itself out
00:58:00 <gamozo> I'm really picky about <2-3 second build-test cycles, so my build times and stuff are always super super carefully managed
00:59:00 <Mutabah> `cargo check` helps a lot with those :)
00:59:00 <gamozo> Yeah, I had to use LTO for my bootloader, although I don't think you have to anymore (it was to make sure all the formatting code got removed)
00:59:00 <geist> yah. i thinki t's one of those things where large LTO things scale almost nonlinearly, though i have no data to back that up
00:59:00 <geist> but i've seen some large rust projects pretty quickly reach the multi minute compile stage
01:00:00 <gamozo> Yeah, that's a common complaint which makes me sad :( I think a lot of generic stuff is done linearly, which I don't think is necessary (eg. you could pre-process and get information to later compile units before the generics are done)
01:00:00 <gamozo> I feel like Rust should do a very fast first pass to generate declarations, and should parallelize way better. I know it's a really hard problem, and they've probably cornered themselves with early design decisions
01:01:00 <gamozo> I think it could be 10xed (improvement of compile times) with no loss of capability. :\ It's not super parallel beyond just, dependency graph stuff at the library level
01:01:00 <Mutabah> Considering that I work on a not-big C++ project that has worse incrmental compile times than my not-small rust kernel project
01:02:00 <Mutabah> I don't quite get why people complain about those
01:02:00 <gamozo> Tbh, I actually think C++ is worst than Rust _on average_. I was just b uilding a small game server last night, ~30-40k LoC, maybe 30-40 1k LoC files, and it took like 20-30 seconds to build. I was confused
01:02:00 <gamozo> (and that was with 1 cpp file per core) probably some macro expansion
01:03:00 <gamozo> Honestly, I just can't live without Rust at this point though. Some of the paradigms I can do are so good. I made an allocator a few weeks ago that allows allocations to be combined into one allocation since the "compiler understands how the allocator works"
01:03:00 <gamozo> I love those aspects of the language.
01:04:00 <gamozo> As an optimization nerd, I can communicate more information to the compiler for it to make better decisions
01:06:00 <gamozo> I think that's what I like about Rust so much. The compiler wants me to get down on its level and help explain what I want to do. Especially around things that compilers are bad at reasoning
01:06:00 <gamozo> The more well defined the behavior, the more the compiler can do!
01:15:00 <geist> oh i think the C compiler people disagree. they loooooove them some undefined behavior
01:17:00 <gamozo> Makes it easy!
01:18:00 <geist> but yeah i really should put more time into rust
01:18:00 <geist> i fiddled with it enough to not be a complete noob, but not yet get to that point where it all clicks
01:20:00 <gamozo> It took me maybe a few weeks to feel okay writing systems stuff, and like 2-3 years to feel comfortable with some of the complexities of unsafe code
01:21:00 <gamozo> There's still some things I'm uncomfy with, like all the crazy aliasing rules and provenance. But some part of me enjoys it
01:44:00 <gamozo> Alright, new bootloader and kernel starts today, it's been too long
01:44:00 <gamozo> I have all the things I wanted to figure out, figured out
02:36:00 <wxwisiasdf> yay, the i370 target for modern gcc works
02:37:00 <wxwisiasdf> 2 days of messing with rtl files :^)
03:35:00 <geist> gamozo: DO IT
03:44:00 <gamozo> I am! I already created the folder, I need a name though
03:45:00 <gamozo> gonna be UEFI too, I made like 1-2 UEFI test OSes since then and I'm sick of my good OS being on BIOS
03:45:00 <heat> bios bad uefi good
03:45:00 <heat> i'm taking the time to properly set up clang-tidy on my project
03:46:00 <zid> uefi bad bios good
03:46:00 <zid> and by bios I actually mean multiboot, install grub via uefi for all I care
03:47:00 <heat> multiboot bad
03:47:00 <heat> linux x86 boot protocol good
03:48:00 <gamozo> I'm just here to skip the BS of real-mode :D
03:48:00 <gamozo> I have to go to ACPI for 99% of stuff anyways, E820 feels bad
03:49:00 <gamozo> I imagine UEFI is less likely to give me a random address overlap in the tables too eh?
03:49:00 <heat> define overlap
03:49:00 <gamozo> Saying memory is free but also in use for the BIOS/tables/devices
03:51:00 <heat> well, it's less likely because the code is less buggy
03:51:00 <heat> since it's all open and nice and reusable
03:51:00 <heat> not the BIOS copyfest 2004
03:51:00 <heat> though early uefi implementations did have some serious bugs
03:52:00 <zid> yea absolutely never touch real mode ever
06:19:00 <No_File> No Arcane Schools
06:19:00 <No_File> No Freemasonry
06:19:00 <No_File> No Bloat
06:19:00 <No_File> Only ~120k lines of simplicity code.
06:19:00 <No_File> Compiler_Fun for everyone!
06:19:00 <No_File> https://imgur.com/JreEh8U
06:19:00 <bslsk05> 'TempleOS DEMO mini_compiler' by [idk] (--:--:--)
06:47:00 <geist> yeah that's some out there stuff
06:50:00 <kazinsal> RIP Terry, walked into a train
06:53:00 <No_File> You know for sure?
07:00:00 <geist> oh absolutely
07:02:00 <kazinsal> yeah, Terry was killed a few years ago when he was hit by a train somewhere in southern Oregon iirc
07:02:00 <kazinsal> dude was homeless and wandering the PNW as a result of his untreated condition
07:02:00 <kazinsal> honestly quite tragic
07:02:00 <geist> yeah totally
07:03:00 <kazinsal> he was quite smart but his unmedicated schizophrenia just drove him into a psychotically hostile personality deeper and deeper as the years went on
07:04:00 <No_File> The point is, did you see him die? Do you believe everything you read?
07:04:00 <kazinsal> I know his parents confirmed his death at the time
07:05:00 <No_File> You can't be sure, and if you claim to be, you are a liar.
07:05:00 <geist> yeah it was pretty well confirmed, i remember it going around
07:05:00 <kazinsal> unless you're claiming to be Terry in which case, self photograph with timestamp and username on paper
07:05:00 <No_File> with checksum ;)
07:05:00 <geist> plus of course terry stopped all output at that point too
07:06:00 <No_File> Your obvious ability to connect things is amazing, keep up the good work.
07:06:00 <kazinsal> yeah, and if there was ever a man who had dedication in his convictions and his passions it was Terry
07:06:00 <geist> yeah
07:12:00 <kazinsal> completely unrelated I'm marathoning the classic Connery Bond films and despite being fairly low budget films from the 1960s (and being extremely 1960s in some aspects) they still hold up quite well
07:14:00 <geist> looks like embargos are up on Zen 4 announcements
07:14:00 <kazinsal> oh nice
07:14:00 <geist> since all the news sites are reporting ryzen 7000 series stuff
07:15:00 <geist> doesn't look like much interesting aside from the usual improvements. only thing different is it seems that the io die will always have some form of gpu on it
07:15:00 <kazinsal> should be handy for DIY servers
07:15:00 <geist> yah
07:16:00 <geist> btw i took the 3950x and put it in another motherboard. will run that for a few days and see if it gets crashy
07:16:00 <kazinsal> hopefully it turns out to be just a PSU issue and not the CPU
07:17:00 <geist> yah, i mean if it doesn't fail in the other mobo that doesn't tell me muich but at least it doesn't tell me anything overtly bad
07:18:00 <kazinsal> been thinking about what I want to do with regards to my next build since I want to retire my old sandy bridge server
07:19:00 <kazinsal> not sure if it'll be a 7000 series or a discounted 5000 series
07:20:00 <kazinsal> or maybe build a new PC with a 7000 series and an RTX 3080 and relegate my 8700K to VMware duty
07:23:00 <geist> yah the difference being the new stuff will be AM5 based and need DDR5
07:23:00 <geist> so that'll be a price hike for a while
07:23:00 <kazinsal> yeah that'll be a tricky one
13:28:00 <mrvn> gamozo: you think a system where the bios gives a bad memory map has any higher quality code for the uefi to generate a memory map?
14:21:00 <mjg> https://v.redd.it/i4xk15o8z5191 something for locals
14:21:00 <bslsk05> 'i4xk15o8z5191' by [idk] (--:--:--)
16:43:00 <heat> mrvn, a system that has a bios that generates a bad memory map doesn't have UEFI :)
16:50:00 <heat> fwiw UEFI firmware needs a valid memory map without overlaps since the memory map is literally the internal memory allocator structure
18:32:00 <Bitweasil> geist, I saw the integrated GPU, that'll be nice. Though it seems that at least some of the AMD boards don't mind running headless.
18:32:00 <Bitweasil> I've got one of my compute heaters running with no graphics output at all, not even for POST, and it's remarkably tolerant of it.
18:32:00 <Bitweasil> "Puts some pixels on the screen!" grade integrated GPUs are nice, though.
18:33:00 <zid> zen4 has quad channel and 5ghz, I am sold
18:34:00 <heat> what happened? zen4 announcement?
18:34:00 <Bitweasil> Yeah.
18:34:00 <Bitweasil> https://www.anandtech.com/show/17399/amd-ryzen-7000-announced-zen4-pcie5-ddr5-am5-coming-fall
18:34:00 <heat> epic
18:34:00 <bslsk05> www.anandtech.com: AMD Ryzen 7000 Announced: 16 Cores of Zen 4, Plus PCIe 5 and DDR5 for Socket AM5, Coming This Fall
18:34:00 <heat> more cores or just more ghz?
18:34:00 <Bitweasil> New socket, DDR5, PCIe 5, and integrated GPUs.
18:34:00 <Bitweasil> New cores, moar GHz.
19:02:00 <ckie> geist: i have started!
19:03:00 <ckie> so far the part of the plan where i collect things about i don't like C is /very/ successful
19:03:00 <ckie> i don't like about C*
19:19:00 <gamozo> mrvn: Hopefully yes, because they probably didn't write the UEFI code (probably forked EDK or something)
19:20:00 <gamozo> and they didn't do 64-bit address math using 16-bit real mode in some hacky compiler (maybe)
19:23:00 <geist> Bitweasil: yeah i discovered that the other day too. i removed the token vid card fro the server and figured it wouldn't boot but it ran just fine
19:23:00 <geist> maybe thats a function of UEFI, since there's no assumption that there is a screen
19:23:00 <geist> vs bios which at least provides the bios hooks to draw to it, etc
19:24:00 <geist> not that bios particularly *mandates* that there's a vga/cga/mda display there, but there's a basic assumptio that there is
19:35:00 <Bitweasil> "Error, no keyboard attached! Press F1 to continue!"
19:36:00 <Bitweasil> Servers can generally redirect to serial, but this is just a random "gamer" board I got, and it's fine with it.
19:36:00 <geist> yah same
19:36:00 <Bitweasil> I mean, I keep a GPU around to toss in, but it means I can have my "utility GPU" and several compute boards without having to toss a GPU in each of them.
19:36:00 <Bitweasil> Saves me some money and clutter.
19:37:00 <Bitweasil> Though those Wraith coolers are quite garish.
19:39:00 <geist> aww i like em
19:40:00 <Bitweasil> They make it easy to see when the system is powered on when it's a bare board, for sure!
19:40:00 <Bitweasil> But I just don't like the whole "RGB all the things!" trend in computers.
20:49:00 <heat> ye can thank tianocore
20:50:00 <heat> your only guaranteed output is just a text pipe (tty-like)
20:50:00 <heat> you can find GOP protocols, but that's not guaranteed
20:54:00 <Griwes> that ryzen 7000 ihs is the weirdest ihs design I've seen
21:02:00 <wxwisiasdf> hi i have a question, where do i place my libc so my cross compiler toolchain uses my OS libc
21:03:00 <wxwisiasdf> so i can build gcc using the cross compiler and port it to le os
21:03:00 <heat> in your sysroot
21:03:00 <wxwisiasdf> yeah where
21:03:00 <wxwisiasdf> (cross)/lib?
21:03:00 <heat> maybe
21:03:00 <heat> only you know the answer
21:03:00 <heat> not (cross) though
21:03:00 <heat> you're supposed to pass --sysroot=$SYSROOT
21:03:00 <wxwisiasdf> oh oh
21:03:00 <heat> don't modify the compiler's internal stuff
21:04:00 <wxwisiasdf> we didn't pass sysroot
21:04:00 <wxwisiasdf> :(
21:05:00 <wxwisiasdf> time to rebuild :D
21:09:00 <heat> https://github.com/heatd/Onyx/blob/master/scripts/setup_package_build_env.sh
21:09:00 <bslsk05> github.com: Onyx/setup_package_build_env.sh at master · heatd/Onyx · GitHub
21:09:00 <heat> this works for autoconf stuff
21:09:00 <heat> and makefiles in general
21:09:00 <heat> cmake and meson are more fidly and require cross files
21:16:00 <mrvn> /usr/lib/<arch>-<kernel>-<libc>
21:18:00 <heat> that's debian multilib-ish
21:18:00 <mrvn> multiarch
21:18:00 <mrvn> multilib is the gcc thing that's horrible
21:19:00 <heat> that's multilib
21:19:00 <heat> it's the same thing
21:20:00 <mrvn> it'c totally different. The arch tripplet has been around for ages too
21:26:00 <mrvn> The sysroot thing won't work if you have to build local tools used to compile something, Or not on it's own. sysroot is just a low level chroot, it doesn't solve the problem of needing different libcs to cross compile software with mor complex build systems.
21:30:00 <heat> what are you on about
21:30:00 <heat> of course it won't
21:30:00 <heat> you're not suposed to store local tools to the sysroot
21:31:00 <heat> it does solve the problem of needing different libcs do cross compile software because the libc is literally there
21:31:00 <heat> sysroot/usr/lib/libc.a <-- the compiler looks here
21:33:00 <heat> i seriously don't know why you're talking about debian multilib, it's literally only used in debian and co.
21:33:00 <heat> cross compilation works everywhere, always has
21:33:00 <heat> no multilib in debian style
21:33:00 <heat> you give it a sysroot, and boom, bob's your uncle
21:34:00 <heat> if it needs to execute local programs, it should compile them (not with CC, not with CFLAGS; these compilations have special variables like CC_FOR_BUILD in autotools)
21:35:00 <heat> if you're using cmake or meson, you pass it a platform/cross file that tells it how *your* platform works
21:35:00 <heat> if it needs to compile things for the host, it uses the host's platform file
21:44:00 <mrvn> heat: and your systems CC will have sysroot configured to build for x86, x86_64 and x86_32? Or thumb, armv7 and aarch64?
21:45:00 <mrvn> and aarch64_32 or whatever the shorter pointer thing is called on aarch64
21:45:00 <heat> my OS? no, it just uses the sysroot the package build system wants it to use
21:46:00 <heat> if the package build system tells it to use a x86_32 sysroot, it does that
21:46:00 <mrvn> I kind of like having "gcc -m32" just work.
21:48:00 <heat> great!
21:48:00 <heat> now make it work on every system
21:48:00 <heat> oh wait you can't because every system does everything differently
21:49:00 <mrvn> I try but you seem to be working against it
21:49:00 <mrvn> do you use .../include/<arch>-<os>-<libc>?
21:50:00 <mrvn> The lib thing can be said to be a bit new, only 2 decades old now. But include has been around since whenever.
21:50:00 <heat> no, my system uses /usr/$triple
21:50:00 <heat> *shrug*
21:51:00 <mrvn> at least that doesn't conflict.
21:52:00 <heat> no one can agree on the multilib format, every multilib sucks and musl explicitly doesn't support multilib at all
21:52:00 <mrvn> and again: multilib is the horrible gcc thing. It's called multiarch
21:53:00 <heat> oh right, instead of being the thing you use to install libs with another configuration it's... the thing you use to install libs with another configuration
21:54:00 <mrvn> instead of the thing where the path is different on every arch and system it's the one where the path is always the same. yes.
21:54:00 <heat> so it's slightly different
21:54:00 <heat> how is /usr/$triple much worse than /usr/include/$triple and /usr/lib/$triple
21:55:00 <mrvn> heat: because on the nxt system its' /usr/lib/ and /usr/lib64 and the next it's /usr/lib and /usr/lib32 and so one.
21:56:00 <heat> and on the next system it's /usr/lib/$triple
21:56:00 <heat> *shrug*
21:56:00 <heat> you're trying to convince me debian's solution is the best because it's the one you use
21:57:00 <mrvn> The choice of /usr/include/$triple was made because a) compilers already supported and b) it allows sharing headers and libs that aren't architecture specific.
21:58:00 <mrvn> If you use /usr/$tripple that's ok by me. As long as it's not the lib32 / lib64 crap.
22:21:00 <heat> how do I put something at the end of my binary?
22:21:00 <heat> in blob format
22:23:00 <heat> I want to get a piece of code in the reset vector
22:24:00 <heat> so 0xfffffff0
22:27:00 <geist> usually i literally cat it to the end of it and then if you have a symbol in your linker script that's off the end you can assume it's address is where your binary got blatted
22:28:00 <geist> but obvious issue there is bss and f it's going to blow over your thing
22:30:00 <mrvn> and making the image large enough that the data ends up at 0xfffffff0 physical would make it rather big.
22:31:00 <heat> yes but this is firmware, it's starting up there anyway
22:32:00 <mrvn> Just put it anywhere in .rodata or .data with start/end symbols. If's page sized then map it, otherwise copy it.
22:32:00 <heat> i can't map it
22:32:00 <heat> this is firmware
22:32:00 <mrvn> if' you are already there then set "."
22:32:00 <mrvn> . = 0xfffffff0; <blob section>
22:35:00 <mrvn> There is an alternate syntax thingy for rom/flash images where you define memory regions and assign sections to regions and such but I never managed to understand that fully.
22:39:00 <geist> yah same. i tried to convert my linker scripts to it
22:39:00 <geist> but i seemed to remember hitting some roadblock but i forget what it was
23:10:00 <heat> how do I do a 32-bit jump backwards in 16-bit mode?
23:10:00 <heat> actually can I even
23:11:00 <heat> lets see if I can golf the switch to 32-bit
23:13:00 <gamozo> you can
23:13:00 <gamozo> oh, misread nvm
23:18:00 <zid> I'm only allowing you 20bit jumps until you show you can handle that much heat