channel logs for 2004 - 2010 are archived at http://tunes.org/~nef/logs/old/ ·· can't be searched
#osdev2 = #osdev @ Libera from 23may2021 to present
#osdev @ OPN/FreeNode from 3apr2001 to 23may2021
all other channels are on OPN/FreeNode from 2004 to present
http://bespin.org/~qz/search/?view=1&c=osdev2&y=23&m=1&d=2
00:08:00 <epony> the good of APM
00:13:00 <kaichiuchi> nice.
00:13:00 <kaichiuchi> i reboot into arch linux and half of the desktop is broken
00:13:00 <kaichiuchi> my only crime? pacman -Syu
00:14:00 <heat> how?
00:15:00 <kaichiuchi> well I rebooted again and suddenly everything is working
00:15:00 <kaichiuchi> so no idea
00:16:00 <heat> your system is weird
00:16:00 <kaichiuchi> that's what every linux person says
00:16:00 <epony> because you have services like messagebus / dbus which need to start early with the session
00:16:00 <kaichiuchi> also why do I need to unplug my transceiver for my G502 HERO and plug it back in to move my mouse
00:17:00 <kaichiuchi> don't have to do that with windows, never had to do that with freebsd
00:17:00 <epony> desktoys are like that, have extra services for middleware IPC / RPC which is the source of EVIL and HELL
00:18:00 <epony> that's entirel to immitate signalling and ole and drag-drop and other perversions
00:18:00 <heat> shrug
00:18:00 <epony> which get you stuffed badly
00:18:00 <heat> listen, if I had a system that broken I would also not use linux
00:19:00 <heat> or would just use a distro that worked
00:19:00 <kaichiuchi> I swear in the name of rms, linus torvalds, alan turing, I am doing absolutely nothing crazy
00:19:00 <epony> frightnight scare https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=dbus
00:19:00 <bslsk05> cve.mitre.org: CVE - Search Results
00:19:00 <epony> it's not you, it's FDO
00:20:00 <epony> (Free Drugs Orgy)
00:20:00 <epony> stuffey pulley https://en.wikipedia.org/wiki/Freedesktop.org#Other
00:20:00 <bslsk05> en.wikipedia.org: freedesktop.org - Wikipedia
00:22:00 <epony> you really like pango and cairo the most
00:22:00 <epony> and rsvg
00:22:00 <kaichiuchi> i have no idea what you're saying
00:23:00 <epony> something like "you can't breathe" in desktoyspeak
00:23:00 <epony> read up on dbus from the last link
00:23:00 <epony> it'll get your hair up
00:26:00 <epony> it uses XML (wtf) you know from the billion laughs fame https://en.wikipedia.org/wiki/Billion_laughs so it's really fun to work with it from the human reviewer perspective
00:26:00 <bslsk05> en.wikipedia.org: Billion laughs attack - Wikipedia
00:27:00 <j`ey> kaichiuchi: most other ppl have /ignored them btw
00:27:00 <epony> and dbus has like monthly expoits
00:27:00 <epony> you can ignore dbus too ;-) but it is not ignoring you
00:27:00 <epony> it gets you stuffed early with systemd
00:28:00 <epony> that's why people hate Redhat
00:30:00 <epony> you have the same on Windows though, that's where these concepts were invented you just "relogin" / restart your desktop or it crashes / freezes / reboots you / nothing until it locks up
00:30:00 <kaichiuchi> template <unsigned int Bit, typename Type>
00:30:00 <kaichiuchi> constexpr void BitSet(Type& value) noexcept {
00:30:00 <kaichiuchi> static_assert(Bit <= gbstl::numeric_limits<Type>::digits());
00:30:00 <kaichiuchi> value |= (1 << Bit);
00:30:00 <kaichiuchi> }
00:31:00 <kaichiuchi> I hate everything about this and it is so stupid
00:31:00 <kaichiuchi> also, just `digits`
00:31:00 <epony> FreeBSD is a bit less stupid than Linux so it does not have systemd but a shim, but the desktoy stupidity is there front and center
00:31:00 <kaichiuchi> is there some magic that I'm missing where I don't have to do BitSet<666>(i) and I can just do BitSet(i, 666);
00:32:00 <heat> you never had to?
00:32:00 <kaichiuchi> not according to the compiler
00:33:00 <heat> constexpr void BitSet(Type& value, uint bit) { value |= (1UL << bit); }
00:33:00 <kaichiuchi> but I can't use `bit` in a static_assert now
00:33:00 <kaichiuchi> unless you mean "the compiler will throw the warning don't even bother"
00:35:00 <heat> why do you care?
00:35:00 <kaichiuchi> why wouldn't I care?
00:36:00 <kaichiuchi> if someone accidentally hits 8 or 9 on their keyboard if they're working with a uint8_t, I want that trapped
00:36:00 <heat> fsanitize=undefined + fsanitize-trap
00:36:00 <heat> in a constant expression, that will just warn
00:36:00 <kaichiuchi> but I could stop it before ever getting to that point
00:37:00 <heat> <source>:4:14: warning: left shift count >= width of type [-Wshift-count-overflow]
00:37:00 <heat> 4 | return 1 << 40;
00:37:00 <kaichiuchi> yes
00:37:00 <heat> this is a non-issue
00:37:00 <kaichiuchi> probably
00:37:00 <heat> this is why C++ sucks
00:37:00 <heat> people try to overengineer the shit out of things
00:37:00 <kaichiuchi> hey
00:38:00 <kaichiuchi> I *did* say that the compiler would indeed have a warning
00:38:00 <kaichiuchi> but this isn't a "warning", this is an "error", but I suppose that's why you use -Werror
00:38:00 <kaichiuchi> i dunno how that isn't an error already
00:38:00 <heat> -Werror=shift-count-overflow
00:38:00 <kaichiuchi> yeah yeah
00:40:00 <j`ey> doesnt work through a function call
00:40:00 <heat> fsanitize=undefined + fsanitize-trap
00:40:00 <kaichiuchi> i hate C++.
00:41:00 <j`ey> you just want template arguments to look like normal ones
00:41:00 <kaichiuchi> yes
00:41:00 <kaichiuchi> that is correct
00:41:00 <j`ey> make it a macro1
00:41:00 <heat> please stop
00:41:00 <kaichiuchi> because BitSet<4>(ndflslkdfl); looks like hell
00:41:00 <kaichiuchi> because "4" isn't a type
00:41:00 <heat> having a BitSet is useless
00:42:00 <kaichiuchi> well it's certainly not going to hurt anything
00:43:00 <heat> your compile time will suffer, the readability will suffer
00:43:00 <kaichiuchi> why would the readability suffer? surely people know what this is doing
00:43:00 <kaichiuchi> it sets a bit `b` in an integral type `t`
00:43:00 <j`ey> so does: t |= (1 << b)
00:43:00 <heat> yes, with an in-out reference parameter?
00:44:00 <heat> ^^
00:44:00 <kaichiuchi> the hope was that it quite literally functions like a regular macro if I use a reference
00:44:00 <kaichiuchi> wtf do you want me to do, say `var = BitSet(var, 4);`?
00:45:00 <heat> that would make more sense
00:45:00 <kaichiuchi> these sorts of functions/macros/etc are nothing new though
00:46:00 <kaichiuchi> i've seen plenty of BIT_TEST, BIT_SET, BIT_CLEAR etc macros in C code
00:46:00 <heat> and it's a bad idiom
00:47:00 <kaichiuchi> what I have as well is an "extract value from bit range" function
00:47:00 <kaichiuchi> so I can say "get the value between bits 5 and 10"
00:47:00 <kaichiuchi> and the compiler will auto-generate the appropriate masks and shifts
00:47:00 <kaichiuchi> are you going to say that's a bad idiom as well?
00:47:00 <heat> it just seems unuseful to me
00:48:00 <heat> if you're doing bit manip without a solid understanding of shifts, masks, whatever, tough luck
00:49:00 <heat> I don't think I've gotten a single bug on one of my manual bit shifting or masking
00:49:00 <heat> and I've written plenty of drivers
00:49:00 <heat> so what do you get exactly? slow compiles?
00:49:00 <heat> less readable things?
00:49:00 <kaichiuchi> i'm really struggling to understand why it's less readable, or how that would lead to a slow compile time
00:50:00 <heat> the compiler needs to run a whole fucking constexpr evaluator for your BitSet
00:50:00 <heat> or instantiate a whole template and then run a whole constexpr evaluator
00:50:00 <kaichiuchi> I guess that's fair
00:51:00 <heat> it's less readable because BitSet(value, bit) is a weird pattern compared to language standard features like |= (1UL << bit);
00:51:00 <kaichiuchi> fine then, but I'm keeping my SetOrClearBitIf template
00:51:00 <heat> hm?
00:51:00 <kaichiuchi> if (cond) { bit_set(value, b); } else { bit_clear(value, b); }
00:51:00 <heat> ok
00:52:00 <heat> if you start getting into weird helpers like BitSet a great number of questions come into mind like "how do you compose this?" and "how do you set multiple bits"
00:52:00 <kaichiuchi> I guess
00:54:00 <kaichiuchi> well, I can see the argument
00:55:00 <kaichiuchi> you can still type the wrong bit in BitSet, so how much are you really helping anyway
00:56:00 <heat> also fwiw bit fields are a thing if you really want "easy" bit manip
00:57:00 <kaichiuchi> yeah but I'd rather not use bit fields
00:57:00 <kaichiuchi> in this case, anyway
01:00:00 <zid> bit fields are shitty unfortunately
01:01:00 <zid> order is unspecified and codegen is often bad
01:08:00 <zid> peko
01:11:00 <heat> https://clang.llvm.org/docs/LanguageExtensions.html#builtin-dump-struct
01:11:00 <bslsk05> clang.llvm.org: Clang Language Extensions — Clang 16.0.0git documentation
01:14:00 <kaichiuchi> i am seriously ready to punch myself in the nose
01:14:00 <kaichiuchi> and put on a clown mask
01:19:00 <kaichiuchi> that's it, that's it, I'm done, I can't do this anymore
01:19:00 <kaichiuchi> fuck C++
01:19:00 <heat> ok
01:20:00 <kaichiuchi> my fancy operator overloading is just killing me now.
01:20:00 <kaichiuchi> I'm starting to think you guys are right
01:20:00 <zid> C++'s great, until you try to use two features at once :P
01:20:00 <kaichiuchi> no one makes actual die hard usage of every feature known to man
01:21:00 <kaichiuchi> at some point, it just gets really distressing
01:23:00 <kaichiuchi> especially when you have "no viable operator=" and you look why and it's 400 lines of nonsense
01:28:00 <zid> https://cdn.discordapp.com/attachments/136321206260334593/1059281258120740965/image.png
01:34:00 <pogchamp> zid
01:34:00 <pogchamp> moth day
01:34:00 <zid> moth day.
01:55:00 <epony> Try Rust instead of C++ and discover your inner feminine side..
01:57:00 <epony> real programmers don't write in.. corporate-owned languages
03:09:00 <Clockface> rust seems more corprate owned than C++?
03:09:00 <Clockface> it seems more centralized and i think mozilla is behind a lot of it?
03:10:00 <kaichiuchi> also
03:10:00 <Clockface> although mozilla is a nonprofit
03:10:00 <kaichiuchi> can someone tell me why C++ doesn't have native restrict support
03:10:00 <kaichiuchi> that's actually bonkers
03:10:00 <Mutabah> "native restrict"?
03:10:00 <kaichiuchi> it doesn't officially support the restrict keyword
03:10:00 <kaichiuchi> you need __restrict or __restrict__
03:11:00 <Clockface> what does restrict do?
03:11:00 <Mutabah> Likely because it forked from C before then, and nobody has proposed adding it
03:11:00 <Mutabah> Clockface: Flags the pointer as being the only (visible) way of getting access to a value
03:11:00 <Clockface> that sounds useful for projects with lots of random programmers
03:11:00 <Clockface> that does sound like a good feature
03:11:00 <kaichiuchi> it's useful for performance and auto-vectorization
03:11:00 <Mutabah> however... can lead to UB if that assumption is violated
03:12:00 <kaichiuchi> i'm going to shamelessly copy the example from wikipedia
03:13:00 <kaichiuchi> Clockface: https://godbolt.org/z/G1z5c9Y3d
03:13:00 <bslsk05> godbolt.org: Compiler Explorer
03:13:00 <Mutabah> Note: All rust borrows/references/&-ptrs are tagged `restrict` at the LLVM layer
03:14:00 <Mutabah> (which the compiler can do, because the borrow rules get the frontend to enforce the rules
03:14:00 <kaichiuchi> it just strikes me as madness that one of the features that made C on par with FORTRAN performance is just... nonexistent in C++
03:14:00 <Clockface> C++ is supposed to have every feature
03:14:00 <kaichiuchi> there's an open-std article where someone is openly baffled by this
03:15:00 <kaichiuchi> and says "it makes a difference. please use it."
03:15:00 <Clockface> why would it not have something?
03:15:00 <kaichiuchi> because it's "safe"
03:15:00 <Clockface> C++ is trying to be safe?
03:15:00 <Clockface> i thought it was C with free crap
03:16:00 <Mutabah> Nope. C++ is not a superset of C
03:16:00 <Clockface> thats how i always thought of it
03:16:00 <Mutabah> (They are very close to it... but not quite)
03:17:00 <kaichiuchi> the lack of restrict makes me wonder if C++ is actually forever slower than FORTRAN
03:17:00 <kaichiuchi> unless someone is piling on __restrict__ everywhere they can
03:18:00 <kaichiuchi> well everywhere where it matters
03:23:00 <heat> restrict makes 0 difference
03:23:00 <heat> except where it actually matters, which is rare
03:28:00 <kaichiuchi> https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3988.pdf
03:28:00 <kaichiuchi> "There is no question that the restrict qualifier benefits compiler optimization in many ways, notably allowing improved code motion and elimination of loads and stores. Since the introduction of C99 restrict, it has been provided as a C++ extension in many compilers. But the feature is brittle in C++ without clear rules for C++ syntax and semantics."
03:35:00 <heat> i'm calling bullshit on that one
03:36:00 <kaichiuchi> i'm not
03:36:00 <kaichiuchi> the restrict keyword was added in response to FORTRAN being faster
03:36:00 <heat> i have not seen a non-libc project that actively uses restrict
03:36:00 <kaichiuchi> because it's kinda... hard
03:36:00 <heat> strict aliasing takes good care of you not needing restrict
03:36:00 <kaichiuchi> hard to guarantee in the future that `a` won't alias `b`
03:37:00 <kaichiuchi> https://godbolt.org/z/xTrjGWKEE
03:37:00 <bslsk05> godbolt.org: Compiler Explorer
03:37:00 <kaichiuchi> here's an example of it working
03:40:00 <kaichiuchi> pretty sure ulrich drepper has said to use it too
03:41:00 <kaichiuchi> https://lwn.net/Articles/255364/
03:41:00 <bslsk05> lwn.net: Memory part 5: What programmers can do [LWN.net]
03:41:00 <kaichiuchi> The rest of the complication here results from the fact that gcc is not very smart when it comes to optimizing array indexing. The introduction of the additional variables rres, rmul1, and rmul2 optimizes the code by pulling common expressions out of the inner loops, as far down as possible. The default aliasing rules of the C and C++ languages do not help the compiler making these decisions (unless restrict is used, all pointer accesses are
03:41:00 <kaichiuchi> potential sources of aliasing). This is why Fortran is still a preferred language for numeric programming: it makes writing fast code easier. {In theory the restrict keyword introduced into the C language in the 1999 revision should solve the problem. Compilers have not caught up yet, though. The reason is mainly that too much incorrect code exists which would mislead the compiler and cause it to generate incorrect object code.}
03:42:00 <kaichiuchi> ok, he didn't say to USE it, but he said there's a solution in theory
03:45:00 <heat> https://cs.github.com/?q=repo%3Atorvalds%2Flinux+%22restrict%22&p=1&pt=41f10601ad0849af8bb6b8ebd8cd8cd9fb924a80d27477fac228343e7cd7c5415042cc54c5a3cb0f51b811b62bcbffac7f8e8ba3a5c45df096b17199aab49d05f2f51a531edf45ee6f28180fd4326caff2193c53cc621dece2056c8bf3223f96b1f89bbf16d2db4c2dd35bbd76ce938ec7a356bf46e3d62c0f9ac25a8e6880d9829f20a1f78ad6b1988f6a4cc60c90f3c8ae7c89ed3b8dc84fb566eaf75778d3769eedeba7fb8ddb7fbd060ddbe1aacca63154e083f31919adcea0fe08f5f8302
03:45:00 <heat> 1ca0a833c1e7122c05b4fb7d54f73c565a7877300d2703e0b881b04b9771ba14448758f83f49918860b2dcf4175dce33047a6fb79dd201ca3a165aeb616870a65430f317a269db0fe8765c4be71a03cd08f864f7ac778aedeb2bc9a803de588fba82d36352290baf7767bf2bed0380c4f72376671e165b0d4b5b02be007b8a4db89523013f1b2ad10e00c626175f2c5245cc650f7dd8af002c8a7127ab29eae8c81806c0745aedebd02cb0e2298fe3a001f4e0536cf0f155a99b8f6b79a89d5775f1ddeeda71fdf7c44b7aefc61cc02&scope=&scopeName=All+repos
03:45:00 <bslsk05> cs.github.com: GitHub Code Search (Preview)
03:45:00 <heat> omg
03:46:00 <kaichiuchi> i can't log in
03:46:00 <kaichiuchi> .
03:46:00 <kaichiuchi> what does it say
03:46:00 <heat> https://cs.github.com/?q=repo%3Atorvalds%2Flinux+%22restrict%22
03:46:00 <bslsk05> cs.github.com: GitHub Code Search (Preview)
03:46:00 <heat> more manageable
03:46:00 <heat> it's not used in linux, that's the point
03:46:00 <kaichiuchi> that doesn't mean it's useless
03:47:00 <kaichiuchi> I think there's even a switch in ICC where you can guarantee "no pointer anywhere will ever alias another"
03:47:00 <heat> it does not, but if speed itself does not use it, what does that make of it?
03:48:00 <kaichiuchi> it means that linux is a majorly huge complicated project and they have every right to be scared of using restrict
03:48:00 <zid> they don't need it
03:48:00 <zid> they have aliasing optimizations off
03:48:00 <heat> no, they have strict aliasing off
03:48:00 <kaichiuchi> I can only say that when it comes to code generation, it absolutely makes a difference
03:48:00 <heat> I'm fairly sure __restrict is still required
03:49:00 <zid> strict-aliasing is off because they write code that aliases pointers, which disables optimizations based on whether pointers alias or not
03:49:00 <zid> effectively they have everything marked anti-restrict
03:49:00 <heat> except pointers with the same type
03:49:00 <zid> "This shouldn't ever alias but I'm going to do it anyway lol"
03:50:00 <heat> https://godbolt.org/z/6d1zx9T57
03:50:00 <bslsk05> godbolt.org: Compiler Explorer
03:50:00 <kaichiuchi> yes
03:50:00 <kaichiuchi> that's mine
03:50:00 <kaichiuchi> oh no it isn't
03:50:00 <heat> with fno-strict-aliasing attached
04:59:00 <sonny> how do I know what architectures openfirmware supports?
05:02:00 <CompanionCube> depends on the implementation, doesn't it?
05:04:00 <heat> why do you care about openfirmware?
05:05:00 <sonny> I'm interested in bootloaders
05:05:00 <sonny> CompanionCube good point
05:08:00 <geist> hmm, wonder if openfirmware is developed anymore
05:08:00 <geist> it's been pretty dead since sun and apple stopped using it, AFAIK
05:09:00 <geist> though i suppose there may still be some sun sparc boxes being made?
05:10:00 <sonny> I thought sparc was dead, but who knows
05:10:00 <kazinsal> oracle stopped doing new sparc stuff but fujitsu still sells sparc boxes
05:16:00 <geist> wikipedia says that ibm power boxes have openfirmware
05:16:00 <geist> well, looks like there is a sun drop though https://github.com/openbios/openboot
05:16:00 <bslsk05> openbios/openboot - Sun's OpenBoot implementation of OpenFirmware (6 forks/25 stargazers)
05:17:00 <geist> hmm, looks like it has a bunch of binaries in it, probably solaris binaries
05:18:00 <geist> looks like some other ones in that same part of github
05:26:00 <heat> i can't get riscv interrupts and I don't know why
05:27:00 <heat> the timer works, the interrupts are enabled in sstatus, but the plic doesn't deliver
05:27:00 <heat> i've even patched qemu with trace calls, they seem to be getting the interrupts and forwarding them on
05:28:00 <zid> time to check every branch
05:28:00 <zid> be the american fuzzy lop you always dreamed you could be
05:33:00 <heat> nah, not american
05:52:00 <heat> omfg
05:52:00 <heat> i found it
05:52:00 <heat> there's a separate interrupt enable register apart from sstatus
05:53:00 <heat> and there I had only enabled timer interrupts not external ones
05:53:00 <heat> shoot me
05:53:00 <sonny> bang
05:59:00 <geist> yeah there are really like 3 or 4 real interrupts on riscv, and timer is one of the special ones
05:59:00 <geist> all external ones are another vector
06:00:00 <heat> what screwed me over is that I forgot sie was a thing
06:02:00 <geist> yah and there's that whole scheme where the M mode can override it from S mode
06:33:00 <vai> unhandled interrupts and exceptions cause my kernel to crash
06:33:00 <vai> I am doing a 386 compatible kernel / OS
06:33:00 <vai> on real HW like 486 it runs like a charm
06:36:00 <geist> you should at least mask off everything you can't handle
06:36:00 <geist> but you should also install at least a handler per vector that does nothing if nothing else
06:44:00 <vai> geist: yeah got handlers iret
06:44:00 <vai> lol
06:45:00 <vai> probably fscks up because I am using legacy 8086 interrupt vectors
06:45:00 <vai> on pm
06:45:00 <vai> PIT instead of APIT
06:45:00 <vai> real HW today simply has so many interrupts exceptions
06:46:00 <heat> hrm?
06:49:00 <heat> [root@Onyx /] $ uname -a
06:49:00 <heat> Onyx Onyx onyx-rolling SMP Jan 2 2023 06:46:39-UBSAN riscv64
07:00:00 <geist> Woot
07:01:00 <geist> Actual SMP too?
07:09:00 <kazinsal> me, less than 36 hours before my vacation ends: oh shit I forgot I said I was going to do some osdev stuff over the holidays
07:20:00 <klys> want to talk about it
07:33:00 <geist> kazinsal: yeah i know exactly what you mean
07:33:00 <geist> it's that stupid head anxiety you get about not fully utilizing your break
07:34:00 <geist> which is a dumb way to ruin a break
07:34:00 <klys> hny
08:10:00 * CompanionCube always forgets that IBM uses openfirmware, and QEMU has OpenBIOS/SLOF for it, in addition to sun's openboot and mitch bradley's own implementation on github
08:31:00 <vai> https://www.beningo.com/3-tips-for-speeding-up-interrupt-handlers/
08:31:00 <bslsk05> www.beningo.com: www.beningo.com | 520: Web server is returning an unknown error
08:33:00 <vai> GPIO?
08:34:00 <vai> interesting https://xilinx.github.io/Embedded-Design-Tutorials/docs/2021.1/build/html/docs/Introduction/ZynqMPSoC-EDT/7-design1-using-gpio-timer-interrupts.html
08:34:00 <bslsk05> xilinx.github.io: Design Example 1: Using GPIOs, Timers, and Interrupts — Embedded Design Tutorials 2021.1 documentation
08:45:00 <kof123> general purpose i.e. that is available for you to use for any purpose?
08:46:00 <kof123> probably more an "embedded" thing
08:59:00 <zid> pigchomper
09:00:00 <vai> kof123: https://www.intel.com/content/www/us/en/develop/documentation/tcc-tools-2021-2-developer-guide/top/time-synchronization-and-communication-tools/time-aware-gpio-tgpio-samples.html
09:00:00 <bslsk05> www.intel.com: Time-Aware GPIO (TGPIO) Samples
09:00:00 <kazinsal> gogchamp
09:00:00 <vai> examples are software timers
09:00:00 <vai> hardware accelerated GPIO timers not available on todays Intels
09:00:00 <vai> I think?
09:00:00 <vai> Always Turned On TImers
09:04:00 <vai> AMD has a "development mode" this might exist
09:06:00 <vai> hackety whackety with NMI ? hehe
13:12:00 <kaichiuchi> hi
13:14:00 <sham1> Hi
13:16:00 <Ermine> \o/
16:30:00 <ddevault> want: wiki specifically focused on documenting hardware, target audience driver authors
16:32:00 <ddevault> quality should aim for a spec but would ideally also provide some information in prose regarding common tasks you can do with that hardware or outlining possible incremental routes towards a working driver
16:34:00 <zid> I always like a good 'basic prinmciples of use/operation' paragraph
16:35:00 <zid> There's a lot of stuff that's hard to understand just given a weird hw api
16:35:00 * ddevault gently weeps from the bottom of a pile of intel HD graphics manuals
16:36:00 <ddevault> after 2-3 hours of reading those I still don't know how to make the GPU do literally anything
16:39:00 <Ermine> Seems like you need to be a pioneer in writing such an article
16:40:00 <ddevault> 'course
16:45:00 <ddevault> MSI is unclear to me
16:45:00 <ddevault> which IRQ is it going to actually fire?
16:46:00 <clever> ddevault: i think MSI is just configuring the device to write X to addr Y, you then need to set Y to the irq controller, and configure the irq controller so that it routes that to a given irq#
16:49:00 <clever> and what exactly it can route to, depends on the irq controller
16:50:00 <ddevault> I'm just going to do the classy thing and forget about it until I'm actually ready to do SMP
16:54:00 <Ermine> So what are you going to do then?
16:54:00 <ddevault> if I don't enable the I/O APIC then I can just use the PCI interrupt fields
18:39:00 <jimbzy> Hi gog
18:39:00 <gog> hi
18:39:00 <jimbzy> Feeling any better?
18:41:00 <zid> chomped some pigs, feeling fine
18:42:00 <zid> (I didn't chomp a pig, I chomped a cow)
18:42:00 <kaichiuchi> hi
18:46:00 <jimbzy> Hey kaichiuchi!
18:46:00 <jimbzy> How's it going?
18:51:00 <zid> we're deprogramming him
18:56:00 <jimbzy> zid, Good luck. The channel has been working on me for like 20 years and I still ain't right. :P
19:00:00 <zid> He had a crisis in confidence recently
19:01:00 <jimbzy> He was probably listening to people, and that's always a bad idea.
19:02:00 <jimbzy> "People like Coldplay and voted for the Nazis, you can't trust people." --Super Hans
19:02:00 <zid> https://aras-p.info/img/blog/2018/cpp_phases.jpg we've gotten him from #3 to #4
19:04:00 <jimbzy> Nice.
19:15:00 <heat> geist, nah, no SMP yet. I haven't dabbled with that
19:16:00 <zid> so your uname is just outright lies
19:16:00 <zid> Did you fix all the bugs in onyx yet?
19:16:00 <heat> i did take like 30m-1h to actually reach functioning userspace because linux has differing ABIs between architectures on struct stat
19:16:00 <heat> it's nuts
19:16:00 <heat> I don't see a valid reason for this, but it's there
19:17:00 <heat> zid, i have not fixed the bugs
19:18:00 <zid> good boy
19:18:00 <zid> Fixing bugs isn't very rockstar afterall
19:18:00 <zid> you need to add flashy new technologies
19:22:00 <Ermine> aren't abis meant to be different on different architectures?
19:22:00 <heat> why would they?
19:23:00 <mjg> syscall abi is loldifferent
19:23:00 <heat> if they're both 64-bit architecture why would the sizes of certain posix types change
19:23:00 <mjg> with numbers changed because who knows why
19:23:00 <heat> mjg, actually linux has sameish syscall numbers now for new architectures
19:24:00 <heat> Ermine, https://github.com/heatd/musl/commit/3223d18ad8ded77d8b328b2c50042448f8dc2585
19:24:00 <bslsk05> github.com: riscv64: Fix ABI issues with struct stat · heatd/musl@3223d18 · GitHub
19:24:00 <heat> this makes 0 sense to me
19:24:00 <gog> jimbzy: a little
19:24:00 <gog> i have an inhaler now
19:25:00 <mjg> heat: wow, that's progress
19:25:00 <heat> nlink_t and blksize_t go from longs to ints, and they shuffle some struct members around
19:25:00 <mjg> heat: see the i386 vs amd64 massacre
19:26:00 <Ermine> heat: I see. I guess you made it so members of struct stat on different arches are in the same order?
19:26:00 <heat> Ermine, similarly size and in the same order, yes
19:27:00 <heat> the problem is that my kernel just has a static bits/stat.h from musl x86_64 so it was using that, while riscv was using different types and a different struct stat layout
19:28:00 <heat> all in all, I should get my kernel uapi header affairs straightned out
19:28:00 <jimbzy> Good!
19:30:00 <heat> mjg, yup, see https://elixir.bootlin.com/musl/latest/source/arch/aarch64/bits/syscall.h.in and https://elixir.bootlin.com/musl/latest/source/arch/riscv64/bits/syscall.h.in
19:30:00 <bslsk05> elixir.bootlin.com: syscall.h.in - arch/aarch64/bits/syscall.h.in - Musl source code (v1.2.3) - Bootlin
19:30:00 <bslsk05> elixir.bootlin.com: syscall.h.in - arch/riscv64/bits/syscall.h.in - Musl source code (v1.2.3) - Bootlin
19:31:00 <heat> but now it makes little sense as io_setup is the first syscall
19:31:00 <heat> tradition go bye bye :((((((
19:31:00 <gog> jimbzy: i get to go back for an EKG tomorrow just to be sure
19:32:00 <jimbzy> Chest hurting?
19:32:00 <heat> but on a nicer note, non -at syscalls don't exist in those architectures
19:33:00 <heat> (you also don't have SYS_fork, SYS_vfork, as those are all implemented by clone, etc)
19:33:00 <gog> breathing difficulty and irregular heart rate
19:33:00 <gog> rhythm
19:33:00 <gog> doc is pretty convinced it's exercise-induced asthma
19:34:00 <gog> combined with the fact that i may have had RSV
19:34:00 <gog> basically i've had recurrent pulmonary illness and i get to this point every few years
19:35:00 <gog> my lungs have never really worked right
19:38:00 <zid> Have you considered buying new ones
19:39:00 <zid> I can get you a great deal
19:39:00 <zid> slightly worn, used to belong to a ballet dancer, she owed the mob some money for gambling debts
19:45:00 <jafarlihi> hey, I made a weaksauce security tool to detect hidden LKM: https://github.com/jafarlihi/modreveal It effectively detects all rootkits hosted on GitHub but I want to go step further and do memory scanning instead of iterating module_kset. Can someone give me some pointers as to how I can go about this? Can I realiably scan kernel memory space and detect LKMs?
19:45:00 <bslsk05> jafarlihi/modreveal - Utility to find hidden Linux kernel modules (1 forks/58 stargazers/GPL-3.0)
19:45:00 <jimbzy> That sucks. I had the flu a few weeks back and it took me a good 7-10 days to really start moving around.
19:46:00 <gog> zid: yeah how much
19:46:00 <gog> also what blood type was she
19:46:00 <zid> gog: Red.
19:46:00 <gog> hm
19:46:00 <gog> my blood is brown sorry
19:46:00 <heat> gog green blood
19:47:00 <zid> pooblood mcgee we call her
19:47:00 <gog> lmao
19:47:00 <GeDaMo> https://www.youtube.com/watch?v=OgV-q5kua34
19:47:00 <bslsk05> 'Futurama - You don't need lungs anymore right?' by Dont You Worry About Quotes (00:00:16)
19:47:00 <heat> https://i.imgur.com/hzXfgQO.png
19:47:00 <heat> i have achieved time travel
19:47:00 <gog> jimbzy: two weeks ago i caught my like 4th viral infection of the season
19:47:00 <gog> none of them have been covid
19:48:00 <gog> i had the flu, at least one or two colds, and possibly RSV but there's no way to know for sure which is which
19:48:00 <gog> not after the fact
19:48:00 <jimbzy> Yeah it's going around here, too.
19:48:00 <gog> half of my co-workers spend their whole day interacting with tourists so whenever i hang out with any of them i almost always catch something
19:48:00 <jimbzy> Flu, RSV and Strep.
19:48:00 <gog> oof
19:49:00 <zid> I have a tiny cold
19:49:00 <zid> just sinus pressure and a subsequent toothache
19:49:00 <jafarlihi> Can someone pls tell me if it's possible to detect LKM by purely scanning memory?
19:49:00 <zid> evreybody seemingly has something rn though
19:49:00 <jafarlihi> zid: I haven't been sick for 5 years now
19:49:00 <jafarlihi> (except psychosis)
19:51:00 <heat> vampires don't get sick very often
19:52:00 <jafarlihi> muhahahaha, tell me how to find lkms by scanning memory
19:52:00 <geist> lkms?
19:52:00 <jafarlihi> LKMs
19:52:00 <geist> what is a lkm?
19:53:00 <jafarlihi> Loadable kernel module, or linux kernel module
19:53:00 <geist> oh. probably not, not
19:53:00 <geist> no
19:54:00 <jafarlihi> With this simple tool you can find 99% of Linux rootkits: https://github.com/jafarlihi/modreveal
19:54:00 <jafarlihi> it works 60 percent of the time all the time
19:54:00 <geist> i mean i guess if you scanned all of phyiscaly memory you could reconstruct the kernel page table and then with that scan through the kernel aspace and try to find things that look like modules
19:55:00 <jafarlihi> can't I have some baseline idea of what kernel allocates normally and look for extra things?
19:56:00 * geist shrugs
19:56:00 <geist> you'd probably want to scan through kernel data structurse first, but you haven't realy specified how you're doing the scanning
19:56:00 <geist> physical memory? virtual? are you running as a root program? is this on a paused VM?
19:57:00 <gog> every kernel is slightly different is the thing, even the data structures are going to be different based on what the config is
19:57:00 <geist> do you know the kernel version?
19:57:00 <geist> yeah
19:57:00 <jafarlihi> Currently just iterate module_kset
19:57:00 <gog> so it's really hard to develop a one-size-fits-all heuristic
19:59:00 <kaichiuchi> heat: i concede something to you, the C++ facilities are mostly bullshit
19:59:00 <kaichiuchi> facilities being most of the STL
19:59:00 <heat> why
19:59:00 <jafarlihi> they are great for userspace
19:59:00 <heat> why do you deal in absolutes kaichiuchi
19:59:00 <heat> only a sith would do that
19:59:00 <kaichiuchi> well
19:59:00 <heat> we've got vampires and siths?!
19:59:00 <kaichiuchi> put it this way
20:00:00 <kaichiuchi> RAII, classes, user-defined suffixes, compile-time execution, etc are all useful bits of the language
20:00:00 <kaichiuchi> but there is a tendency to overengineer if you think in strict C++ terms
20:01:00 <kaichiuchi> jafarlihi: they're great for 99% of things except my 1% use case
20:02:00 <zid> 1% chances happen 9/10
20:02:00 <heat> "but there is a tendency to overengineer if you think in strict C++ terms" cheers, you got it
20:03:00 <heat> BUT it doesn't mean that it's horrificly bad and shit and poop
20:03:00 <kaichiuchi> weren't you shitting on std::accumulate and most of <algorithm>
20:03:00 <heat> (i would say it is bad, but "mostly bullshit" may be a bit too far)
20:03:00 <heat> sure I was
20:04:00 <heat> <algorithm> is not most of the c++ standardlibrary
20:04:00 <gog> implicit conversions!
20:04:00 <gog> i know implicit conversions are hated but i love them
20:08:00 <heat> I think that in a way, good chunks of the standard library are *that* close to greatness
20:08:00 <heat> but have a big flawed that just Fucks It Up
20:08:00 <heat> or have something that should've been compiler magic instead
20:08:00 <heat> s/flawed/flaw/
20:08:00 <kaichiuchi> i dunno. i think i'm just bummed that I just can't get my head around the more complicated shit of C++
20:09:00 <heat> *cough cough* arrays
20:10:00 <sham1> Which is funny, because std::array is one of the easier types to do
20:10:00 <kaichiuchi> std::array is fine
20:10:00 <kaichiuchi> i dunno I think I have OCD or something
20:10:00 <kaichiuchi> I just can't process how the fuck anyone writes large scale shit in a language where nobody is invalidated, yet no one is right
20:11:00 <heat> std::array is horrible
20:12:00 <kaichiuchi> i mean "fine" in the sense that it's easy to implement your own
20:12:00 <heat> it's a shitty templated wrapper around plain arrays because they couldn't get their shit together and add new syntax
20:12:00 <heat> it also *doesn't work*
20:12:00 <kaichiuchi> dunno what you mean it doesn't work
20:12:00 <heat> std::array<T> arr = {t1, t2, t3, t4}; does not compile
20:12:00 <kaichiuchi> oh
20:13:00 <j`ey> meaning it doesnt infer the size?
20:13:00 <heat> yep
20:13:00 <kaichiuchi> what?
20:13:00 <kaichiuchi> it absolutely does
20:14:00 <heat> it does not
20:14:00 <kaichiuchi> `static constexpr std::array t = {1, 2, 3, 4};` should turn into `std::array<int, 4>`
20:14:00 <sham1> I thought that works now with C++20
20:14:00 <kaichiuchi> yes
20:14:00 <kaichiuchi> that's what I'm saying
20:14:00 <sham1> Yeah
20:14:00 <heat> but I want the type
20:14:00 <kaichiuchi> oh
20:14:00 <kaichiuchi> then yes you are fucked
20:14:00 <heat> I obviously want the type
20:14:00 <heat> like a normal array
20:14:00 <kaichiuchi> no not obviously in C++ land
20:14:00 <j`ey> what do you mean you want the type?
20:15:00 <heat> std::array<unsigned long>
20:15:00 <j`ey> array t = {UL(1)..} :p
20:16:00 <heat> this is also highly nuts. why is std::array not a native type? you could pull this off much easier, quicker, etc if a native type
20:17:00 <heat> it's why rust is goated and C++ sucks
20:17:00 <heat> if rust people see something they want, they also change the language instead of building shitty abstraction upon shitty abstraction in template metaprogramming land
20:18:00 <heat> have you seen the implementation of std::tuple? it's a recursive fucking template
20:19:00 <zid> C++ isn't allowed to change the languag
20:19:00 <zid> because it's all done via small ammendments via commitee
20:20:00 <heat> if I didn't know better I would say C++ is a small language fork that still wants to merge back with C
20:22:00 <kaichiuchi> i really don't get you sometimes
20:22:00 <kaichiuchi> and I say that as a friend
20:22:00 <kaichiuchi> you simultaneously seem to really have a penchant hate for C++, yet end up using it, but to the point where it's barely C++ it seems
20:22:00 <kaichiuchi> since you seem to not like almost anything that's come out of it
20:24:00 <kaichiuchi> and that's a pattern I seem to see a lot
20:24:00 <kaichiuchi> as in, a pattern from every project that says "performance in mind" end up not using most of C++ at all
20:25:00 <jimbzy> That's the best part about learning c++. Once you've worked with it for a bit you get to complain about how it's not <insert language here> ;)
20:25:00 <heat> you're not supposed to get me
20:25:00 <kaichiuchi> i can write C++, if I have the STL at my disposal
20:25:00 <kaichiuchi> but I can't do it without it
20:25:00 <kaichiuchi> and this means I don't know as much C++ as I thought I did
20:25:00 <jimbzy> C++ without the STL is "C with classes".
20:25:00 <heat> not quite
20:25:00 <jimbzy> Not 100% exact, but pretty close. ;)
20:26:00 <heat> you just need to build a bunch of abstractions yourself
20:27:00 <kaichiuchi> and then when you do, you see how horrifically complex the language is
20:28:00 <zid> if C++ were an animal it'd be a cryptid
20:29:00 <kaichiuchi> I've bitched about it about a dozen times by now, but I really don't think I should have to watch several hour long videos about making an std::function replacement that doesn't end up using dynamic memory allocation
20:30:00 <heat> type erasure isn't that crazy
20:30:00 <kaichiuchi> it must be if the videos on it are an hour long
20:31:00 <heat> https://github.com/heatd/Onyx/blob/master/kernel/include/onyx/culstring.h
20:31:00 <bslsk05> github.com: Onyx/culstring.h at master · heatd/Onyx · GitHub
20:31:00 <heat> this is a more or less good ok completeish std::string implementation
21:37:00 <sortie> heat, oh cool new MaxsiString.h dropped
21:38:00 <heat> i bet your maxsistring didn't have SSO
21:38:00 <sortie> I'm afraid to even ask what SSO Is
21:38:00 <kaichiuchi> small size optimization
21:38:00 <gog> single sign on
21:39:00 <sortie> gog, bingo, my mind went there
21:39:00 <sortie> heat, touch your security key...
21:39:00 <Ermine> single sign optimization
21:39:00 <sortie> heat, the true C++ file extension is of course .c++
21:40:00 <gog> c++++
21:40:00 <sortie> c++ c++.c++ -o c++
21:40:00 <heat> kaichiuchi, small string*
21:40:00 <kaichiuchi> oh
21:40:00 <Ermine> gog: you just invented c#
21:40:00 <gog> true
21:40:00 <sortie> c#, for music programming
21:41:00 <heat> c# for poor eyesight
21:41:00 <kaichiuchi> it is cold
21:41:00 <sortie> auto new_data = realloc(data_, (new_length + 1) * sizeof(_Ty));
21:42:00 <sortie> heat, OpenBSD rolls in its grave
21:42:00 <sortie> Cute overflow bugs
21:42:00 <sortie> :P
21:42:00 <heat> it's because I killed it
21:42:00 <Ermine> _Ty
21:42:00 <sortie> Ermine, you're welcome
21:43:00 <Ermine> XD
21:45:00 <heat> Ermine, sometimes I try to be more or less standards-compliant
21:46:00 <heat> I fail because I can't write code that ugly
21:46:00 <Ermine> heat: are you about _Ty?
21:47:00 <heat> hm?
21:47:00 <heat> i dont get it
21:47:00 <Ermine> Well, what are you referring to?
21:49:00 <heat> identifiers used in C/C++ headers by their standard libraries need to be reserved
21:49:00 <heat> i.e #define data "bazinga" #include <string> must still work
21:52:00 <gog> bazinga
21:52:00 <gog> foo bar bazinga
21:55:00 <heat> Ermine, if you look at musl, you'll notice things in headers are all either standard-reserved names (str*, mem*, etc) or __name or _Name
21:55:00 <heat> it's also why in glibc, where they actually have parameter names for the function decls, names also all start with __
21:56:00 <heat> i.e extern void *memset (void *__s, int __c, size_t __n) __THROW __nonnull ((1));
21:56:00 <heat> every identifier there is reserved for the standard OR implementation
21:56:00 <Ermine> heat: I don't think this can be really accomplished: user can break header by #define if they intend to do it. The best effort here is to use some special format for names which other do not normally use. Apparently __ and _ became a convention (which iirc leaked to python)
21:56:00 <heat> not true
21:57:00 <heat> __ and _Uppercase are reserved for the implementation by the standard
21:57:00 <heat> period
21:57:00 <heat> it's not a mere convention
21:57:00 <heat> you can break the header by #define __s "bazinga" but that's plainly your fault
21:57:00 <Ermine> So compiler might refuse your code if it contains such identifiers?
21:58:00 <heat> in theory
21:58:00 <heat> it's UB to use those identifiers
21:58:00 <Ermine> Well, I see.
21:59:00 <heat> this is why C++ standard library headers are horribly unreadable
21:59:00 <heat> _M_data, _M_length, etc
21:59:00 <heat> the exact same rules apply
22:00:00 <j`ey> headers--
22:01:00 <heat> "Note: in C++, identifiers with a double underscore anywhere are reserved everywhere;" TIL
22:01:00 <Ermine> heat: I guess $lang should avoid #include-like stuff if intends to avoid such complication?
22:02:00 <heat> yeah, and use proper namespacing, etc
22:02:00 <heat> as it stands, if you define a strermine() it's UB as that name is reserved
22:03:00 <Ermine> Ping
22:05:00 <heat> pong
22:10:00 <epony> dung
22:15:00 <ddevault> git log | tail
22:16:00 <ddevault> wow my kernel came along quickly
22:16:00 <heat> ddevault, oh yeah did you need help on MSI?
22:17:00 <ddevault> later, will ask here when the time comes
22:17:00 <epony> are you using your kernel now?
22:17:00 <ddevault> define "using"
22:17:00 <epony> define intelligent
22:17:00 <ThinkT510> an irc client on helios would be cool but probably not there yet
22:17:00 <ddevault> do you mean am I sending these IRC messages from a system running my kernel
22:17:00 <ddevault> no, but someone did get a simple ethernet driver working and was sending pings a while ago
22:17:00 <ddevault> I don't put the cart before the horse
22:18:00 <ddevault> little demos on top of a half-assed kernel is not my game
22:19:00 <ddevault> consequently my kernel is almost done even if my userspace and drivers are very basic
22:20:00 <ddevault> of course, I did break my little demos rule by porting doom a while back
22:21:00 <ThinkT510> fun is permitted
22:21:00 <ddevault> taking the work seriously is fun for me :)
22:21:00 <ddevault> the results are more rewarding this way
22:24:00 <ddevault> little demos can be useful, though, for (1) validating the work they rely on and (2) peeking forward at future work to better understand the requirements for present work
22:24:00 <epony> I'd use my system from the first boot.
22:24:00 <ddevault> glhf
22:24:00 <epony> you're unable to design a usable system otherwise
22:28:00 <ddevault> I'm all for dogfooding
22:29:00 <ddevault> once I have a shell, editor, and toolchain, that seems reasoanble
22:29:00 <heat> and have it all stable*
22:29:00 <ddevault> and ideally a PDF reader <_<
22:34:00 <epony> now you know why the plan9 funkopops have that table of 'bad" formats that abuse the developer resources and time for "features" and "complexity" of owning the format and applications around it
22:34:00 <epony> their typical reaction would be, what is PDF ;-)
22:34:00 <ddevault> the format all of the specs are written in, unfortunately
22:34:00 <ddevault> good answer though
22:35:00 <epony> it's not that bad as a "usage" and 'end result' but is not that good of a design and standardisation and "actual portability"
22:36:00 <epony> it's an end-station, a last-stop, a breakage-snapshot distillation-render of the document
22:36:00 <epony> like a web-page
22:37:00 <epony> obtaining the tech specifications (and source files) would be a comparable / better method
22:37:00 <epony> for the documents and the system they are documenting
22:38:00 <epony> just 10K pages of a PDF or that split in 10 documents of 1K pages each is.. not really the documentation, it's the preprint books
22:43:00 <epony> but otherwise, yep, you need it, most books are in PDF format
22:45:00 <epony> so.. you need processes, a file system, and portable applications that can be brought in, instead of recreated, or a converter for the application programming
22:46:00 <epony> here is a list of some system calls http://man.openbsd.org/pledge.2#DESCRIPTION
22:46:00 <bslsk05> man.openbsd.org: pledge(2) - OpenBSD manual pages