klange changed the topic of #osdev to: Operating System Development || Don't ask to ask---just ask! || For 3+ LoC, use a pastebin (for example https://gist.github.com/) || Stats + Old logs: http://osdev-logs.qzx.com New Logs: https://libera.irclog.whitequark.org/osdev || Visit https://wiki.osdev.org and https://forum.osdev.org || Books: https://wiki.osdev.org/Books
foudfou has quit [Remote host closed the connection]
heat_ is now known as heat
<heat> geist, I was thinking just now of something you said AGES ago (a few years): you said something like implementing e.g vmo_read and vmo_write was tricky because you've got some edge cases if you copy from/to the same vmo, etc
<heat> do you remember any of this?
<geist> yah notably, if the vmo itself is mapped and you vmo_read into/out of the mapping of itself
<heat> but isn't this a no-go anyway since you don't want to hold locks when copying memory anyway?
<geist> if you have a 'take faults and demand fault inside the user copy' style copyin/copyout
<mrvn> urgs, doesn't that deadlock because both sides want to lock the address?
<geist> if you dont design thins right that can be an issue, yes
<heat> wdym?
<geist> because you could recurse your locks, yes
<geist> say you had some sort of per vmo lock, or a range lock or something. you could be holding it when faulting on itself
<mrvn> don't think that would be ok. You can't let something access the mapped pages till you actually fill them with data.
<heat> yeah but it's not like you want to be holding it anyway when doing copyin/out
<geist> generally speaking that's not an issue, so it's fairly easy to design a system that way, *except* the recurse on itself problem
<geist> well, yes you know that *now*
<geist> if you avouid that problem then it's not a problem
<heat> yeah I'm saying this from a performance standpoint
<heat> copyin/out isn't necessarily trivial so hogging a lock while waiting for IO would suck
craigo has joined #osdev
craigo has quit [Changing host]
<geist> but then that causes some issues elsewhere because you might need some sort of mechanism to temporarily pin that page
<mrvn> heat: you have to
<geist> pin that physical page that is, in the kernel
<geist> so that you can drop the lock and copyin/copyout
<heat> yep
<mrvn> gorgonical: if you drop the lock then the next access to the page gets random data while the copyin runs.
<geist> and that extra logic of pin/unpin may actually be slower performance wise than just holding some sort of lock
<mrvn> geist: ^
<geist> mrvn: well, that's a given. you never ever ever map an uninitialized page to user space
<heat> geist, how does fuchsia pin vm_pages?
<geist> that would be if nothing else a gigantic security issue
<mrvn> any second access has to be blocked while the "alloc page, copy in data, map page" process runs.
<geist> i think there's a pin count per page but that logic has been somewhat rewritten since i got my hands dirty at that level
craigo has quit [Quit: Leaving]
<heat> something I can't quite get my finger on is how you're supposed to do page replacement and how that interacts with page refs
<geist> the very initial design when i slammed it together, it was holding the vmo's mutex while doing the copyin/copyout. which is very simple, but of course has the recursion thing
<geist> that's where the tricky part i was talking about was. because though it's simple it's not sufficient for more than just performance reasons
<mrvn> geist: I would think you need a range lock so you can lock down parts of the vmo.
<geist> or the whole thing, yes.
<heat> I guess that if you stick to iterating thru your VMOs looking for pages to replace you can know that those pages are either +ref'd to VMOs or pinned as they are being currently used on mlock and/or being mapped
<geist> or you individually pin pages, whcih is kinda like a range lock per page
<mrvn> And an extra check if copyin/out will read/write overlap.
<mrvn> You could have memmove(p, p+1, 10000);
<heat> but... I don't know, this sounds off to me
nyah has quit [Quit: leaving]
<mrvn> (except with a read or write in there I guess)
<heat> I need to read through more of the cranor paper for more ideas on how to do COW, etc
<mrvn> heat: single level COW or multi level?
<heat> whatever level
<heat> I'm more concerned about single level because that's the only COW required/"suggested" by POSIX
<mrvn> well, multi level gets really complex and a simple ref count won't suffice.
<heat> not really?
<mrvn> A-B-C share a page with COW. Then B shares the page with D through shared memory and D then forks creating E that has COW again. Now if A, C and E modify the page you are left with a refcount of 2 but no longer needing COW.
<heat> if the page is shared with D thru shared memory then D and E are not doing COW
<heat> they are doing shared memory
<mrvn> exactly. You need a more complex structure to manage COW and shared relations.
<heat> no?
<mrvn> Lets go back to the original state. If B writes to the page you need to COW it and update both B and D, changing the refcount by 2. How will you know how to change D without more data?
<mrvn> You need something like a graph with alternating COW and Share nodes.
<heat> right. you're assuming I don't have vm objects. don't worry, I have vm objects
<heat> pages do have owners, they aren't loose
<mrvn> heat: Ok, then each COW node (wherever you store that) has a list of owners of that page and on every write you copy the page and split the node and each node that has only one owner becomes non-COW.
<mrvn> i.e. when refcount == 1
<mrvn> That's basically it.
<mrvn> If you have only a single-level then sharing a page would force a COW vm object to copy the page and create a new shared vm object. You wouldn't have the recursion there at the cost of sometimes having to copy pages early even though they are unchanged. Easier data structure and code but possibly less efficient.
<heat> geist, does fuchsia ever try to avoid the COW chain problem?
<heat> (the OG COW chain problem in the BSD VM)
<mjg> no problems in bsd boss!
<heat> mjg, i'm still more or less halfway thru cranor's dissertation but the uvm system sounds solid to me
<heat> although things like "this hasn't been tried in SMP" do worry me
<heat> but the ideas themselves seem sound
<heat> some things that they brag about are probably not major wins (or wins at all), like the page loaning stuff
<mjg> i only skimmed through it and even then quite some time ago
<heat> at what point is doing a good old memcpy faster than changing page tables around and flushing TLBs, potentially with a shootdown, while needing to hold some more locks
<mjg> i distinctlyr ecall warning you though that papers tend to be self-conglaturatory
<heat> yes, i know
gog has quit [Ping timeout: 260 seconds]
<mjg> ye, so when dude states "f4st3rz bro" don't take it aface value
<heat> although I think I'm just looking at it in 2023 when it was written 25 years ago
<mjg> there is a sunos vm paper where they claim mmap() is always faster than read()
<mjg> well don't blindly assume the idea was necessarily good at the time of writing either
<heat> when this was written (per the author) no BSD even supported SMP
<mjg> there is a funny book, "beautiful code" or similar
<mjg> it has chapters by several different people, one of them about freebsd vfs thingy
<heat> they also have *weird* things like using a linked list to hold vm regions
Burgundy has left #osdev [#osdev]
<heat> mjg, 4.4BSD VFS and beautiful in the same sentence???
<mjg> in that book the chapter author states ye there is some branchin' on each op, but it is no problem bro!
<mjg> and so worth it!
<heat> what branching?
<mjg> not only the functionality was dead, but it was implemented in such a slow manner
<mjg> DUDE
<mjg> give me 5
<mjg> mind-fucking-boggling
<heat> i do not look at 4.4BSD vfs code
<mjg> i'm gonna paste generated call
<mjg> just need to build an old fucker
<heat> you and your vn_ops and your WEIRD_UPPERCASE_CALLS
<geist> i was wondering when mjg was gonna pop up
<heat> i'm a simply catholic boy who enjoys struct file and struct inode
<mjg> why, was performance mentioned previously? :]
<geist> exactly
<mjg> idon't read scrollback most of the time
<mjg> the one time i look today and bam, 01:43 < heat> (the OG COW chain problem in the BSD VM)
<heat> dh told me that NetBSD has cleaned up much stuff that is still haunting FreeBSD in this day and age
<heat> and he is absolutely right
<mjg> he missed the part where freebsd cleaned up stuff which is haunting netbsd
<heat> the same problem has been there for 25 years
<mjg> also i'm pretty sure he was talking about vfs
<mjg> :]
<heat> 1) yes 2) the BSD VM system seems to have also given you large amounts of technical debt and weird code to work around its limitations
<mjg> so i'm waiting for an old yeller to boot
<heat> is it an ia-64?
<heat> might take a while
<mjg> that bit i cannot comment on
<mjg> ufs is already stupid
<mjg> and it leaks into the "layer"
<heat> ever since you took out that cmpxchg relax that the critical ia-64 servers run slow
<mjg> originally there was no layer, then someone just plopped in api calls instead of direct ufs/ffs usage
<mjg> which is a start
<mjg> some systems cleaned it up later to some extent, others mostly did not
<mjg> as in dumbfuck ideas are part of the loosely stated api contract
<mjg> because bare minimum + epsilon was done to support other filesystems
<mrvn> heat: mmap is faster than read if your buffer isn't paged in yet. Otherwise 1 syscall for read will not be slower than demand page faulting every page.
<mjg> aight mofer
<mjg> while(vop != NULL && \
<mjg> vop->vop_cachedlookup == NULL && vop->vop_bypass == NULL)
<mjg> vop = vop->vop_default;
<mjg> every.single.time. you do any vop call
<mjg> lock, unlock, lookup, read, write, whatevertehfuck
<mjg> and it even starts stpid as vop is guaranteed not-null
<mjg> anyhow whacked all this crap
<geist> SLAPCHOP
<geist> set it and forget it
<heat> ??
<heat> what is that?
<mjg> that is vnode_if.c, generated by magic awk script, trying to figure out what's the routine to call
<bslsk05> ​'Original Slap Chop Infomercial (Extended) - Vince Offer (SlapChop Guy)' by Vince Offer (00:03:11)
<mrvn> Also consider any claims X is faster than Y from 25 years ago is probably obsoleted by hardware changes and needs to be profiled again.
<geist> you gotat slap chop those if statement
<geist> mrvn: yeah that's my general thought. different set of constraints
<heat> mjg, ... and why does it involve a loop?
<mjg> heat: you can have struct lolops heatfs { .default = &some_other_lolops_table; .... }
<mjg> heat: because stupid, that's why
<mjg> i patched the code to require registration of ops
<mjg> which also resolves all of them
<mjg> no wtf looping
<mrvn> heat: the numbers I read for mapping vs. copying is that 4-64k is faster to copy. There is some uncertainty there because copying will also prime the caches. Which either helps or hurts depending on what the code does with the pages.
<heat> mjg, lol
<mjg> it's a fucking fever dream man
<heat> hah found the book
<mjg> it also has a chapter by cantrill
<mjg> read at your own peril
<heat> "Note that although the complete
<heat> vop_vector structure contains 52 fields, only 16 are defined in the preceding code"
<heat> what is wrong with you people?
* geist points at everyone in the past and laughs
<geist> what fools they were
<mjg> cmon geist
<geist> heh
<mjg> by 2007 it was known all this dogshit
<mjg> so why is the dude writing a chapter praising it
<mjg> 2007 is when the book cmae out
<heat> it's the unix-history-repo guy btw
<geist> ah figure this was the 4.4 bsd book
<geist> which woulda been like 1995
<mjg> look, i don't mind people experimenting here
<heat> no, it's "Beautiful code", you can find it if you google around
<heat> or bing if you're a weirdo
<mjg> so one funny bit from the book
<mjg> see mofo?
<mjg> autogened assertions
<mjg> sounds great on paper
<mjg> what he neglected to mention is that the retarded api contract for rename requires filesystems to perform lookups inside
<mjg> which in face of other renames can result in finding other vnodes
<mjg> making these asserts worthless
<mjg> you may also recall null_bypass
<bslsk05> ​cgit.freebsd.org: null_vnops.c « nullfs « fs « sys - src - FreeBSD source tree
<mjg> a lot of this lunacy was used to support it
<heat> where's vop_vector defined?
<mjg> up your ass
<mjg> * This version has been optimized for speed, throwing away some
<mjg> * safety checks. It should still always work, but it's not as
<mjg> * This is the 10-Apr-92 bypass routine.
<mjg> * robust to programmer errors.
<mjg> it would be faster and simpler to *not* have the routine
<heat> up my what
<mjg> it is autogened with awk
<mjg> vnode_if_newproto.h
<mjg> struct vop_vector { struct vop_vector *vop_default; vop_bypass_t *vop_bypass; vop_islocked_t *vop_islocked; vop_lookup_t *vop_lookup;
<mjg> .... snip
<mjg> see kern/vnode_if.src
<heat> ... oh fuck off
<mjg> anyhow this is just total lunacy pretending to be complicated for a good reason
<heat> WHY
<mjg> LSD
<geist> this is like the two girls at the start of Baby Got Back video
<geist> 'omg look at her butt, it is so big'
<heat> why is there a meta language to describe a struct
<heat> why is this ok?
<mjg> to my undersatdning they used to experiment with layering of filesystems
<heat> mjg, thank you for adding spares
<mjg> it made non-zero sense for quick iteration over it i guess
<heat> you never know when a struct member goes flat
<mjg> you may notice this only ever calls one func
<mjg> not a chain
<mjg> you can find out what func it is going to be once
<mjg> instead of every time
<mjg> this is a failed experiment which was never properly cleaned up
<mjg> 's what i'm saying
<mrvn> if only compilers where smart enough to optimize the common subexpression
<heat> computing itself is a failed experiment
<heat> reject computer, become monk
<mrvn> with a lot lot lot of luck the compiler will notice the pointers aren't aliased and figure it out
<mrvn> heat: climbing down from the trees was a mistake, some even say leaving the oceans.
<mjg> what
<mjg> the compiler has no choice but roll with the branchnfest
<mjg> including the initial null check, which is known to be worthless, but not by the compiler
<mrvn> mjg: not if it can see the check remains constant during the loop
<mjg> it has to generate the loop because it does not know how many pinters it will have to follow
<mjg> anyway all that crap is gone now
<mjg> on the other hand netbsd has still some funzies in this area
<mrvn> mjg: that wasn't the point. You said you can cehck the function once before the loop. With a lot of luck the compiler sees that itself.
<mjg> no
<mjg> i said i can add a routine to register vector ops
<mjg> do the flattening there
<mrvn> 02:16 < mjg> you can find out what func it is going to be once
<mjg> and then the actual op calls don't have to loop
<mjg> you can, upfront, when registering the vop vector
<mjg> not when doing vop_read or whatever
<mjg> the vop vector registration retains the looping, but it is not a problem because it happens once per op when the filesystem is being loaded
<mjg> past that nobody has to figure out anything, it is just there
<heat> i don't really like that approach unless you end up marking it read-only
<mjg> you do understand that the "dynamic" looup, or howeveryou call it, would already be unsafe in this regard?
<heat> no idea
<heat> I'm not familiar with your crappy vfs
<mjg> say someone adds a routine to call instead of what's there normally
<mjg> how is safety of that call guaranteed
<mjg> for example, how do you know nobody is executing the func or went through it
<heat> wdym?
<mjg> foo -> vop_lookup -> snarkyroutine -> heatfs_lookup
<mjg> say you now want to unload snarkymodule
<heat> oh sure
<mjg> how do you know nobody rolls with snarkyroutine or heatfs_lookup called from there
<mjg> the code pasted above already does nothing to prevent squat
<mjg> as i said, it does look like bare minimum experiment
<heat> I'm not talking about that, i'm talking about having a large table of function pointers that is dynamically calculated
<mjg> but it only happens once
<mjg> before anyone can see it
<mjg> legally anyway
<heat> all of this should be immutable, either at compile-time or write-once and write-protect
<mjg> are you a security guy now?
<mjg> not saying no, but low prio
<heat> if I see a table with 56 function pointers you bet I'm nervous lol
<mjg> brah
<mjg> lemme check the current size
<heat> also, seriously? 56?
<mjg> it soudns fishy mate
<heat> I looked at your default vnops, it's around 50
<mjg> ... :D
<mjg> (kgdb) p sizeof(struct vop_vector)
<mjg> $2 = 656
<mjg> 8=====D
<mjg> turbo loller
<heat> ...
<heat> is that all writeable at runtime?
<mjg> probably
<mjg> how are you suddenly so security conscious
<heat> well, in my OS I also do security
<heat> I don't have a dedicated security guy
<mjg> do you have a security committee?
<heat> yes, we do trapsled by committee
<mjg> your nick is the length as theo
<mjg> and you even share 3 letters out of 4
<mjg> are you sure you are not his nephew
<zid> I have a security commity
<zid> I ask my stuffed animals if even heat could hack this
<zid> and they say no
<heat> I've just asked my stuffed Tigger and he says yes
<mjg> i asked bonwick
<mjg> he says i need to post a PSARC
<mjg> i don't know what these letters mean, but sounds serious
<mjg> i also like how it is an anagram from sparc
<zid> my method for avoiding exploits is just to never read user memory
<bslsk05> ​Note by Dave Fischer: "About ten years ago a flying squirrel snuck into my house and spent a few hours playing hide-and-seek with my cat. Anyways. Here's the best photo you're likely to ever see of a […]" https://media.hachyderm.io/media_attachments/files/109/486/285/065/480/741/original/dfb465e8b7dedad2.jpg
<heat> geist, btw if slap chop was a thing we'd be living in 2123 already
<heat> galaxy brain idea
<heat> I wanted grated oreos
<zid> you okay there heat?
<zid> sounds like you're having a mania attack about kitchen gadgets
<mjg> the slap chop thing is fucking great man
<mjg> will look for a project to write just so that i can name it like that
<heat> if someone renamed bionic slap chop it would be incredibly on point
<heat> literally a slap chop of libc's
<mrvn> zid: Don't trust the frog, it is lying to you
<mrvn> zid: also: big bug in his computer. Should be fixed asap. :)
<zid> I think we should slap chop freebsd
<heat> we should slap mjg and chop freebsd
<mjg> noo i'll give you dirt on solaris
<mjg> plz
<mjg> geist: the slapchop dude could easily be on peep show
<mjg> i totally see the 2 main anticharcters watching it on tv
<mjg> with one change that it would also make them question their life
[_] has joined #osdev
[itchyjunk] has quit [Ping timeout: 248 seconds]
[_] has quit [Ping timeout: 260 seconds]
tanto has quit [Remote host closed the connection]
pie_ has quit [Remote host closed the connection]
vancz has quit [Remote host closed the connection]
tanto has joined #osdev
[_] has joined #osdev
tanto has quit [Ping timeout: 248 seconds]
cross has quit [Remote host closed the connection]
tanto has joined #osdev
pie_ has joined #osdev
vancz has joined #osdev
hato-kokoro has joined #osdev
hato-kokoro is now known as yuriko
slidercrank has quit [Ping timeout: 248 seconds]
rensuiyi has joined #osdev
smeso has quit [Quit: smeso]
gxt has quit [Remote host closed the connection]
gxt has joined #osdev
rensuiyi has quit [Read error: Connection reset by peer]
jjuran_ has joined #osdev
aws_ has joined #osdev
terrorjack2 has joined #osdev
yuriko has quit [Quit: Konversation terminated!]
dutch has joined #osdev
DynamiteDan_ has joined #osdev
eck_ has joined #osdev
srjek has joined #osdev
yuriko has joined #osdev
gorgonical has quit [*.net *.split]
spikeheron has quit [*.net *.split]
Bonstra has quit [*.net *.split]
xenos1984 has quit [*.net *.split]
Brnocrist has quit [*.net *.split]
dennis95 has quit [*.net *.split]
knusbaum has quit [*.net *.split]
terrorjack has quit [*.net *.split]
eck has quit [*.net *.split]
Terlisimo has quit [*.net *.split]
jjuran has quit [*.net *.split]
DynamiteDan has quit [*.net *.split]
Patater has quit [*.net *.split]
les has quit [*.net *.split]
aws has quit [*.net *.split]
terrorjack2 is now known as terrorjack
jjuran_ is now known as jjuran
DynamiteDan_ is now known as DynamiteDan
eck_ is now known as eck
smeso has joined #osdev
Brnocrist has joined #osdev
Starfoxxes has quit [Ping timeout: 246 seconds]
Starfoxxes has joined #osdev
fedorafansuper has quit [Ping timeout: 248 seconds]
Patater has joined #osdev
dennis95 has joined #osdev
Terlisimo has joined #osdev
les has joined #osdev
xenos1984 has joined #osdev
knusbaum has joined #osdev
Bonstra has joined #osdev
knusbaum has quit [Max SendQ exceeded]
les has quit [Max SendQ exceeded]
les has joined #osdev
knusbaum has joined #osdev
terrorjack has quit [Quit: The Lounge - https://thelounge.chat]
XgF has quit [Remote host closed the connection]
terrorjack has joined #osdev
XgF has joined #osdev
[_] has quit [Remote host closed the connection]
gxt has quit [Remote host closed the connection]
gxt has joined #osdev
heat has quit [Ping timeout: 248 seconds]
srjek has quit [Ping timeout: 260 seconds]
bradd has joined #osdev
gxt has quit [Ping timeout: 255 seconds]
gxt has joined #osdev
MarchHare has joined #osdev
MarchHare has quit [Remote host closed the connection]
wand has quit [Ping timeout: 255 seconds]
gildasio has quit [Ping timeout: 255 seconds]
aws_ is now known as aws
wand has joined #osdev
fedorafan has joined #osdev
fedorafan has quit [Quit: Textual IRC Client: www.textualapp.com]
<kof123> PR/docs_12345 [2023-02-09] patch: fix rhyming, better pun 8< -little c89... -chinny chin chin... +little c89, let me in +not by the >= 8-bit char of my stdin 8<--- status: reviewed, merged to docs-stable
danilogondolfo has joined #osdev
fedorafan has joined #osdev
wand has quit [Remote host closed the connection]
wand has joined #osdev
gog has joined #osdev
pog has joined #osdev
pogchamp has joined #osdev
nyah has joined #osdev
gog has quit [Ping timeout: 268 seconds]
pogchamp is now known as gog
pog has quit [Ping timeout: 268 seconds]
GeDaMo has joined #osdev
slidercrank has joined #osdev
bgs has joined #osdev
<epony> huffing and puffy-ing
<epony> blow your standards inn
sakasama has quit [Quit: Bridge terminating on SIGTERM]
Irvise_ has quit [Quit: Bridge terminating on SIGTERM]
sham1 has quit [Quit: Bridge terminating on SIGTERM]
CaptainIRS has quit [Quit: Bridge terminating on SIGTERM]
yuriko has quit [Quit: Bridge terminating on SIGTERM]
chibill has quit [Quit: Bridge terminating on SIGTERM]
epony has quit [Remote host closed the connection]
epony has joined #osdev
sakasama has joined #osdev
Irvise_ has joined #osdev
CaptainIRS has joined #osdev
sham1 has joined #osdev
chibill has joined #osdev
CaptainIRS has quit [Ping timeout: 252 seconds]
sakasama has quit [Ping timeout: 246 seconds]
chibill has quit [Ping timeout: 252 seconds]
Irvise_ has quit [Ping timeout: 252 seconds]
sham1 has quit [Ping timeout: 260 seconds]
bradd has quit [Ping timeout: 248 seconds]
sakasama has joined #osdev
CaptainIRS has joined #osdev
Turn_Left has joined #osdev
Left_Turn has quit [Ping timeout: 265 seconds]
Left_Turn has joined #osdev
Turn_Left has quit [Ping timeout: 264 seconds]
justache is now known as deliriumt
deliriumt is now known as justache
Irvise_ has joined #osdev
sham1 has joined #osdev
barnsy has quit [Quit: leaving]
barnsy has joined #osdev
gildasio has joined #osdev
chibill has joined #osdev
heat has joined #osdev
gxt has quit [Remote host closed the connection]
gxt has joined #osdev
fedorafan has quit [Ping timeout: 248 seconds]
fedorafan has joined #osdev
ggherdov has quit [Ping timeout: 252 seconds]
paulbarker has quit [Ping timeout: 252 seconds]
<heat> mjg, why does the openbsd random(4) take potshots at other systems?
<heat> sortie, you forgot to mention this as part of the mdoc writing process
ggherdov has joined #osdev
paulbarker has joined #osdev
<heat> mjg, https://grok.dragonflybsd.org/s?refs=smr_read_enter&project=openbsd bro they have smr I can't believe this they're beating me in concurrency primitives
<bslsk05> ​grok.dragonflybsd.org: smr_read_enter (reference) in projects: openbsd - OpenGrok search results
mrvn has quit [Ping timeout: 260 seconds]
<sortie> heat, have you seen Sortix udp(4)? :D
<heat> oh cool you did a write up of your os-test results
<heat> "On OpenBSD, it is an alias for /dev/urandom, but on many other systems misbehaves by blocking because their random number generators lack a robust boot-time initialization sequence" this is the kind of elitist development one would expect from OpenBSD developers
<heat> I like how they completely forgot that their random code does questionable stuff and is entirely questionable itself
<heat> It also doesn't misbehave, /dev/random was always defined as blocking, but these asshats really wanted to rub their shit in didn't they
<heat> despite the only current system that still blocks on /dev/random being NetBSD
<sham1> I'm sure that changing the docs to update that little cute part is totally in the OBSD developers' priority
<kof123> wait until you see ruuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuus(t)
<kof123> the openbsd version will be vastly superior
<zid> dw heat
<zid> I 100% believe you are concurrently primitive
fedorafan has quit [Quit: Textual IRC Client: www.textualapp.com]
fedorafan has joined #osdev
bgs has quit [Remote host closed the connection]
srjek has joined #osdev
mrvn has joined #osdev
slidercrank has quit [Ping timeout: 248 seconds]
<heat> kof123, i seriously hope they game-of-trees rust
<heat> the world needs poor NIH reinventions of software
sinvet__ has joined #osdev
sinvet__ is now known as shinbeth
<gog> yes
<gog> we need as much of that as possible
<gog> more repeated code less quality
<zid> That's why I just rewrite everything from scratch every time I need it
<zid> it builds immunity to bugs
<gog> yes
<gog> i'm going to have to rewrite a bunch of things fom scratch because i forgot why they work
<zid> who knows how buggy some 20 year old line of code somewhere is
<gog> i will never comment code
<zid> comments don't help
<gog> comments are for babies and clowns
<zid> Just think, when you wrote it the first time, you were top of your game, you knew every character in that piece of code
<zid> and you still didn't write it correctly or you wouldn't need to be editing it
<zid> how are you going to compete with that just by reading a couple of comments?
<zid> Only solution is to delete and rewrite
<heat> gog, you know what's worse than comments? descriptive names
<heat> foh
<GeDaMo> At best, a comment is what you /thought/ you were doing :P
<zid> comments are all demonstrably false
<zid> if the comments were correct you wouldn't have the file open in your editor, thus you would not see them and they would not exist
<zid> if the file is open in your editor, the file is buggy, and thus the comments are incorrect about what the code does
<zid> ergo all extant comments are incorrect
<zid> QED
<heat> what if you're adding something to the file
<zid> then you're not reading the comments
<zid> and the comments are invalid even if you do, because they don't describe the new thing yet
wootehfoot has joined #osdev
<mrvn> What we need is a language that's just comments.
<GeDaMo> Whitespace? :P
<mrvn> any code will only deviate from the comments.
<mrvn> GeDaMo: that's rather blank
<geist> random? where rust is going they dont need random
gxt has quit [Ping timeout: 255 seconds]
gxt has joined #osdev
<\Test_User> mrvn: /dev/null as the compiler?
<\Test_User> ought to consider everything a comment ::P
joe9 has quit [Quit: leaving]
<mrvn> \Test_User: you missed the point. The compiler shall implement the commends, not the code.
<mrvn> comments are always right, comments don't have bug, do what I mean, not what I say.
<\Test_User> hmmm
<\Test_User> true
<\Test_User> .txt and let a human deal with it?
<GeDaMo> Wouldn't that be literate programming?
<heat> i'm starting to think that doing PAGE_SIZEd leaves on my radix tree may be a bit too much
xenos1984 has quit [Ping timeout: 248 seconds]
<heat> linux seems to do 6 bits per leaf. so 64 entries, 512 bytes
xenos1984 has joined #osdev
<heat> if I have a 4GiB file, it seems to work at around 16386 leaf tables plus all the usual radix tables in the middle
<heat> so 8MiB of radix, if we forget the middle tables... hmm
<heat> well, the amount of memory isn't going to change much, but the number of levels and the memory consumption for smaller files is
gog has quit [Quit: Konversation terminated!]
x8dcc has joined #osdev
levitating has joined #osdev
<levitating> Hey, this is really stupid but what are the answers to the sign up? I am not sure what fault causes reboots, and I am pretty sure the first program loaded off the disk is a bootloader but that's not true.
<levitating> Or correct I should say
<heat> what's the question?
<levitating> The program first loaded off of a disk when booting your computer is known as a <answer>.:
<levitating> or
<levitating> A reboot happens when a <answer> fault occurs.:
<heat> boot sector and triple
<heat> if boot sector doesn't work, bootsector
<heat> that should be it I think
<levitating> triple works, awesome
<heat> the reboot one is straight forward
<heat> yeah those questions are... silly
<levitating> The last time I had a registration challenge that challenging was signing up for hack the box
<heat> what are the questions for, again? wiki?
<levitating> Forum
<heat> ah
<levitating> https://wiki.osdev.org/CPUID the second instruction here (for checking cpuid availability) should be pop esp instead of pushfd right?
<bslsk05> ​wiki.osdev.org: CPUID - OSDev Wiki
<heat> pop esp is 100% wrong
<heat> routine does look weird tho
<levitating> You can't pop into esp or?
<zid> pushfd is a weird looking name takes me a second every time
<zid> pushf + dword I guess?
<heat> levitating, pop esp will thrash your stack
<heat> congrats, you crashed
<levitating> But this is before a stack is initialized
<heat> it's not
<heat> pushfd and push and pop all use the stack
<zid> gcc has cpuid intrinsics btw :P
<levitating> Oh I just realized how this code works
<levitating> I would've stored the EFLAGS into a register instead of reading it from the stack
<heat> use the gcc cpuid intrinsics
<heat> levitating, mov eflags ain't a thing
<zid> pushfd; pop eax
<levitating> You can move them via the stack, the CPUID check code in another page does that.
<zid> is precisely what that sippet already does
<heat> pushf and popf are the only way to do it
<bslsk05> ​wiki.osdev.org: Setting Up Long Mode - OSDev Wiki
<levitating> Has a different snippet for checking cpuid
<levitating> I am not using GCC, I am writing the initial bot stuff in assembly and then moving to rust.
<heat> "Basically Intel tried to get 64-bit processors on the market with EM64T, but failed to do so"
<zid> mov eax, eflags ; Note, psuedo instruction for pushf; pop eax, destroys [rsp]
<heat> hahahahahaha
<zid> there :P
<froggey> that still uses pushfd/popfd for getting/setting eflags
<levitating> heat: Ye that got a laugh out of me as well
<heat> you do realize the error right?
<heat> "Intel failed with EM64T, so they introduced IA-32e, then that failed, so they introduced Intel 64, those bastards!"
<zid> IA64 for life
<heat> god the wiki sucks
fedorafan has quit [Ping timeout: 252 seconds]
<heat> levitating, anyway what do you need this for?
<froggey> heat: but it's ~~~peer reviewed~~~ that makes it amazing
<levitating> Checking if I can switch to long mode right?
<zid> failing gracefully on pentium 4s is important
<heat> i mean... don't bother?
<levitating> ¯\_(ツ)_/¯
<heat> it's not like there's a fallback here
<zid> when rust getting intrinsics
<levitating> Both the rust guide and OSDev I am following cared to do it, so whatever.
<heat> 1) seriously, checking for cpuid? this is pentium-old
<heat> 2) you check for long mode, it fails. what now? hlt?
<heat> there's no solid fallback
<zid> printing a nice message
<levitating> print an error to the screen
<froggey> print an error then hlt
<zid> saying "buy a real cpu lol"
<levitating> lmao
<heat> yeah printing an error but "uh oh what, this doesn't support VGA text mode??"
<zid> is efi old enough that amd64 wasn't supported at any point heat
<heat> yes
<zid> fucking efi
<heat> EFI was originally made for IA64 AIUI
fedorafan has joined #osdev
<mjg> bring back IA64
<heat> then around the early 2000s they backported x86 support
<mjg> revert any pessimization to it
<heat> mjg, ur enemy number 1 for IA64 fans
<zid> early 2000s is amd64 though
<mjg> heat: you computer necrophiliac!
janemba has quit [Ping timeout: 248 seconds]
<levitating> What do you guys think about arm instructions?
<heat> love em
<heat> or hate em
<mjg> hate em
<mjg> why love em
<mjg> lol @ ll/sc
<zid> hate em
<heat> why not
<mjg> you are a contrarian heat, aren't you
<mjg> kernel in c++
<mjg> love for itanium
<mjg> lol atomics in the fast path
<heat> geist also has a kernel in C++ and loves itanium
<mjg> os hipsters
<heat> if anything you're the contrarian
<mjg> i'm the reallifean dawg
<heat> so why do you work on freebsd?
<heat> that is not real life
<mjg> dude i can almost guarantee you are seeing some packets pushed through it
<mjg> you do know that right
<heat> cry
<mjg> worse though, there are probably people on this very channel who get packets touched by openbsd itself
<mjg> and not from their home router\
<heat> all the routers between libera and me run microsoft windows 8
<zid> vxworks is all we need
<Ermine> didn't see anyone having zig in the kernel
<heat> windows 8 is the ideal windows experience
<heat> mjg, also did you see the shit i linked those fucks have SMR AND I DONT
<mjg> that openbsd has one?
<heat> yes
<levitating> What kind of OS are you guys on?
<mjg> they had a lol variant for years mate
<heat> levitating, fentany... oh you said OS
<mjg> and it makes sense especially at their stage of development
<heat> linux
<mjg> albeit i don't know if they made it for that erason
<Ermine> heat: daily driving onyx when
<mjg> key point being that a big codebase with epsilon smp awaraness will keep running into massive lock ordering issues
<x8dcc> heat: I am also addicted to fentanyl
<heat> when fix filesystem and vm and make everything go vruuuuuuuuuuuuuum
<mjg> ... which you can largely skip if you do lockless
<levitating> daily driving hurd when
<heat> never
<mjg> brauh
<mjg> $ uname -a
<mjg> GNU/hurd motherfucker
<levitating> lmao
<mjg> oops did not copy the entire line
<mjg> GNU/hurd motherfucker ia64
<heat> oh fuck yeah
<heat> Debian/Hurd ia64
<x8dcc> s/De/Les/
<heat> you ruined it
<levitating> top tier humor
<mjg> les hurders
<Ermine> 'd just like to interject for a moment. What you’re referring to as Hurd, is in fact, GNU/Hurd, or as I’ve recently taken to calling it, GNU plus Hurd.
<x8dcc> Debian is for very masculine men
<heat> Ermine, WRONG
<mjg> Ermine: GNU/Hurd-libre
<heat> it's GNU Hurd
<heat> not GNU/Hurd
<heat> Hurd is itself part of the GNU project
<mjg> stallman will have a word with you once he stops chewing foot food
<Ermine> heat: GNU then
<GeDaMo> I don't know, Hurd seems very divisive :P
<levitating> Checking the recent commit history does not give me much trust that hurd will ever finish lmao
<heat> operating systems never finish
<Ermine> heat: the OS is GNU, uses Hurd, therefore GNU/Hurd is correct if you want to highlight the kernel imo
gog has joined #osdev
<x8dcc> only hope finishes
<mjg> levitating: dude
<heat> Ermine, why would you? It's all GNU, the GNU operating system
<mjg> levitating: they have a paper somewhere about "hurdng", discussing how the current hurd is a turd
<mjg> :]
<levitating> lmao
<mjg> by design
<heat> GNU turd moment
<heat> this post was sponsored by MICRO$HIT WINBLOWS
<levitating> I just love the fact that Stallman is annoyed GNU is used on non-linux kernel while at the same time GNU has been working on their own shit show of a kernel for 20 years
<levitating> That will never ever be used by anything fucking ever
<x8dcc> let them have fun
<levitating> Judging by the commit history they're not having much fun lmao
<x8dcc> as heat and more people here can tell, I have had fun while suffering for some days
<mjg> dude the only hurt utilit for the past 20 years is making fun of its existence
<mjg> hurd
<heat> "Stallman is annoyed GNU is used on non-linux kernel" huh?
<heat> GNU was supposed to be used on non-GNU and non-Linux kernels since always
<Ermine> Meanwhile that one guy that hacks on Hurd part time: https://i.kym-cdn.com/photos/images/original/001/878/329/dfa.jpg
<x8dcc> stallman is a horny old man that drinks wine
<x8dcc> and I love him
<levitating> lmao
<FireFly> Stallman seems annoyed, like, just in general tbh
<x8dcc> its his role in this world
<gog> hi
<Ermine> hi gog, may I pet you?
<gog> yes
* Ermine pets gog
* gog pr
* Ermine aw
joe9 has joined #osdev
<x8dcc> sus
<x8dcc> thats what young people say
<FireFly> pets are good
<geist> heat: ITANIUM
<nikolar> we just weren't ready for itanium
<mjg> did you even port to itanium though?
<zid> The problem with iranium is the rest of reality
<heat> mjg, send me one of them noisy machines and consider it done
<zid> the types of problems we try to solve just don't fit with itanium
<mjg> heat: qemu motherfucker
<zid> so we find ourselves at fault
<heat> mjg, there's no qemu ia64
<mats2> sus
<heat> motherfucker
<mjg> what
<heat> the only emulator out there is an obscure HP thing AFAIK
<x8dcc> based
<nikolar> doesn't intel still make some itanium cpus
<heat> no
<nikolar> because of their contract with ibm or something
<heat> AFAIK they stopped all ia64 production 5 years ago or so
<mjg> huh
<mjg> i found some experiemntal github repo
bnchs has joined #osdev
<bnchs> hi
<bslsk05> ​pvaibhav/qemu-ia64 - Intel Itanium (ia64) Linux user target for Qemu (5 forks/24 stargazers/NOASSERTION)
<x8dcc> what do you think about IBM as a company
<mjg> heat: accept my apologies
<heat> yeah dude 2011
<heat> for linux usermode
<bnchs> how are you all?
<mjg> how did the necrophiliacs let this happen?
<nikolar> bnchs: not bad
<nikolar> you
<mjg> they do know their precious bare metal is gonna break sonner than later
<mjg> dn't they
<heat> mjg, gentoo users are too busy recompiling chrome every 3 days to write a qemu ia64 backend
<mjg> do they have fpga emulators? :p
<mjg> heat: 's debian
fedorafan has quit [Ping timeout: 248 seconds]
<mjg> which protested
<bnchs> i'm trying to figure out how to simulate a 32-bit memory map for emulating a 32-bit program (compatibility layer) in a 64-bit OS
gildasio1 has joined #osdev
<bnchs> well.. 24-bit
gildasio has quit [Remote host closed the connection]
<heat> mjg, debian users are too busy smelling glue to write a qemu ia64 backend
<x8dcc> facts
<mjg> heat: too busy rejecting firmware
<zid> refreshing keys yo
<heat> bnchs, what's the problem?
* sham1 looks at backlog
<zid> mmap(24bit space)
<heat> mjg, glue is FREE as in beer and FREE as in speech
<bnchs> i'm making a compatibility layer between another OS and Linux/BSD/whatever,
<zid> done?
<heat> can't say the same for all the proprietary opioids
<zid> emerge --sync && emerge -u chrome time
<sham1> I like Itanium. Makes for a good compiler target with how many little switches it gives you
<sham1> Good in theory. Sadly it fell through
<zid> it's not even good in theory
<zid> vliw is bad
fedorafan has joined #osdev
<zid> software instruction scheduling is only a win if you are definitely running a static load with no branches or cache effects etc etc
<zid> and then it allows you to remove all the reordering etc hw and run the chip harder for the same power budget
<bnchs> it's in a different processor, so the program in question will only be able to access up to 16 MB of memory
<sham1> Which for pure numeric computation you are
<zid> which is precisely 0% of all software
<bnchs> but i have to map some of the objects that the compatibility layer has allocated to it, to the emulated process' map
<sham1> I care about number crunching. F-ing data science, man
<bnchs> and the problem is if one of those objects gets bigger than 16 MB
<zid> good news on my gentoo updates heat, I need to redo 78 packages because python 3.8 is now deprecated
<sham1> Also also, Itanium gave C++ an ABI
<zid> which happens every fucking week or two
<nikolar> sham1: kek
<heat> zid, reject gentoo, use arch
<zid> does arch not update their python
<sham1> > Arch
<sham1> Fucken
<nikolar> arch doesn't require users to build python :)
<x8dcc> I gdb is broken in arch for some reason
<x8dcc> s/I/my
xenos1984 has quit [Ping timeout: 248 seconds]
<x8dcc> in gentoo (what I am using now) works fine
<nikolar> or you could switch to artix if you want to get away from systemd
<zid> I already am away from systemd
<heat> x8dcc, shrug, my gdb works a-ok
<x8dcc> heat: what distro
<heat> arch
<zid> context bro
<x8dcc> hmm
<nikolar> zid: i know you are, we are talking about switching to arch
<zid> then the word's 'stay' not 'get'
<zid> PSA
<heat> the best part about staying away from systemd is struggling to install basic shit
<nikolar> zid: fair
<nikolar> heat: can't really say i've struggled but ok
<zid> best part is figuring out how the fuck X works now
<sham1> Staying away from systemd isn't all that difficult
<zid> cus all the resources now assume systemd
<zid> everything else is fine
<nikolar> what are you using
<nikolar> dm or de
<sham1> Most often all you need is elogind and you're golden
<nikolar> true
<zid> I gave up on logins and greeters and shit instead
<zid> and switched to startxfce4
<zid> ran as root
<zid> :D
<nikolar> ke
<nikolar> lol
<heat> nikolar, if you haven't struggled it's because your distro maintainers are doing a good job
<heat> no one supports run scripts or whatever anymore
<nikolar> heat: well i am also a maintainer :)
<nikolar> not on init stuff though
<heat> cool
<zid> idk why I'd switch away from gentoo
<zid> I might have to switch to systemd at some point though
<zid> when it just gets so unreasonable not to
<zid> same with me switching from windows 7
<x8dcc> unreasonable? why?
<zid> things change
<zid> people add more and more hard deps to more modern stuff
<x8dcc> hmm I see
<zid> "javascript is everywhere now, we can just expect json to be fine here"
<zid> now you rely on spidermonkey, etc
<zid> it all piles up until eventually there's 0 configurations that don't need certain things
<nikolar> we aren't anywhere near that point yet
<zid> depends what you have installed
<heat> yes we are fucking are
<zid> X is getting there
<zid> udev had to be forked
<zid> etc
<zid> without that fork it'd already be the case
<nikolar> fair point
<heat> there's little point in not using systemd (the service manager) on Linux
<heat> just weird stubbornness
<zid> I just hate learning new things
<heat> and hurr durr not the unix way
<zid> I want to push the power buton and have it work how it did the last time I pushed it
<nikolar> and i hate how they are trying to push their will on other people
<zid> not suddenly be skinned completely differently and all the commands no longer work
<heat> nikolar, what will?
<heat> please, tell me something "they" (who is they? the NWO?) are trying to push
<zid> The HOA
<nikolar> mostly poettering
<nikolar> for example refusing to fix their own crap but insisting on the kernel maintainers to implement whatever sysd needs
dude12312414 has joined #osdev
<heat> that happened once with the debug in /proc/cmdline string stuff
<heat> and what exactly did they push on people?
<mjg> kdbus
<mjg> that one was glorious
<heat> kdbus was wanted by kernel people
<mjg> nope
<heat> like gkh
<mjg> that bit i know, you missed allt heo ther people who had a different take on it
<mjg> it got immediately called out when submitted
<epony> don't name one person to be a culprit of changes that are mandated by parenting and employer organisations
<mjg> they claimed performance
<heat> dbus is also not at all a systemd thing
<mjg> then someone profiled the userspace variant and showcased lollers
<mjg> aaand it suddenly died off
<epony> address the "proposed solutions" instead of the people making the proposal
xenos1984 has joined #osdev
<mjg> heat: cmon dawger
<mjg> next you are gonna tell me udev also is not
<zid> heat's in the soup
<heat> anything desktop depends on dbus
<epony> it does not
<heat> udev is literally in the systemd repo
<epony> that's a fairly late and particular implementation of message passing in a "bus" abstraction
<heat> dbus is under freedesktop and depended on by half the linux desktop world
<epony> before that there were others, after it there will be others, along it are other such IPC/RPC control and data exchange models
<epony> neither unique, nor special, and certainly not the best in class
<heat> in fact, dbus does not require a specific implementation, such that kdbus was a thing and the systemd idiots got their own
<epony> there are many people with ideas
<epony> implementations compete, various models and topology and accompanying utilities too
<epony> standards "are the end product"
<epony> for the time being, it's just a CVE generator "pit"
<sham1> dbus is an annoying protocol
<sham1> The wire format especially
<sham1> Eugh
<epony> dangling XML nodes anyone..
<epony> million laughs
<epony> etc
<epony> there are lots of challenges
<epony> message passing is important however
<epony> objects too
<epony> C++ has 2 main objectives, developing new languages and message/object passing interfaces (brokerage)
<epony> that's one more than C
<sham1> C++ has the objective of cramming as many different features into a single language while trying to remain at least slightly coherent. I leave it to others to consider whether they succeed
<zid> if 'slightly' is the bar then yes, it is debateable.
<heat> what does that have to do with systemd
<zid> no idea
<zid> or dbus either
<sham1> Nothing
<heat> do you want me to shit on C++?
<epony> on your hands doing IPC/RPC
<nikolar> heat: sounds like fun time
<heat> https://www.reddit.com/r/osdev/comments/10xz39w/sigabrt_sender_process/ in this thread, everyone is wrong about everything
<bslsk05> ​www.reddit.com: Reddit - Dive into anything
<zid> well it's reddit
<sham1> Well it's /r/osdev. I'm not all that surprised
<sham1> The actual wiki forums are better, but I still feel that this very chat is the best place to discuss this stuff in
<x8dcc> heat: well nvm, gdb is also not stopping at breakpoints in gentoo. Is that related to paging?
<bslsk05> ​www.reddit.com: Reddit - Dive into anything
<heat> mjg, ^^ found the NetBSD dev
<zid> did you break on the physical or the virtual address
<zid> or via symbol name, or what
<x8dcc> zid: I break on function name, but mapping is 1:1
<mjg> heat: to be fiar, the lua thing in kernel ws a one person ordeal afair
<epony> via gen2
<x8dcc> ^
<sham1> > You can write a kernel that _runs_ Lua, but you can't write a kernel _in_ Lua.
<sham1> Wrong
<zid> You can write 98% of a kernel in lua
<sham1> In fact, confidently incorrect
<zid> unless you have a lua cpu to hand
<zid> someone's gotta write a bit of asm/C to host it
<sham1> Like sure, you'll need some assembly, but that's also the case with C and no one's saying that you can't write a kernel in C
<epony> you can do anything, but you can't prove computational reliability in functional transformations
<zid> I meaaan, the C is all intrinsical
<zid> so you sort of can these days
<heat> mjg, such a lunatic idea, why would anyone want a bytecode interpreter to inject random code into a kernel
<zid> attribute interrupt and the like
<heat> that idea would never see the light of day on e.g Solaris or Linux
<zid> yea, I hate acpi too
<sham1> And eBPF
<mjg> heat: did you want to say luatic?
<x8dcc> zid: so any idea on why is not stopping?
<heat> heheheehehehehe
<epony> moonotick kernels
<heat> x8dcc, qemu gdb is spotty sometimes
<sham1> heat: anyway, this is why it's good that NetBSD and the like exist, so we can have something to do this kind of interesting research on. Because as you said, this'd never happen on Linux or Solaris; they're not interesting research OSes
<zid> x8dcc: nope
<x8dcc> well it was not like that before, so I guess it's because of paging
<heat> sham1, yes it would?
<x8dcc> but it should not matter
<epony> interesting research is a dfferent organisation of the kernel, for now, they are mostly similar
<heat> I was joking when I said that (as per eBPF)
<heat> and dtrace
<epony> deathrace ;-)
<epony> at some point it'd need HW assist
nytpu has left #osdev [WeeChat 3.8]
<epony> negative rings etc
<heat> sham1, also, I do see the value in NetBSD.
<epony> (management / debug engines)
<heat> dragonfly and open are the ones I couldn't give two shits about
<sham1> But yeah, alongside microkernels, this is the kind of thing that interests me. I've actually seriously thought about having interesting languages in kernel-space like JavaScript, maybe even with a full JIT compiler, but that'd require me to write an implementation and I can't be fudged
<heat> thought of that, someone already beat me to it and embedded v8 as the kernel
<sham1> Although a bootstrapping JS implementation in JS would be an interesting experiment
<epony> there is one more that does not yet exist about the new kernel organisation (without the input of Tanenbaum-like advisors)
<sham1> But again, that'd require writing a JS implementation
<heat> use v8
<heat> or bun, bun is the hot new thing now isn't it
<epony> it's called vv8
<sham1> But why, that's in C++
<sham1> That's exactly the kind of thing I wouldn't want. I want to bootstrap the language itself into the kernel-space
<heat> how else would you write a js interpreter?
<heat> you can't write a js vm in js unless you have another vm written in C++ on top
<sham1> In JS. Then you compile it to machine code with said implementation
<x8dcc> heat, zid: I fixed it by using hbreak instead of break
<epony> actually you want the post-C++ machine specific derivate of it
* x8dcc shrugs
<heat> sham1, hmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmm. there might be a way to tweak v8 into doing that
<heat> probably your best shot
<epony> that's what "larger than you" businesses are doing.. since the late 80ies
<zid> hyperbreak
<sham1> So you basically compile the compiler in itself, solving the bootstrap problem. I mean, we clearly know this kind of an approach works; Mezzano exists
<zid> why does your gdb not default to hbreak
<zid> set breakpoint auto-hw on
<gog> hbreak???
* gog invetigates
<epony> there is an extra G in most of the concepts you're using ;-)
<heat> gog, hardware breakpoints
<gog> yes
<heat> wit le cpu and stuff
<zid> dr0
<gog> interesetting
<zid> dr0g
<heat> gr0g
<gog> gög
<sham1> gøg
<heat> goog
<sham1> Alphabet
<heat> abc
<sham1> Petrol station
<x8dcc> gog: I had no idea what that was. hardware break
<heat> i too like holding companies
<heat> bp
<x8dcc> in my case, I had to "target remote :1234" before doing the hbreak in order to work
<heat> x8dcc, you know you need to do that always right?
dude12312414 has quit [Remote host closed the connection]
<x8dcc> heat: well I was able to place breakpoints before connecting
<heat> doesn't matter, they won't work
<zid> because
<heat> try break now
<zid> you can always just set them
<x8dcc> what I am saying is that they worked before, I don't know if that's not supposed to happen
<heat> it probably stops working thru the paging setup barrier due to $reasons
<x8dcc> well using break after connecting doesn't work either
<heat> try after paging
* gog breaks
<heat> gdb is absolutely fucky
<sham1> Oh no
<heat> when it comes to qemu that is
<heat> i just use gdb to debug crashes
<heat> like hlt; and attach + walk around the stack
<x8dcc> I am trying to figure out why my framebuffer thing crashes with paging, btw
<zid> why not check the exception
<zid> that's easiest
<x8dcc> I mapped 512 MiB 1:1 to try it
<heat> because you didn't map it?
<heat> info mem
<heat> if its not a vga framebuffer it's going to be up in the 3GB zone
<x8dcc> heat: ah, that's probably it :(
<x8dcc> well shit
<zid> you should really
<zid> write a map function
<zid> that takes a virtual and physical pair and sets that mapping up
<zid> and do everything through that
<Ermine> heat: can gdb use OS symbols if it is built with -g
<Ermine> ?
<zid> uintptr_t fb = fb_get_phys_addr(); map(0xBEEF0000, fb); *BEEF0000 = RED;
<zid> or just map(fb, fb) and keep it linear, whatever
<epony> that's the interesting area of research, stream and block processors working on memory regions near and for the main and application processors and the i/o periphery
<x8dcc> zid: yeah, I have been looking at some stuff, but I am not sure what I need to get it to work
<zid> ?
<x8dcc> anyway, I am going to try to make that map function
<x8dcc> zid: I mean stuff like page allocation
<zid> what page allocation
<x8dcc> I am talking about some functions I saw people were using, and I don't know what they are for
<zid> I guess you need a couple of spare pages if you haven't got that exact PT available
<zid> http://shogun.rm-f.net/~zid/page.html this is 64bit but this is effectively all that map function does, figures out which slots in which tables that virtual address is, then writes addr | PT_PRESENT there
<bslsk05> ​shogun.rm-f.net <no title>
srjek has quit [Ping timeout: 246 seconds]
<zid> ffffbeef0000 -> pml4[512]->pdpt[510]->PD[503]->PT[240] = addr | PT_PRESENT;
<x8dcc> I see. Thank you
<zid> your numbers will be different cus you get 1024 entries per table not 512 though
<x8dcc> yeah, got the idea
<zid> 511*
<zid> pml4[512] is a nice crash
Ameisen has quit [Quit: Quitting]
Ameisen has joined #osdev
<heat> Ermine, what OS symbols? kernel syms? yes. user syms? also yes, but depends
<zid> heat: Where my 32bit page for page.html?
<heat> PIE, shared libraries are tough to get syms for. also debugging user level stuff is super duper hard with gdb attached to qemu
<heat> you're just at the wrong level of abstraction
robem has joined #osdev
<heat> with threads constantly switching and then your stepping getting interrupted by IRQs, etc
<zid> yea that's why once you have usermode you wanna port gdb
<zid> so you can run it on the right level
<heat> yeah that's one of my TODOs. lldb seemed easier, but gdb is also an option
<zid> you could also
<zid> implement a kernel gdb stub that opens a new port for each pid
<zid> :D
<heat> you're evil
<levitating> awesome
<heat> Ermine, anyway any time I need to e.g stop a process I just panic() and then add-symbol-file the executable. easy on my init, which is statically linked and not PIE
<heat> but this is a horrible solution
<heat> ... also won't work if you need to demand fault something
<heat> right?
robem has quit [Quit: Client closed]
robem has joined #osdev
slidercrank has joined #osdev
k0valski18891 has quit [Ping timeout: 252 seconds]
<x8dcc> I see addresses 0xFFC00000 being used for page tables, is this just preference?
<zid> might that be a dirty recursive map
<zid> heat: https://i.redd.it/2d4e1j8vu1ha1.jpg stop sending me pictures of your bedroom
k0valski18891 has joined #osdev
wand has quit [Remote host closed the connection]
fedorafan has quit [Ping timeout: 246 seconds]
wootehfoot has quit [Read error: Connection reset by peer]
wand has joined #osdev
Burgundy has joined #osdev
utzig has joined #osdev
<geist> preference
fedorafan has joined #osdev
heat has quit [Read error: Connection reset by peer]
heat has joined #osdev
<x8dcc> geist: thank you
<x8dcc> well I mapped my framebuffer manually when I fill the page tables, but I am not sure how I am supposed to map a new address after the initial fill. For example, do I need to map my page tables itself? (which is what I think I am seeing)
<clever> x8dcc: if you want to modify the pagetables, then some virtual address must map to the phys addr the tables live in
<clever> and then to map something new, you just compute where in the tables its virt addr lives, and write to that slot
<clever> allocating pages and adding branches to the tree as needed
<x8dcc> hmm I see. Thanks
<clever> to unmap things, clear that slot in the tables, and flush the TLB
<x8dcc> although I learned a lot, this paging journey has been a bit demotivating, ngl
<GeDaMo> Welcome to osdev! :P
bch has joined #osdev
<netbsduser`> x8dcc: you might learn to love it
<netbsduser`> the vmm is certainly one of my favourite things to work on, i just recently added swapping to mine
<x8dcc> well, thing about paging is that I don't *need* it right now, so it seems kinda pointless at first sight
<x8dcc> I still want to add it, but you know
<x8dcc> netbsduser`: that's cool :)
<netbsduser`> it may seem pointless right now, but it is the foundation of most modern general-purpose operating systems
<x8dcc> yeah, that's why I still wanted to add it. Just know that I learned 90% of what I know about paging here, and I spent time searching lol
<vin> Is anyone aware of database or storage engines that use the Key-Length-Value format? https://en.wikipedia.org/wiki/KLV
fedorafan has quit [Ping timeout: 252 seconds]
<vin> Also, I am curious about your thoughts on the ongoing fervor of LLMs and it's impact on OS development.
fedorafan has joined #osdev
<epony> we call that RAM defragmenter
<epony> and respectively fragmentation server applications
<epony> everything looks quite nice after a long and memory fulfilling compilation
<epony> that goes to waste the moment you start the memory storage services
<epony> that explains the modern software strive for continuosly defragmented memory state
GeDaMo has quit [Quit: That's it, you people have stood in my way long enough! I'm going to clown college!]
<epony> repetitive, long lasting, and ever-more orderly
bauen1 has quit [Quit: leaving]
fedorafan has quit [Ping timeout: 252 seconds]
fedorafan has joined #osdev
heat has quit [Read error: Connection reset by peer]
heat has joined #osdev
danilogondolfo has quit [Remote host closed the connection]
heat has quit [Read error: Connection reset by peer]
heat has joined #osdev
shinbeth has quit [Ping timeout: 256 seconds]
<heat> zid, wtf i'm not a man united fan what do you think I am
<heat> I'd need to live either in London or the middle east for that
<zid> or... manchester?
<heat> no
<heat> half of man utd fans live in London, 25% in the middle east and 25% in the US
<heat> and this is fax
xvmt has quit [Read error: Connection reset by peer]
xvmt has joined #osdev
<zid> no this is a fax, 0xFF 0x12 0x..
<sham1> Not even email :(
<zid> heat is surprisingly retro at times
<heat> caveman heat enjoy 1970 tech unix good fork good modernity bad
<sham1> C++ bad
<heat> c++++ horrendous C perfect perl perfect unix pipeline
<zid> correct.
<sham1> This but unironicallyu
<heat> cpp | cc best
<sham1> And yeah, fork is good. File descriptors are the best
<heat> oh yes everything is a file procfs great sysfs great devfs great
<mjg> burp
<heat> but static devfs great, auto devfs horrendous bad not traditional
<mjg> lol @ devfs as seen in linux
<mjg> especially their original implementation
<mjg> what a joke
<heat> wtf's wrong with linux devfs you freebsd fuckboi
<mjg> what? nothing!
<mjg> it is amazink
<mjg> everyone knows
<heat> this but unironically
<mjg> is it even an actual devfs?
<sham1> udev is evil
<mjg> afair they just slapped some crap on top of tmpfs
<mjg> and said voila
<sham1> Alongside netlink
<heat> mjg, dude, devtmpfs just works
<heat> there is *nothing* wrong with it
<mjg> you know what else just works? actual devfs
<heat> what's an actual devfs?
<mjg> aand does not need udev to mknod squat
<heat> you don't need udev for shit with devtmpfs
<heat> try again
<mjg> really? will have to check, mate
<heat> yep
<mjg> have not seen it in quite some time
<mjg> if they fixed that, i retract my main objectino
<heat> sudo mount -t devtmpfs none <dir>
<heat> the only thing you may need udev for is device renaming and weird symlinks you may want
<heat> but the base devfs they give you is perfectly ok
<mjg> quite a change dawg
<mjg> very unlinuxey
<sham1> Of course there are some annoying parts about POSIX especially
* sham1 glares at ioctl
LostFrog has quit [Remote host closed the connection]
<heat> unix is hot garbage
<heat> fact
PapaFrog has joined #osdev
<mjg> OOOH
<sham1> Should have just adopted plan9
<mjg> dmr rolling in his grave
<mjg> or maybe his ashes bouncing, who knows
<sham1> Distributed systems galore
<heat> mjg, yeah was just testing rn if it actually added hotplugged devices and yes
<heat> so highly poggers
<sham1> UNIX for all its warts did survive the test of tim e and the var ious paradigm shifts within computing, where many other paradigms just died
<sham1> That has to count for something
<heat> mjg, you know who added devtmpfs?
<heat> kay sievers
<mjg> :d
<mjg> no comment
<heat> the systemd 2nd antichrist himself
<zid> kay sievers sounds like a pirate
<sham1> mjg: I was expecting :q
<mjg> well i don't know the guy
<kazinsal> today in fucked up machines I found at work: an ACPI memory map where the starts are right but the lengths are all 0. you get to guess your memory map!
<mjg> just remember one lkml rant by someone you know
<heat> kazinsal, ACPI does not have a memory map tho?
<zid> kazinsal: neato
<kazinsal> s/acpi/grub/
<kazinsal> staring at this thing broke my brain
<zid> e820*
<kazinsal> because it's 80% ACPI entries too
<zid> (grub just gets it from the e820)
<heat> kazinsal, efi machine?
<kazinsal> think it's CSM
<heat> ah
<heat> well, don't
<heat> no need to thank me
<kazinsal> I'm trying to debug this poor busted blade
<kazinsal> unfortunately there's a vendor BIOS password lockout on it that persists through a CMOS clear so I need to find the reset jumper and a pair of tweezers
<heat> sham1, btw yes, unix surived the test of time after many many many hacks
<heat> like COW fork
<heat> and suped up pipes that do all sorts of shit
<sham1> Hacks or not, it shows that it can adapt
<heat> and like 4 or 5 IPC mechanisms
<heat> all of them suck
<heat> the unix way with small utilities and pipes is also ideologically busted
<sham1> It's similar to functional programming
srjek has joined #osdev
fedorafan has quit [Ping timeout: 252 seconds]
fedorafan has joined #osdev
[itchyjunk] has joined #osdev
<x8dcc> heat: can I send you a private message?
<heat> yes
<zid> heat can I send you a privates message
<heat> yes
<x8dcc> zid: you made me this way
<kazinsal> 8===D
<zid> kazinsal: Pretty much what I sent, yes :P
<zid> github just emailed me
<zid> r4v10l1 tagged me and heat in a commit for paging
<zid> also you spelled important wrong, x8dcc
<heat> lol
<x8dcc> zid: hmmm??
<zid> seems awfully suspiciously timed if it wasn't you
<x8dcc> well I like it that way
<x8dcc> so cope
<zid> imporant sounds like.. a cross between implore and impotent
<zid> to beg soft dickily
<x8dcc> dont disresnptect my art
xenos1984 has quit [Read error: Connection reset by peer]
<bslsk05> ​github.com: bazinga by heatd · Pull Request #4 · fs-os/fs-os · GitHub
<zid> yea it's fine, just the pselig
<zid> that description though, eesh
<heat> x8dcc, what's wrong with your philosophy»
<heat> GNU, suckless, cat-v and templeos?
<zid> sounds like someone took a set of darts to a graph of all of osdev
<x8dcc> heat: well it looks like I am "based"
<heat> $ make fs-os.iso # If you haven't built sysroot before, it will fail
<zid> More based than heat at least, he uses bazinga
<heat> you know targets can have dependencies right?
<x8dcc> can you not bully me
<x8dcc> I am fragile
<x8dcc> heat: I USE THEM
<heat> well not here apparently
<zid> fs-os.iso: sysroot
<zid> there you go
<zid> fixed it for you
<x8dcc> hm??
<x8dcc> I use them
<x8dcc> wtf
<bnchs> can I send someone a private message?
<heat> yes
<x8dcc> yes please do
<heat> flood my dm inbox you fucking weirdos
<zid> such a zoomer
<x8dcc> so true
<bnchs> rude
<bnchs> how much does a private message cost?
<heat> 0
<heat> this isn't onlyfans
<heat> yet
<bnchs> what? i thought it was like mail
<bnchs> you have to buy a stamp to send mail
<x8dcc> yes
<x8dcc> you pay with your soul
<bnchs> wow this is new technology
<x8dcc> this is all zid's fault
<bnchs> can you teach your old grandpa how to send those "private messages"?
<heat> no
<heat> rtfm grandpa
<bnchs> damn it
<zid> how much do "dm"s cost heat
<bnchs> where are my glasses!
<zid> is 'dm' DCC CHAT? btw?
fedorafansuper has joined #osdev
fedorafan has quit [Ping timeout: 248 seconds]
<nikolar> you can send a private message to me too
xenos1984 has joined #osdev
<epony> check your swap file for the messages
epony has quit [Quit: QUIT]