Search logs:

channel logs for 2004 - 2010 are archived at ·· 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

Sunday, 12 March 2023

00:00:00 <geist> for zircon we have gp -> current cpu *, tp -> curren thread *
00:00:00 <heat> ah
00:00:00 <heat> that's cute
00:00:00 <geist> but we do the tp that way for another reason: we're using some stack guard stuff and the compiler *mandates* that tp point to the current TLS stuff
00:00:00 <geist> so we couldn't reuse TP for anything else anyway
00:01:00 <geist> could hang a pointer to the current cpu off the current_thread structure though, if we had a use for GP
00:01:00 <geist> but it'd be another indirectino, etc
00:01:00 <geist> that's what i have it do in LK, and am currently trying to actually use GP for small data
00:01:00 <geist> figured for embedded riscv things SMP isn't a thing so may as well make GP useful there where small data may actually be more valuable
00:01:00 <heat> do you know if there's a way to smartly transform ld offset(tp) into more complex insn sequences when required?
00:02:00 <heat> is there a relaxation for this?
00:02:00 <geist> oh like if offset is too great?
00:02:00 <linear_cannon> mjg:
00:02:00 <bslsk05> ​ 49e9262 —
00:02:00 <heat> geist, yep
00:02:00 <geist> hmm, not really. no
00:02:00 <geist> aside from some inline asm with maybe some constxpr trickery
00:02:00 <geist> to choose a different version
00:03:00 <heat>
00:03:00 <geist> i'd just generally avoid having the struct be too big
00:03:00 <bslsk05> ​ Onyx/percpu.h at master · heatd/Onyx · GitHub
00:03:00 <heat> i'm really not happy with this
00:03:00 <mjg> linear_cannon: thanks a bunch mate
00:03:00 <heat> yes, the problem is that I have no struct so I only know this at link time :/
00:03:00 <mjg> linear_cannon: hue so there a slight win for dup1_threads -s 5 -t 2
00:03:00 <geist> you should probably at leat avoid hard coding a0 like that
00:05:00 <geist> ah atually i did it the other way around: i have LK point tp to the current cpu
00:05:00 <geist> and then the current thread is just slot 0 off that
00:05:00 <geist>
00:05:00 <bslsk05> ​ lk/riscv.h at master · littlekernel/lk · GitHub
00:06:00 <geist> so then yeah no fast accessors for fields in current thread, except for `get_current_thread()->field`
00:06:00 <geist> and that's probably not optimal because it'll keep dereffing off tp every time, etc
00:06:00 <heat> yeah but that's standard, no?
00:06:00 <mrvn> lol,
00:06:00 <mjg> linear_cannon: check this out
00:06:00 <bslsk05> ​ <no title>
00:07:00 <bslsk05> ​ Using an Out-of-Control Car to Calculate π. - YouTube
00:07:00 <geist> i dunno, depends on what you mean by standard
00:07:00 <heat> at least linux does not do any of that trickery
00:07:00 <heat> current is current, period
00:07:00 <geist> yeah
00:07:00 <geist> the key is you need to arrange for any preemption in the middle to not mess up getting to the current thread
00:07:00 <geist> so either current thread is held directly in a register, or in this case it's exactly one instruction to look it up, so can't be broken
00:08:00 <geist> snce current thread is always current thread, even if you got preempted and moved to another cpu anywhere in it it's safe
00:08:00 <heat> in what case do you care about doing this atomically?
00:08:00 <geist> of course reading current cpu is instantly out of date if it takes more than one instruction to read something off it
00:09:00 <geist> well, since TP points to the current cpu you have to assume that effectively the TP register can change out from underneath the current thread at any time, unless preemption is disabled
00:09:00 <geist> between any two instructions the TP register could switch to another cpu transparently because of preemption
00:10:00 <heat> oh, right
00:10:00 <linear_cannon> mjg, wow, so adding a thread cuts performance in half?
00:10:00 <geist> but in this case since field 0 of the current cpu structure must always point to current threa,d it's safe to `ld current_thread, 0(tp)` because the invariant is maintained that it's always the current cpu
00:10:00 <linear_cannon> or worse, if on different sockets
00:10:00 <heat> yep
00:11:00 <geist> but if you did something like `mv r0, tp; ld current_thread, 0(r0)` then you'd be in trouble
00:11:00 <mjg> linear_cannon: ye it's not good
00:11:00 <geist> since you're instantly looking at a stale cpu pointer
00:11:00 <geist> thus i wrote that as inline asm in one instruction so that it can't be broken
00:11:00 <geist> but anyway you can probably just as easily point TP at the current thread, and read the current cpu * off it, and then just maintain that
00:12:00 <heat> yeah so my pcpu implementation right now is slightly broken
00:12:00 <geist> either has their advantages and disadvantages
00:12:00 <heat> good to know
00:12:00 <geist> yah, aid *if* you store a per cpu pointer in a register, then you have to make sure you dont reload it on exceptions
00:13:00 <geist> because think of it this way: if you save it on exception entry and then go and run some code and the thread is blocked and comes back on another cpu and exits, restoring the wrong per cpu pointer from the iframe... boom
00:13:00 <geist> (i hgave personally written that bug before and spent a day debugging it)
00:14:00 <heat> yeah generally most of code similar to that really does need to be preempt_disable()'d
00:14:00 <heat> or at least migration_disable'd
00:14:00 <geist> yah
00:14:00 <geist> in general most of the data on the percpu struct is one off fields that you can safely read or write in one instruction
00:14:00 <geist> like getting the current number
00:15:00 <heat> yep
00:16:00 <heat> funnily enough linux doesn't seem to give much of a shit here
00:16:00 <heat> they seem to do optimized inline asm on x86, arm64, loongarch
00:16:00 <heat> the rest uses plain C
00:18:00 <mrvn> linux doesn't migrate threads to different cores often
00:19:00 <mrvn> maybe they only do that outside preemption?
00:33:00 <geist> yeah i was reading the glibc riscv string, and it uses the C version
00:33:00 <geist> seems to be basically as good of a job as can currently do in asm really
00:34:00 <geist> given current hardware and not using vectors, etc etc
00:34:00 <geist> at least with GCC as the compiler. i dont trust clang to generate good enough code from the C
00:34:00 <gog> hi
00:53:00 <mrvn> geist: Kind of makes you want an "compare ptr1 and read ptr1[offset]" atomic op.
00:55:00 <mrvn> .oO(I'm so happy about not scheduling inside the kernel)
01:01:00 <moon-child> what do you want that for?
01:36:00 <heat> geist, oh I meant inline asm in the percpu var stuff
01:36:00 <heat> although yes, riscv is still pretty unoptimized
01:36:00 <heat> I think linux (the kernel) recently got some new stringops stuff for a new extension that got ratified recently
01:37:00 <heat> gog: bog
01:58:00 <kof123> ACTION stares up at chat log "quad-processor pentium 3 systems. i want one" im not sure if it was pentium 3, but i think that was the -march i used, intel sc450nx, 4x500 mhz IIRC, i think i had 1-2G ram maybe? nothing special about that, but they did/do exist "big square box with quad cpus in it" yes, i had a little had dual PSUs (for backup, not needed) ...6 or so scsi sleds/slots for drives i also had 2x hp r
01:58:00 <kof123> mount something, were like 2x700 mhz, 768M ram, 2 scsi drives
02:01:00 <kof123> not a huge deal maybe, but "server" stuff you could hot-swap drives. these were "server" systems
07:32:00 <moon-child> oh cute
07:33:00 <moon-child> I just realised cmpccxadd can be used to implement both regular xadd and regular cas
07:35:00 <moon-child> oh nvm, i thought cmpccxadd had weaker ordering, but seems like not. So not helpful there. Oh well
11:07:00 <lav> hi gog
11:07:00 <gog> hi lav
12:38:00 <johngammerson> hey
12:38:00 <johngammerson> quick question: if i boot an os using x86_64 qemu using -kernel with multiboot and then jump to long mode, it's considered a 64 bit os right?
12:40:00 <moon-child> well, it's certainly not a 32-bit os
13:09:00 <Mutabah> ilovethinking: Why would it not be?... I guess it's a "32-bit" image, but the kernel runs in 64-bit mode after bootup, so it's a 64-bit kernel
13:24:00 <mrvn> If a long-mode kernel comes with it's own bootloader (16-bit), multiboot (32-bit) and limine (64-bit) clearly that then is a 16/32/64 kernel. :)
15:37:00 <gog> hi
15:39:00 <zid> hello gorg
15:41:00 <Ermine> hi gog, may I pet you
15:50:00 <gog> yes
15:50:00 * Ermine pets gog
15:51:00 * gog prr
17:22:00 <zid> nobody's said RUST in the past hour, where's heat today
17:24:00 * Ermine heats up...
17:24:00 * Ermine ...
17:29:00 <sham1> Wait, rust has a windup time?
17:31:00 <zid> ofc, it has a runtime
17:31:00 <zid> std::rust::unbox::map::list::unordered::set::vector(T)
17:34:00 <sham1> FactoryBeanStrategyVisitor
17:39:00 * gog rusts
17:40:00 <sham1> Oh no!
17:41:00 <mrvn> In Rust if you have a list, a set or map or something is there a way to remove an item from the container without first having to search it? Some kind of iterator or handle?
17:41:00 * zid Cs gog rust
17:42:00 <gog> c gog
17:42:00 <gog> c gog rust
17:42:00 <gog> rust gog rust
17:43:00 <nortti> mrvn: do you mean like, getting a &mut iterator and then mem:replace()ing it out of there?
17:44:00 <mrvn> USB power sucks. I have a PSU with USB-C and USB-A outlet. I run my ARM on the USB-C outlet. But when I plug the TFT into the USB-A outlet power goes off and my SoC restarts.
17:46:00 <mrvn> nortti: Say I have a thread "current_thread" and that dies. Now I want to remove the thread from the list of running threads. current_thread->running_handle.remove_from_list() or something.
17:47:00 <nortti> I presume the list of running threads is an intrusive linked list?
17:47:00 <mrvn> I have no idea what Rust has. But an intrusive lists solves the problem easily.
17:48:00 <nortti> you may enjoy "Learn Rust With Entirely Too Many Linked Lists"
17:48:00 <bslsk05> ​ Introduction - Learning Rust With Entirely Too Many Linked Lists
17:48:00 <netbsduser> nortti: in all sensible kernels it probably would be
17:51:00 <mrvn> nortti: If you have a non-intrusive list then the handle would be a pointer to the struct ListItem { ListItem *next, *prev, T *data; }; Going that way is a bunch harder to work with and wastes space. So hence my question what Rust has.
17:51:00 <nortti> there is no built-in linked list support, but you can build your own like in C or C++
17:52:00 <mrvn> there is no STL like cargo?
17:53:00 <nortti> how do you mean?
17:53:00 <mrvn> A standard collection of data types and algorithm everyone needs every day
17:53:00 <nortti> there's core, alloc, std
17:54:00 <netbsduser> mrvn: they are notoriously limited in rust
17:54:00 <nortti> but those don't include linked lists because they are a very niche use case
17:54:00 <netbsduser> for example the standard containers can't handle out-of-memory
17:54:00 <netbsduser> they just abort
17:54:00 <mrvn> well, the kernel panics so that isn't much different. :)
17:54:00 <danlarkin>
17:54:00 <bslsk05> ​ LinkedList in std::collections - Rust
17:55:00 <nortti> huh, nvm then
17:55:00 <danlarkin> you probably don't have std though
17:55:00 <mrvn> std isn't something a rust kernel would/could use?
17:56:00 <danlarkin> I mean, you can do anything you want, but probably not
17:56:00 <nortti> yeah std is mainly meant for hosted implementations
17:56:00 <nortti> there is tho
17:56:00 <bslsk05> ​ alloc::collections::linked_list - Rust
17:56:00 <nortti> and alloc:: just requires a memory allocator
17:57:00 <danlarkin> oh yeah that's right! alloc
18:00:00 <nortti> think this is what you'd want if you are using the alloc::collections::LinkedList
18:00:00 <bslsk05> ​ CursorMut in alloc::collections::linked_list - Rust
18:00:00 <mrvn> std::collections::linked_list and alloc::collections::linked_list seem to be pretty identical
18:00:00 <danlarkin> yeah the one is std is an import of the one from alloc iirc
18:00:00 <mrvn> nortti: more like IterMut::take(1)
18:01:00 <danlarkin> like they're not just identical, they're the same thing
18:01:00 <netbsduser> mrvn: my init system does not, and the kernel also shouldn't panic if i asked for a fallible allocation
18:01:00 <mrvn> A cursor would advance to the next and you just want to remove the current from the list.
18:01:00 <netbsduser> my last foray into rust i was working on a service manager (or "init system") and i had to abandon the language for this reason
18:01:00 <nortti> a bit surprised these don't seem to have a allocating functions that return Result<(), _> instead of aborting
18:01:00 <nortti> pretty sure vector has those for example
18:02:00 <netbsduser> while C++ signals an exception and leaves things consistent if it fails to allocate, the rust panics if an allocation fails. the C++ people must be having a laugh at how silly this is
18:02:00 <mrvn> netbsduser: the user side malloc fails gracefully but if you are somewhere deep inside the kernel functions and allocation fails things generally go BOOM. Kernels generally keep a bit of memory reserved for internal use so that internal alloc never runs out.
18:03:00 <nortti> netbsduser: can't you do equivalent of what c++ does if you set panics to unwind?
18:03:00 <nortti> since aiui one of the invariants is that unwinding leaves stuff in a consistent state
18:03:00 <netbsduser> mrvn: in my case it is 512kib i keep reserved (i take no chances)
18:04:00 <mrvn> nortti: that only works if the container only ever does one alloc at a time and does that before any change to the container.
18:04:00 <nortti> hm?
18:04:00 <netbsduser> nortti: reportedly rust panicking needs to further allocate & in any case the containers abort rather than panic on OOM
18:04:00 <nortti> oh okay
18:05:00 <netbsduser> it's what drove me away from rust
18:05:00 <mrvn> Can one write an intrusive container in Rust? Can an object belong to multiple intrusive containers (even of the same type)?
18:06:00 <danlarkin> you can write any data structure you want, the only limit is your patience for unsafe code
18:06:00 <mrvn> danlarkin: obviously I mean without unsafe.
18:06:00 <nortti> if you reject using unsafe, then no
18:06:00 <mrvn> if I use unsafe I might as well just write C
18:06:00 <danlarkin> that's not obvious at all, a rust kernel will necessarily have some unsafe code
18:07:00 <mrvn> danlarkin: If you need unsafe to implement List then that's a fail.
18:07:00 <danlarkin> shrug
18:07:00 <nortti> why?
18:07:00 <zid> rust is designed around very explicit ownership and stuff
18:08:00 <nortti> that's like saying, if you need non-smart-pointers to implement List, that's a fail, for C++
18:08:00 <zid> hardware disagrees
18:08:00 <mrvn> nortti: and it is. you don't need non-smart-pointers to implement List.
18:08:00 <mrvn> nortti: you might want to and you can. But you are not required to.
18:09:00 <nortti> wait, you can implement a bidirectional intrustive linked list in c++ using refcounted pointers, without memory leaks?
18:09:00 <mrvn> nortti: a shared_ptr and a weak_ptr
18:10:00 <nortti> hm. you might actually be able to implement something similar in rust safely using stuff like Rc<> and RefCell<>. unsure if you can get all the lifetimes to nicely match up
18:11:00 <nortti> well, you can if you use a backing arena to allocate them
18:12:00 <mrvn> nortti: A weak_ptr doesn't keep the object alive but gets notified when the object gets removed. So I'm guessing weak_ptr are themself in a doubly linked list owned by the shared_ptr proxy object.
18:12:00 <mrvn> Or they are ref counted by the proxy object and that remains behind till the last weak_ptr dies.
18:12:00 <danlarkin> nortti linked this above not that long ago, but is a good read if you care about this
18:13:00 <mrvn> nortti:
18:13:00 <bslsk05> ​ Weak in std::rc - Rust
18:13:00 <mrvn> nortti: so I would say you can do it in C++ and in Rust exactly the same way.
18:13:00 <danlarkin> you won't have std
18:14:00 <mrvn>
18:14:00 <bslsk05> ​ Weak in alloc::rc - Rust
18:14:00 <danlarkin> gah! alloc strikes again
18:14:00 <nortti> lol
18:14:00 <mrvn> std seems to import all of alloc
18:14:00 <nortti> yeah, same with core
18:15:00 <nortti> unsure if they started with everything in std and then moved nonhosted stuff to std and alloc first, or why they do it like that
18:15:00 <nortti> s/first/later/
18:15:00 <mrvn> They probably don't want people to have remember what is in core and alloc. You just write std::foo
18:16:00 <mrvn> Just us freestanding / embedded people have to worry about this :(
18:16:00 <danlarkin> which has worked! as evidenced by my forgetting what's in alloc all the time
19:17:00 <heat> hlelo
19:17:00 <vaartngvirf> henlo
19:18:00 <heat> mjg, mofo how are you supposed to spin for readers in a rwlock
19:18:00 <vaartngvirf> you mean once write lock is acquired?
19:20:00 <heat> when write locking, spinning while waiting for readers
19:20:00 <heat> i read linux's impl but it reads like a bunch of pseudo science to me
19:21:00 <mrvn> heat: are spinning waiting for other cores or other threads?
19:22:00 <mjg> heat: you can't in a truly informed manner
19:22:00 <mjg> heat: at best you can speculate
19:22:00 <heat> ok so you'll never escape pseudo science
19:22:00 <mjg> heat: a'la userspace just doing sme spins
19:22:00 <heat> wonderful
19:22:00 <mjg> did i mneiton there is no such thing as an optimal lock?
19:23:00 <mjg> the only thing which is a net benefit vast majority of the time is *adaptive* spinning, past that it is all shamanism
19:23:00 <mjg> i'm pretty sure linukkkz does not spin on readers
19:23:00 <heat> it does
19:24:00 <heat> it's a best-effort thing, tries to spin on the last reader
19:24:00 <mjg> ?
19:24:00 <heat> if that reader unlocks it needs to stop spinning I think
19:24:00 <mjg> you mean if it sees only one?
19:24:00 <mjg> perhaps you found a case where it sees a *transient* state of the lock
19:24:00 <heat> no, I mean that down_read() will put you down as the "owner" of the lock
19:24:00 <mjg> and this is where it spins
19:24:00 <heat> so it spins on that
19:25:00 <mjg> that's for the sleepable locks?
19:25:00 <gog> hi
19:25:00 <heat> yes
19:25:00 <sham1> yes, hi
19:25:00 <heat> gog goog google
19:27:00 <heat> mjg, also I'm thinking that adding a has_waiters flag is a good idea for both rwlocks and mutexes
19:27:00 <heat> and anything that sleeps really
19:27:00 <mjg> heat: see freebsd locks
19:27:00 <mjg> heat: they do it
19:27:00 <gog> what do you think about the singleton pattern
19:27:00 <gog> it might help me but it might also hurt me
19:27:00 <heat> gog, bad
19:27:00 <mjg> people who use it are singletons!
19:27:00 <heat> mjg, yes I think every decent lock does it
19:27:00 <gog> yeah i'm leaning toward it hurts more than it helps
19:28:00 <heat> gog, just a glorified global m8
19:28:00 <sham1> > singletons
19:28:00 <sham1> Absolutely an antipattern these people!
19:28:00 <gog> it's adaptive
19:29:00 <heat> mjg, i have a new flamegraph for Onyx, wanna take a look
19:29:00 <sham1> Oh, adapter is fine. It's the singleton that drives me up a wall as a professional OO wrangler
19:29:00 <heat> i think patterns are stupid
19:29:00 <mjg> heat: sure
19:29:00 <gog> yeah i hate patterns
19:30:00 <gog> i agree with heat on everything always
19:30:00 <heat> twiiiiiiiiiinsssssssss
19:30:00 <gog> :3
19:30:00 <heat> colon of the three
19:30:00 <heat> mjg, so this is done for unlink1_process. i think this shit doesn't really scale very well
19:30:00 <gog> i'm doing things you'd disagree with btw
19:30:00 <sham1> Design patterns are useful. It's when people use them religiously and use them just to use them is the problem
19:31:00 <gog> sham1: i mean yeah
19:31:00 <gog> programmign isn't a dogma
19:31:00 <heat> mjg,
19:31:00 <bslsk05> ​ out-unlink1-onyx.svg · GitHub
19:32:00 <heat> so I noticed it scaled DOWN like 100x so I added spinning
19:33:00 <heat> now it scales meh
19:34:00 <sakasama> sham1, gog: The singleton pattern resolves an issue with undefined global initialisation order between translation units in C++, and in that context it's sensible.
19:35:00 <sham1> And to that I say that not every language is C++
19:35:00 <sakasama> Java coders later adopted it, oblivious to that requirement, and popularised it as merely a way to enforce having a single instance.
19:35:00 <mjg> heat: unlink is meh-ey think to bench
19:35:00 <mjg> heat: anyway i like that you discovered benefits on not going straight to sleep
19:36:00 <heat> i'm not sure how much of it is just my scheduler sucking
19:36:00 <sakasama> sham1: Yes. It should never have been so readily adopted for other languages.
19:37:00 <heat> mjg, does unlink ever scale? maybe when doing RCU on that?
19:37:00 <mjg> yes and no
19:38:00 <mjg> first unlink of what
19:38:00 <mjg> currently everyone that i know of has unlink serialized on the directory vnode, at least
19:38:00 <mjg> but without naming names, unlink from *different* dirs will also serialize in certain case
19:38:00 <mjg> it can be made to mostly scale by range-locking, but i don't know if it is of practical use
19:39:00 <mjg> as in i have not ran into a real workload which unlinks enough for this to be a problem
19:41:00 <mrvn> mjg: 2 users deleting files?
19:42:00 <heat> also do note that currently my spinning is completely based on good vibes and inshallah
19:42:00 <heat> it's entirely possible the thread fucks off and gets unmapped and I get egg on my face
19:55:00 <mrvn> sakasama: I just define initialization priorities by hand in an enum.
20:03:00 <sakasama> mrvn: If interdependent globals can be placed in a single unit so that order is well-defined, even better.
20:03:00 <mrvn> sakasama: if they can not be ordered then the singleton initialization would deadlock.
20:04:00 * sakasama nods.
20:18:00 <sortie> ← I did an osdev.
20:18:00 <bslsk05> ​ libc/glob/glob.c · staging · sortix / Sortix · GitLab
20:43:00 <zid> oh I thought I heard some rust, there's heat
20:44:00 <heat> rurururuuuuuuuuuuuuuuuuuuust
20:48:00 * geist hears the call of the rust
20:48:00 <geist> RUUUUUSSST
20:50:00 * sakasama flees into the wilderness.
20:50:00 * gog oxidizes
20:50:00 * sakasama weeps for gog from a safe distance.
20:52:00 <heat> geist, how far along is the zircon riscv support?
20:52:00 <geist> not checked in (in a sandbox branch) boots single core up to the end of the kernel start
20:52:00 <geist> user space is stubbed out right now
20:52:00 <geist> so a few more weeks
20:53:00 <geist> going to start pushing changes into gerrit next week
20:56:00 <zid> heat you love acpi, what's all this mess of tables
20:56:00 <zid> BGRT, CDIT, SSDT (x10)
20:56:00 <zid> I have a TPM2 at 0xBC61B000
20:57:00 <heat> BGRT is your firmware logo, no clue what CDIT is, SSDT are like auxiliary DSDT tables you dynamically load
20:57:00 <geist> there are an arbitrary number of tables, ignore the ones you dont want
20:57:00 <zid> oh is that how it did the AORUS thing + windows spinny
20:57:00 <heat> yep
20:57:00 <zid> neat I uess
20:57:00 <zid> Table Description Windows SMM Security Mitigations Table
20:57:00 <zid> For when windows wants to hack my SMM
20:57:00 <heat> if you look at the BGRT data it's just a plain .bmp
20:57:00 <zid> so time to hex edit it, then reflash firmware?
20:58:00 <heat> could work brilliantly, could brick your mobo
20:58:00 <zid> I guess it might actually be compressed and it unpacks it to that memory at POST
20:58:00 <zid> so I might not be able to edit it
20:59:00 <heat> a good chunk of firmware volumes are completely compressed
20:59:00 <zid> • Major vulnerabilities updates, customers are strongly encouraged to update to this release at the earliest.
20:59:00 <zid> Credits to "Assaf Carlsbad and Itai Liba from SentinelOne"
20:59:00 <zid> should I install this bios rev
21:00:00 <zid> might lock me out of doing fun stuff to my own machine!
21:00:00 <heat> yes
21:00:00 <zid> `1 x Q-Flash Plus button`
21:01:00 <zid> I don't know how this works on AMD
21:01:00 <zid> I have two bios chips though and I can swap between them, that's handy
21:05:00 <heat> geist, btw cool cool ping me if you want some eyes on it
21:06:00 <heat> just testing on qemu or did you manage to boot it on your riscv board?
21:06:00 <geist> kk. the cguts are pretty close to LK, since the core underlying architecture is
21:06:00 <geist> qemu
21:28:00 <brunothedev> let me test something here
21:28:00 <heat> no
21:28:00 <zid> no
21:29:00 <heat> theend.
21:29:00 <brunothedev> the message was the test, #gentoo is giving me a weird message
21:29:00 <brunothedev> so i tested here, on another chatroom
21:30:00 <lav> The weird message is that you're quieted I think
21:30:00 <heat> hahahahahahaha
21:30:00 <brunothedev> lol
21:31:00 <zid> does not surprise
21:31:00 <bnchs> lav: you wouldn't quiet someone
21:31:00 <bnchs> you would kickban them
21:31:00 <lav> I would?
21:31:00 <zid> lav: I did not know this about you
21:31:00 <zid> how come he knows but we didn't
21:32:00 <brunothedev> i am not angry, just deceptioned
21:32:00 <bnchs> because i know
21:32:00 <bnchs> brunothedev: new word unlocked: deceptioned
21:33:00 <brunothedev> bnchs: there is a similar phrase in portuguese
21:33:00 <heat> poortuguese moment
21:33:00 <brunothedev> heat: brazilian here btw
21:33:00 <heat> poorbraziliantugese moment
21:34:00 <brunothedev> just say "luso" by this point
21:34:00 <heat> argentina moment
21:36:00 <brunothedev> "#gentoo: Cannot send to nick/channel", i think if i was quieted, the channel would receive the message, should not talk about his here though
21:40:00 <lav> Nope, that's what you get when you're +q
21:41:00 <bnchs> brunothedev: or maybe when you're kicked
21:41:00 <lav> If you do `/mode #gentoo q` you're right at the top of the list (:
21:41:00 <bnchs> lol what did brunothedev do to earn this quiet
21:42:00 <geist> huh. thats lame
21:42:00 <geist> maybe they do a quiet by default and then unquiet if you talk to them?
21:42:00 <lav> Nope don't think so
21:42:00 <brunothedev> lemme see the date which they quieted me
21:43:00 <lav> the dates are all in 1970 lol
21:43:00 <lav> for me at least >_>
21:43:00 <geist> maybe it got imported from freenode or something
21:43:00 <geist> and thus has a epoch date
21:43:00 <lav> ah that'd make sense
21:44:00 <sortie> Sometimes osdev just boils down to writing that super specific and complex function from POSIX with an efficient and semantically correct algorithm that makes various implementation tradeoffs. :)
21:44:00 <brunothedev> lol, i got quited on 11:00 on this date, i made some jokes yesterday, tho, my last messages was some questions
21:44:00 <lav> brunothedev: 15:13 UTC today
21:45:00 <brunothedev> lav: for me it is 18:44
21:45:00 <lav> huh
21:45:00 <geist> sortie: yeah if nothing else it's really educational. at least in as much as knowing intracacies of posix is helpful
21:46:00 <lav> actually it's 14:13 utc for me
21:46:00 <sortie> geist, yeah I just implemented glob(3) and my shell skills did improve :)
21:46:00 <brunothedev> i made such jokes as: "if ( == 1) printf("me love gentoo!\n");
21:46:00 <lav> tbh you were trolling
21:46:00 <brunothedev> lav: what ur time zone?
21:46:00 <geist> woot
21:46:00 <lav> and gentoo peeps are brutal
21:46:00 <lav> just be glad it wasn't -chat
21:46:00 <geist> reminds me, the other day i learned whatever the ctrl trick is to get bash to glob stuff on the command line, but already forgot it
21:47:00 <geist> but there's some trick you can do to get it to expand it live
21:47:00 <sortie> geist, sometimes it's also just nice in its own right to write that standard library algorithm
21:47:00 <brunothedev> lav: tho why they banned the other day?
21:47:00 <lav> geist: on zsh that's just called tab
21:47:00 <geist> yah, most shells hve their own thing for it
21:47:00 <lav> brunothedev: idk ask them
21:47:00 <geist> i'd actually be a little annoyed if it was tab per se, that's a bit too easy to trigger
21:47:00 <geist> actually one that'd be nice is 'toggle glob'
21:48:00 <geist> ie, expand, to see what it'll do, then hit it again to go back to *
21:48:00 <brunothedev> did they got angry at mine: "just did 'mount --rbind /sys /mnt/gentoo' pls help" ?
21:49:00 <lav> well you can C-x u I suppose
21:49:00 <brunothedev> lesson learned: Dont make bad jokes while bored building the gentoo kernel
21:49:00 <lav> make them here instead
21:50:00 <brunothedev> lav: i already made some troolsusing /part
21:50:00 <lav> or in #windows
21:51:00 <brunothedev> imagine being #windows at
21:54:00 <brunothedev> gonna drop a cool /part message at #windows
21:55:00 <geist> brunothedev: i'm gonna guess they just did it on accident
21:55:00 <geist> you could try to ask one of the ops
21:56:00 <zid> gentoo is heavily moderated
21:56:00 <zid> you're supposed to ask your question and go away
21:58:00 <brunothedev> zid: i thought it was just like the void linux chatroom, this was my first time with irc and it was FUN
22:00:00 <geist> i have no idea if zid is making that up or not
22:00:00 <lav> nope
22:00:00 <geist> ah so maybe it's a standard policy to voice everyone after they ask a question?
22:01:00 <lav> nah, it's just they really don't like trolling
22:01:00 <lav> it's a serious business kinda chan
22:01:00 <brunothedev> the last message i see: "ready to wreck clean a system again lol?"
22:01:00 <geist> i guess they've experienced in the past that if they dont lock it down it just turns into complete noise
22:01:00 <geist> maybe there's a -discuss channel
22:02:00 <lav> there's gentoo-chat
22:02:00 <brunothedev> gentoo users is the kind of people to see a IRC channel about gentoo and think "seriouus bisness"
22:02:00 <lav> they have crap moderation but in another way
22:03:00 <brunothedev> boredom always leads to bad things
22:04:00 <heat> irc channels are all usually more seris bizns than #osdev
22:04:00 <heat> for better or worse
22:04:00 <geist> does remind me, i should try a gentoo install w/systemd. not my favorite thing, but it's clear that its harder and arder to keep from using it
22:08:00 <brunothedev> geist: what are your problems with openrc
22:09:00 <geist> none, i love openrc
22:09:00 <brunothedev> u saying it is "harder and harder" to not use systemd? Package support?
22:10:00 * geist nods
22:10:00 <heat> because systemd is objectively better and upstream packages usually only support systemd
22:11:00 <geist> yah, objectively, not subjectively (from my point of view) but it's getting harder to ignore it
22:11:00 <geist> OTOH all of my real linux boxes are ubuntu based, which is already systemd. so i've had some time to get used to it
22:12:00 <brunothedev> i think that systemd gets a bad rep more about pottering
22:12:00 <mrvn> systemd is bad when things go wrong
22:12:00 <mrvn> nightmare to debug and most of the time you can't even get a console
22:14:00 <brunothedev> the only i dont like about openrc && runit, is the interface, in runit u have to symlink and delete files to enable/disable init processess
22:15:00 <brunothedev> pottering just likes to offend people, like when he called suckless devs far-righters when they did a torch march
22:16:00 <brunothedev> i think he fighted with linux too, my memory is a bit cloudy
22:16:00 <brunothedev> * linus
22:16:00 <moon-child> out of all the crap redhat puts out, systemd has not really gotten in my way very much
22:16:00 <moon-child> although I will say coredumpctl is one of the stupidest things I've ever encountered
22:17:00 <heat> why? I like it
22:17:00 <heat> it makes sense
22:17:00 <brunothedev> moon-child: i think systemd is the worst thing redhat has put out, atleast pipewire and wayland are cool
22:17:00 <moon-child> wayland no
22:17:00 <moon-child> after the way they bungled pulseaudio I have very little hope for pipewire
22:17:00 <heat> wayland is good, pipewire is good, pulseaudio is good, systemd is good-ish
22:18:00 <brunothedev> * pulseaudio is bad, * systemd is mid
22:18:00 <moon-child> pulseaudio is one of the worst pieces of software I have ever had the displeasure of running on my computer
22:18:00 <zid> I used pulse for a bit it was like... fine?
22:18:00 <zid> Just acted like win7's volume mixer
22:18:00 <moon-child> coredumpctl: what's the point? Just dump core in cwd like a normal computer system
22:19:00 <brunothedev> remembering when it thok 2 weeks to configure audion on my gentoo system, oh the times... it was like a year ago
22:19:00 <moon-child> pulseaudio: random hitching; hitching when changing volume; randomly spinning up to 100% cpu; randomly refusing to recognise outputs or inputs
22:19:00 <brunothedev> moon-child: bloatware
22:20:00 <brunothedev> pulseaudio with kde dont work on youtube too, when i change to pipewire it fix
22:20:00 <heat> moon-child, coredump compresses dumps by default, coredumpctl debug <progname> gives ya the latest dump, also does GC of old dumps you don't look at
22:20:00 <heat> also omfg I can't believe suckless devs did a fucking tiki torch march
22:20:00 <moon-child> lol
22:20:00 <heat> I hate them even more now holy shit
22:20:00 <zid> You're a football fan heat you're supposed to be into racism
22:20:00 <brunothedev> heat: ?
22:21:00 <brunothedev> guess everyone in brazil is racist
22:21:00 <lav> i thought they were mask-off ages ago
22:21:00 <moon-child> I will concede suckless is worse than redhat
22:21:00 <heat> zid, nooooOOOOooooooooo I love n'gubu when he scores, but when he doesnt I go get my tiki torch
22:22:00 <brunothedev> being racist because of sports... So English
22:23:00 * brunothedev plays "rule britannia"
22:23:00 <zid> he's portuguese
22:23:00 <zid> can you stop being a cunt
22:24:00 <heat> u wot m8
22:24:00 <heat> im not a geese
22:24:00 <geist> ugh come on people
22:25:00 * lav honks
22:25:00 <brunothedev> lav: oi m8 u got a loicense to honk?
22:25:00 <brunothedev> wait, is heat portuguese?
22:31:00 <heat> moon-child, also, re: pulseaudio, pipewire: they all kind of collectively suck because very few companies do desktop linux work. but they were both good steps in the right direction
22:31:00 <heat> just like wayland, etc
22:31:00 <brunothedev> wayland doesnt suck!
22:31:00 <heat> they all suck because almost no one wants to do the work and the fragmentation is nuts
22:32:00 <brunothedev> also, bsd gets no representation :(
22:42:00 <klys> /usr/lib/xorg/Xorg -listen tcp :0 vt1 -keeptty -auth /tmp/serverauth.XxXxXxXxX
22:50:00 <brunothedev> klys: wut
23:01:00 <bnchs> hi
23:02:00 <brunothedev> fun fact: rms wrote gnu using the nutrients of his feet
23:02:00 <brunothedev> bnchs: does your name mean benches
23:03:00 <bnchs> bunches
23:06:00 <sakasama> Honey bnchs of osdev.
23:07:00 <bnchs> sakasama: i'm not a osdev, i'm merely a idiot here
23:07:00 <sakasama> ... but you're here, thus you are of here.
23:09:00 <bnchs> really?
23:09:00 <FireFly> sure why not
23:09:00 <FireFly> it's okay I don't do osdev either
23:10:00 <bnchs> i forgot why i was here, amorphia invited me because i was doing this os-9 reverse engineering shit
23:11:00 <heat> geist, have you seen the soon-to-be-new RAO atomics for x86?
23:11:00 <geist> hmm, no
23:11:00 <geist> is there a whitepaper or something
23:11:00 <sakasama> bnchs: I've only intermittently tinkered with osdev: I spend most of my effort on compilers and an absurd experimental architecture that will probably never be completed.
23:11:00 <heat> there's a pdf containing soon-to-be-new-shit for Intel
23:12:00 <heat> it's there, I think moon-child mentioned CMPccXADD which led me to it once again
23:13:00 <heat>
23:14:00 <heat> RAO basically gives you atomics that may be done at the lower cache levels and/or DRAM controller itself
23:14:00 <heat> with a bunch of weaker ordering constraints as well
23:14:00 <mrvn> heat: so I don't bounce around a cacheline at the cost of needing a round-trip to get the result?
23:15:00 <heat> CMPccXADD is also slightly related but cool as well, basically does a semaphore/down_read operation
23:15:00 <bnchs> sakasama: i'm making a OS emulator/debugger, it's dumb
23:15:00 <heat> essentially replaces the standard cmpxchg loop you need for this
23:16:00 <mrvn> CMPeqADD #0, %rax, #1?
23:18:00 <moon-child> I'm annoyed cmpccxadd isn't more weakly ordered (from what I could tell)
23:18:00 <sakasama> bnchs: My only goal in life is to write an expert system that can rewrite me.
23:19:00 <mrvn> sakasama: I'm sure it will feel real bad when it does that.
23:19:00 <moon-child> could fence if you really wanted, or even say it's weakly ordered if plain, and seqcst with a lock prefix
23:19:00 <bnchs> my goal in this is rewriting an obscure 35 year old OS barely anyone uses
23:19:00 <moon-child> since then you'd be able to use it to implement weakly ordered xadd and cas
23:19:00 <moon-child> ohai sakasama
23:20:00 <nortti> bnchs: which OS, out of interest?
23:20:00 <sakasama> mrvn: It feels real bad already, so that doesn't sound like much of a risk.
23:20:00 <bnchs> nortti: microware OS-9 (m68k version)
23:20:00 <nortti> ooh, neat
23:20:00 * sakasama waves at moon-child.
23:21:00 <bnchs> or the m68k assembly version, not to be confused with OS-9000's m68k port (unoptimized C port)
23:21:00 <mrvn> sakasama: you will be the end of us. Think about it. You are creating a life form whos first act is to kill you. How ever will that go wrong?
23:22:00 <sakasama> mrvn: That's the genius of it; if it replaces me, my objective is already fulfilled!
23:26:00 <heat> moon-child, making it weakly ordered would be supremely strange for an x86 insn
23:27:00 <heat> just like RAO but RAO makes sense in this case, while cmpccxadd is more suited to normal programming like down_semaphore/down_read
23:27:00 <moon-child> yeah but having all your atomics be strongly ordered really sucks
23:28:00 <moon-child> since essentially everything is a fence, which you don't need
23:29:00 <moon-child> basically every other arch in common use gets this right. If cmpccxadd were weakly ordered, then you get the two most important atomics--cas and faa--as weakly ordered for free
23:29:00 <moon-child> by weakly ordered, I just mean acquire/release, like arm; not relaxed. Basically what you want 99% of the time
23:29:00 <heat> what's faa?
23:29:00 <moon-child> fetch and add. ie lock xadd
23:30:00 <heat> ah yes
23:45:00 <mrvn> I want a "pause till $ARRD == imm and set imm2"
23:46:00 <mrvn> potzentially with imm/imm2 just 0/1.
23:47:00 <mrvn> bonus points for having a "wake one" and "wake all" variant.
23:48:00 <mrvn> So basically lock and wait_condition
23:49:00 * mrvn goes to bed with a case of the Mondays.