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
<heat> netbsd has relookup
<mjg> too generic of a name don't ya think
<mjg> there is even lookup
<heat> it's the unix way
<mjg> exported to be abused by nfs, but maybe they fixed that bit
<heat> short and vague names
<heat> brelse, bread
<mjg> butter
<heat> hmmmm, butter
<heat> buttshitfuckthisrenamecrap
<mjg> fucking vfs_bio is another can of wormz
<heat> as would be netbsd ufs tradition
<zid> The vfs has evolved to be partially biological now? oh dear
<mjg> unix vfs is a practical joke which got way out of hand
<gog> dnafs
<heat> cumfs
<zid> heatfs
<heat> zid
<zid> heat
<heat> gog
<gog> gog
<heat> go
<zid> grog
<mjg> brian
<zid> Mateusz Guzik
<mjg> no, me and your wife are brian
<gog> zid has a wife?
<heat> its mjg
<mjg> did i match your name by accident? :S
<zid> gog like "zid has a wife!??//// don't believe that for a fucking millisecond"
<gog> i didn't say that
<zid> I have lots of waifus actually
<gog> waifu
<mjg> there is a video on the interwebz where someone talks why having a waifu is not weird
<mjg> i did not have what it takes ot click on it though
<heat> least weeb bsd user
<zid> confirmed
<zid> heat is the chaddest person to have ever looked at the bsd source infact
<heat> oh absolutely
<heat> >looks at bsd source
<heat> >looks at nerds raging at rename
<heat> nerds lmao
<zid> Unfortunately it causes both feminization and carcinization, so you are now a female crab
<heat> hot
<zid> actually yea that's not unfortunate
<zid> gog: Which eva girl is best girl?
<gog> the one whose brain is part of that computer
<gog> goals
<zid> ritsuko akagi's mother
<zid> acceptable answer I suppose, I beat heat would have said something dumb like asuka
StoaPhil has joined #osdev
<zid> and not even the good disassiative state asuka
<heat> best eva girl is cristiano ronaldo
<zid> that's actually a better pick than asuka
<heat> goal siuuuuuuuuuu
StoaPhil is now known as dutch
<dh`> hmm looks like I missed the rename fun
<dh`> mjg: surviving dirconc is only the first step. the volume has to pass fsck afterwards too
epony has joined #osdev
<mjg> dh`: i just ran it a bunch of timeso n ufs, no issues, and fsck is clean
<mjg> will leave it in a loop
<heat> so my dentry locking is shit
<heat> what do
<mjg> embrace the suck
<zid> make one of those "we've been fooled" ludite meme posters
<zid> but make it about dentry locking
<mjg> i presume you don't have anything to tell you about an impeding deadlock
<dh`> just adjust the constants so it runs longer, or with more subprocs, or whatnot
<klys> impending*
<dh`> (also consider disabling the printing; it'll run a lot faster without that)
<mjg> fair
gog has quit [Ping timeout: 246 seconds]
<dh`> even with printing it will probably break things if there's a significant problem, though
<dh`> at least if you have enough threads and run it for long enough
<heat> mjg, i know that's the true 4.4bsd vfs way
<heat> but I would like to avoid that if possible
<dh`> but that surprises me, someone must have fixed up freebsd's code recently
<mjg> dh`: btw there is a number of compilation warns as is
<mjg> why recently
<dh`> because the last time I read the code it was wrong
<mjg> i'm pretty sure we talkeda bout dirconc 3 years ago if not earlier than that
<mjg> and at that time it was already passing at least for tmpfs and zfs
<dh`> but at this point it may have been 3-4 years ago
<mjg> i did not check ufs
<mjg> anyway
<mjg> dirconc.c:239:30: warning: format specifies type 'unsigned long' but the argument has type 'pthread_t' (aka 'struct pthread *') [-Wformat] say("join %zu (%lx)\n", i, threads[i]);
<mjg> and so on
<dh`> hmm
<heat> you can't print pthread_t I think
<mjg> you don't say :)
<heat> you're not guaranteed that it's a void *
<dh`> what's the ancestry of that version? the one I wrote generates forks, not threads
<heat> netbsd riadstradh
<heat> fuck
<heat> you get it
<heat> the dude with the weird name
<dh`> he must have done that
<mjg> it's literally what's in https://www.netbsd.org/~riastradh/tmp/dirconc.c right now
<mjg> i have to ask though, does netbsd ufs pass this?
<heat> :DD
<heat> goto arghmybrainhurts;
<mjg> ihateyou:
<dh`> yes
<dh`> despite all the genfs_insane_rename stuff
<dh`> that is just vfs fuckage
<mjg> i don't konw if you know dillon from (now) dfly
<mjg> he went the rename lock route after dirconc fucked up his tmpfs
<heat> it's best to give up
<bslsk05> ​github.com: os161/dirconc.c at master · benesch/os161 · GitHub
<dh`> (that's not my tree, I still need to get an official os161 onto github)
<dh`> it is not cool that riastradh's doesn't seem to have the license, though it might be my fault
<dh`> also nobody ever told me that it spread around that far!
<dh`> I don't think I've ever met dillon but I certainly know of him
nyah has quit [Ping timeout: 265 seconds]
<heat> im gonna fork freebsd and remove the stupid
<heat> i'll call it librebsd
<heat> then everyone will want to switch to it because i'm awesome, until i stop being able to maintain it and then python drops su-
carbonfiber has quit [Quit: Connection closed for inactivity]
<epony> there is no python in freebsd, there is focking ruby
<epony> python is the redhat poison pill
<heat> python is the devil's sauce
<heat> use perl like a good unix
<epony> and ruby is his sausage
<kof123> re: XXX comments that's where i saw them as well, i consider it like a side comment, not necessarily a clear FIXME but noting something is obscene maybe :D maybe something that is not a bug, but noting why it is that way its like budget NB to me, NB is reserved for classier things
<epony> XXX indicates three-swear-words-fix-this-if-you-can (todo / seriously problematic)
<heat> ok, think this through with me: dentries have a rw spinlock to protect themselves and to append children
<heat> I can't hold it through sleepable sections, like calls to the fs implementation
<heat> this is doable everywhere except rename where I need to be a bit more precise with what I'm doing
nick64 has quit [Quit: Connection closed for inactivity]
<heat> ok i fixed it kinda
<heat> I still don't think this is correct
<heat> I get a bad dirconc result
<klys> spinlocks are a way to have mutual exclusion, I'm afraid I'll get into a pile of semantics.
<dh`> XXX means "this is a problem"
<dh`> I thought this had gradually migrated out into general awareness by now
<klys> perhaps you could mention where code can be run from and which stack it's run from, so as to set aside sleepable behavior from other points.
<geist> i generally use it as 'make sure you look at this before committing it'
<geist> like a higher level than TODO
<klys> I have a mount(8) related question about chroot today
<bslsk05> ​paste.debian.net: debian Pastezone
<klys> somehow chroot with the bind mount knows to hide the socket (?)
theruran has joined #osdev
<heat> fuck it, im doing major changes to the dentry stuff
<heat> it's spaghetti af
<zid> testetti
<zid> well I didn't get a sendmsg failure
<zid> youtube's dead for me
<heat> youtube is worky
<zid> yea it worky now
<geist> also ugh i'm gettig slowly sicker and sicker as the day goes on
<geist> started off as a sore throat yesterday, now i feel like i got hit by a hilux truck
sympt has quit [Ping timeout: 265 seconds]
<heat> :/
<heat> covid?
<zid> I'm told covid feels more like some kind of european car
<geist> yeah that's why i said hilux. it's like getting hit by a light, but largely indestructable truck
<klange> But the Hilux is a mid-size...
<geist> well used to not always be right?
<Mutabah> Light compared to a B-double :)
* geist is thinking of the Top Gear episode where they keep trying to destroy the hilux
<heat> the hilux is a terrorist classic because of that
<heat> middle eastern insurgent starter pack
<zid> The hilux was mounted in the studio like a grotesque warning to other cars henceforce
<heat> mjg, how many dentry cache hash table entries do u have?
<heat> "Dentry cache hash table entries: 1048576" this sounds a bit too fucking much
<heat> for freebsd I mean
<mjg> ? :]
<heat> dentry hash table yes?
<heat> how many entry
<heat> thank
<heat> is dynamic? or static?
<mjg> how few million a problem no understanding
<zid> That is a lot of disgusting entry
<heat> monke want goood size
<mjg> i get 3 mln and the system does not give 2 fucks
<zid> how do you have that many derps
<heat> communist lunix doing dynamic entri
<zid> I'm not sure I have that many total
<mjg> thank clang
<mjg> you create a dir, unpack the system in there, git clone the tree
<mjg> and then run a full build for all architectures
<heat> no
<heat> is not what i mean
<heat> i mean chains
<mjg> and observe how clang, make and other fuckers create fuckton of neg ents
<heat> im talking about chainzz
<mjg> heat: it's dynamic
<heat> aw
<heat> you mofos
<mjg> lolo tuned at boot time
<mjg> there is no code to *auto* resize though
<heat> yeah that's normal
<heat> linux does it like that too
<mjg> trick q
<mjg> how many chainz obsd
<heat> 0
<heat> no hash table
<mjg> you get a wooden giant lock
<geist> haha i just watched half of the hilux episode
<geist> they actually drove it onto the set at the end
<zid> yea, it's mounted at a rakish angle
<zid> from then on
<zid> you see it in every ep
<mjg> heat: nchashtbl = nchinittbl(desiredvnodes * 2, &nchash);
<heat> oh fuck
<mjg> heat: not claiming this is any good tho
<heat> thats netbsd naming
<mjg> no, that' bsd naming
<heat> lets decode that together
<heat> n =
<heat> i lost
<zid> number of chins it tables
<zid> easy
<mjg> n stands for no
<heat> no means no
<mjg> yes
<zid> remember to ask for consent
<zid> before you insert into her hash table
<heat> number chain init table?
<heat> seriously wtf
<mjg> name cache hash init table
<heat> why are all your names layed out like letter soup
<heat> i thought freebsd was a bit better in this regard but jesus
<mjg> it is in newer code
<mjg> besides a shitty name give you an opportunity to write a comment
[itchyjunk] has joined #osdev
<mjg> increased comment:code ratio == good
<mjg> or so i'm told
<dh`> it's because of the great vowel famine of 1982
<heat> return EIO; /* XXX Panic? What? */
<mjg> :))
<mjg> the way i see it they ate some letters, but patching that in ed was so inconvenient
<mjg> they stayed
<mjg> 's how unix history is made
<dh`> yeah, that's the real reason
<dh`> things looked a lot different when vi was advanced technology
<dh`> my dad never did get the hang of writing clear code
<mjg> i know and old geezer who started with vi and does not even want to switch to vim
Brnocrist has quit [Ping timeout: 260 seconds]
<mjg> to his own detriment
<heat> what's vim?
<heat> I only use nano
<dh`> but he started in the early 60s if not earlier, don't remember precisely
<mjg> graduated from mcedit?
<geist> oh reminds me. neovim: discuss
<mjg> geist if you think you are baiting me, you don't :>
<mjg> it is i mildlly considered checking out, but i may be a lost cause now
<geist> no i mean, someone is bound to have tried it or used it, i'm geniuely curious what their experience was
<mjg> i know my vim is bad but i can't be fucked to learn anything else
<dh`> also, vertical space was still expensive until sometime in the late 90s
<mjg> geist: not a serious comment
Brnocrist has joined #osdev
<heat> oh shit hold on
<heat> this is going to be hilarious
<bslsk05> ​wiki.freebsd.org: IdeasPage - FreeBSD Wiki
<heat> >Solaris Doors IPC Implementation
<heat> mjg, you mentoring or what?
<mjg> dude that page is not even outdated
<mjg> i mean yes
<mjg> lol wut deasPage (last edited 2022-10-04
<mjg> i have not seen this page brought up in years
<mjg> how did you land there anyway
<heat> i was looking for fun ideas
<heat> i got a hilarious idea instead
<mjg> add off cpu tracking to obsd
<heat> are linux kernel conferences fun?
<mjg> for whom
<heat> i have netdev happening like 30 minutes away from home and im thinking about going
<heat> even though its netdev
<heat> idk, nerds
freakazoid332 has quit [Ping timeout: 268 seconds]
<mjg> i don't know about netdev
<mjg> normally most talks are crap
<mjg> but "hallway track" is where it's at
<mjg> you reminded me of a funny problem
<mjg> there was a reasonbly respected security conference in poland, annually
<mjg> there were some management changes and tech panel got wiped
<mjg> then they accepted a talk from 2 college students who just learned about exploiting stack buffer overflows
<mjg> nothing about bypassing any mitigations, just the concept
<mjg> dudez were turbo excited to talk about it
<mjg> bless their hearts
<heat> hahaha
<heat> there were like 2 conferences here in the past 3 years and i missed them both
<mjg> good for you
<heat> "whose dick can I suck for a kernel.org account"
<mjg> look man normally conferences are just an oportunity to meet irl with people you only interact with over the interwebz
<mjg> talks, if of sensible quality, are a just a commercial for laymen
<heat> lol
<mjg> real shit is in the paper
rurtty has quit [Quit: Leaving]
<mjg> also see my past remarks on claiming whatever is presented in the paper kicks ass
<heat> kinda related, why did freebsd never get uvm?
<heat> is uvm not as kick ass as the paper?
<mjg> i don't know the history on that front
<mjg> given general idea/code quality of the era, consider everything available below quality line
<mjg> the uvm paper goes to some detail to explain how shit mach vm integration was
<mjg> but what matters most is what they are not telling you
<heat> is this a conspiracy theory or what
<mjg> what
rorx has joined #osdev
<mjg> no, that's the general remark on the papers lying about realities of what they did
<geist> we must stand up to the netbsd foundation
<geist> for they will soon control everything
<mjg> everything is best ever
<mjg> you made some questionable tradeoffs? make sure to not mention them, intsead show the win
<mjg> etc.
<geist> yeah i mean the uvm thing was probably nice for what they had at the time. doesn't alwaysm ean it's the best ever
<heat> the vm object chain thing is a super solveable problem
<heat> but no one ever solved it?
<heat> which hints that either 1) mach vm is hard to work with 2) freebsd stupid
<heat> i'm going to assume its 1
<mjg> the keyboard on you
<mjg> mach vm is total crap but it got beaten into shape enough to not be an immediate problem for joe random
<dh`> freebsd got its own new vm system before uvm happened
<mjg> ye the paper talks about it
<dh`> so freebsd and netbsd have just diverged on vm
<heat> why is it new if its still mach?
<mjg> the critcism expressed in the paper was that the choice was made to beat mach with a hammer
<mjg> instead of whacking it, like netbsd did
<heat> ah
<dh`> it got major updates of some kind, I don't know the details
<mjg> i have no idea what the fbsd devs at the time were thinking
<dh`> whether it was "new" or just rehacked is probably not important
<dh`> unless freebsd still has machvm's infinitely long shadow page chains, that would be a significant failure
<mjg> it has obj chains, but also has machinery to collapse them
<mjg> i don't know how bad they can get in practice
<dh`> you never need more than one shadow page
<mjg> bigger problem is how pmap works
<dh`> anything else is a result of machvm being research and nobody knew how to do it properly yet
<mjg> which is basically anti-performance at this point
<mjg> when i have more time i'll consider taking a look at what's actually needed for pmap to work
<dh`> (and I have no idea why you would need or want whole shadow objects)
<mjg> the current stuff is so bad it's not funny
<dh`> the pmap interface is way too high level
<geist> how so?
<mjg> who are you asking
<mjg> :>
<geist> dh`:
<dh`> even if you don't grant that the pagetables themselves can be mostly MI code like linux does
<dh`> there is no reason the coremap code shouldn't be MI
<dh`> and yet it's pasted into every pmap in slightly different form
<heat> what's coremap?
<dh`> reverse mapping from paddrs to vaddrs
<heat> oh
<geist> ah
<heat> yeah that's mi
<heat> well, should be
<dh`> when machvm happened nobody knew for sure so they were very general to be safe
<dh`> also I strongly suspect someone didn't really understand hardware-level "inverted page tables" and thought maybe they could serve as the reverse mapping
<geist> probably reason it's still in the pmap layer is the pmap knows when it can recycle mappings
<heat> i think that exposing page tables, although kinda new, is a weird move
<dh`> but I have no evidence for that, it's a conjecture
<geist> and the pmap code may decide to wipe out mappings for Reasons, so it knows how to update the coremap
<heat> at some point you have to ask yourself if $thing_you_are_doing applies to every architecture or just the ones you're working with
<geist> OTOH the coremap maintenance code can at least be implemented outside of pmap
<dh`> dropping mappings from the pagetables is one thing; dropping them from the system is another, and that should be MI
<geist> right. that's the point: does the coremap remember what *should* be mapped, or what actually is mapped
<geist> if it's the latter, the pmap code should keep it up to date. which makes sense to me
<geist> because that gives it flexibility to throw away mappings for whatever reason
<dh`> most of that logic should be MI or MI hooks for the MD code to call
<heat> the latter is maybe not the best idea
<geist> what should be mapped is a higher level thing: this object mapped to that spot in that vm
* geist nods
<dh`> that's the forward mapping
<dh`> or are you proposing an object-level reverse mapping? not sure there's any actual use for that
<geist> oh i dunno. we're probably talking about different things
<geist> i dont know what 'coremap' is precisely
<geist> but i generally think of 'pmap' as the layer that abstracts the mmu per arch
<geist> ie, map/unmap/protect/createaspace/destroyaspace
<dh`> right, my claim is that it has lots of stuff in it that should be MI
<geist> okay.
<dh`> map/unmap of objects is entirely MI
<geist> ah sure
<dh`> all that needs to be MD is entering specific pages into the pagetables, or removing them
<geist> right
<heat> is object-level reverse mapping not the important bit?
<heat> it's what linux does at least
<heat> and fuchsia, and me
<dh`> all the important stuff that works on the reverse mapping (e.g. LRU chains, eviction) is MI
<dh`> what you need from the reverse mapping is: given a page, what address spaces on what CPUs have or might have it mapped (and at what address)
<dh`> there are various ways to represent that, no one choice is obviously canonical
<heat> AIUI you usually get the offset inside the vm object and then all the mappings of it
<heat> (and go through the ones that have that offset mapped)
<dh`> but it is MI information unless you want to closely track what happens with mappings that get flushed from the hw because of capacity limits
<heat> on archs without page tables?
<dh`> you can store a list of address spaces and virtual addresses (this is what most of the BSD pmaps I remember do) or you can point directly to some kind of virtual page structure that has more info, or you can point to the memory object and offset, or various other combinations
<dh`> there are tradeoffs, but as I was saying none of the choices are obviously canonical and it intersects with choices about the locking model too
<dh`> yeah, on software-refill arches
<dh`> but mostly trying to track that state is too much overhead
<heat> obligatory praise ITANIUM
<dh`> refill traps happen a lot and you tend to care about single extra instructions, never mind large updates of complex structures or locking
<dh`> and on hardware-refill arches there's basically no reason to drop mappings from the MD code, or at least not any I can think of
<dh`> at least if all the concerns that should be MI are in the MI code...
<dh`> anyway basically the core problem with VM systems is that the virtual <-> physical mapping is bidirectional and needs to be transited in both directions, so you need some locking scheme (that isn't a biglock) that allows going both ways without deadlocking
<dh`> and usually the other choices are subordinated to whatever scheme you come up with for that
<dh`> heheh
<heat> dh`, unrelated but do you happen to know if its possible to set up a netbsd install in a wireless ssh way?
<heat> i have a rpi i'd like to maybe daily drive it on and I don't have serial for it
<epony> hahaha
<epony> "diskless" + "wireless" + "remote serial over lan" + "autoinstall".. nonono, let's start again.. "wireless" + "a boot loader"... nonono, "boot somehow", anything..
<heat> never mentioned autoinstall
<heat> nor "remote serial over lan", whatever that means
<dh`> as in, install over a wireless network? should be but idk
<heat> i just want a way to set up wireless + sshd in the installation image such that this is possible
<heat> manjaro (sigh) did support it
<dh`> oh, sshd for running the installer over ssh? no idea. good question
<dh`> my guess is that you will need to tinker with the installer image by hand though
<heat> yeah that's totally fine
<heat> i just don't see instructions for it anywhere
<dh`> give it a network config that matches what you want to do, start sshd explicitly
<dh`> the installer image probably doesn't have sshd though
<dh`> rather than fiddling with that it might be easier to start with a live image and then run the installer manually
<dh`> you're supposed to be able to do that nowawdays
k8yun has joined #osdev
<heat> ooooh
<heat> i'll take a closer look then, thanks!
<dh`> -r-xr-xr-x 1 root wheel 454440 Jun 2 22:45 /usr/sbin/sysinst
<dh`> it is there
<dh`> you might need some options to make it behave like an install image, not sure
<dh`> the biggest problem will be that you boot it and it doesn't respond and you have no way to figure out what's happening... so probably you want a r/w live image with syslogd enabled and some stuff like that
<dh`> so when it doesn't work you can move it back to another machine and examine what happened
<dh`> realistically, setting up the console is probably less work
<heat> i need to learn how to solder :P
<kaichiuchi> hi
<heat> hello
<kaichiuchi> question, and I understand how general it is
<kaichiuchi> how difficult is targeting a raspberry pi
<kaichiuchi> I *figure* a raspberry pi might be good because everything is integrated and "small"
<klange> Hardware is wonky and special, but also rather well documented [by third parties / REers] for what it is...
<kaichiuchi> is there any other board that might be better for this?
<klange> Depends on your goal.
<heat> all in all, standard pc is probably the easiest
<kaichiuchi> that's slightly surprising
<kaichiuchi> by standard PC, do you mean modern standard PCs or BIOS/x86 era?
<heat> very well documented and well tested path
<heat> whatever
<heat> they're all super compatible
<heat> a modern standard PC will at a glance look super similar to a later-90s PC to the kernel
<heat> x86 is quirky but you can also get *a lot* more help
<heat> hardware and hardware interfaces will be relatively standardized
<heat> booting too
<kaichiuchi> it does seem that way, looking at the intel manuals
darkstardevx has joined #osdev
JerOfPanic has quit [Remote host closed the connection]
<bslsk05> ​'LPC 2022 - Kernel Summit - Lansdowne' by Linux Plumbers Conference (07:42:17)
<heat> that talk is fairly interesting
<heat> "The Maple Tree: Condensing 40 Liters of Data into 1 [tree data structure replacing augmented rbtree + doubly linked list + vmacache] "
<bslsk05> ​docs.freebsd.org: Design elements of the FreeBSD VM system | FreeBSD Documentation Portal
<mjg> > Under Linux there is no such linked list. In order to remove all the hardware page table mappings for a vm_page linux must index into every VM object that might have mapped the page. For example, if you have 50 processes all mapping the same shared library and want to get rid of page X in that library, you need to index into the page table for each of those 50 processes even if only 10 of them have actually
<mjg> mapped the page. So Linux is trading off the simplicity of its design against performance.
<heat> huh?
<heat> linux maintains a whole bunch of super fine tuned structures to reverse map a page to regions in address spaces
<mjg> 1. that's old
radens has quit [Quit: Connection closed for inactivity]
<mjg> 2. the claim was probably never true ref perf
<heat> "author: Matthew Dillon"
<heat> yeah it may be a bit old :P
k8yun has quit [Quit: Leaving]
<bslsk05> ​lwn.net: [PATCH v2 00/70] RFC mm: Introducing the Maple Tree [LWN.net]
<mjg> signal1-processes gets a win
xenos1984 has quit [Read error: Connection reset by peer]
<mjg> like bro
<mjg> lol
\Test_User is now known as \\\\Test_User
\\\\Test_User is now known as \Test_User
<mjg> meanwhile several cases of what is actually affected in terms of code get a slowdown
<Griwes> lol that test file
frkzoid has joined #osdev
PapaFrog has quit [Read error: Connection reset by peer]
<heat> "I'd still like some help with figuring out how to make building kernels faster"
PapaFrog has joined #osdev
<Griwes> building kernels faster? easy, add some rust
* Griwes clown walks away
<mjg> at least guy mostly concedes trhere is a single-threaded slowdown
<mjg> Hmean malloc1-processes-2 513481.82 ( 0.00%) 447458.20 * -12.86%*
<mjg> glorious
<mjg> to be fair
<mjg> Hmean malloc1-threads-2 14119.77 ( 0.00%) 179149.22 *1168.78%*
<heat> suck it
<heat> dont be mean to apple tree man
<mjg> apologies
<heat> what's freebsd using for vm regions again?
xenos1984 has joined #osdev
wxwisiasdf has joined #osdev
<wxwisiasdf> hi
heat has quit [Ping timeout: 268 seconds]
k8yun has joined #osdev
* geist reads about WAVL trees
<geist> looks like on first glance they have similar characteristics to RB trees
frkzoid has quit [Read error: Connection reset by peer]
<geist> hmm, okay. the wikipedia article i think sums it up.
<geist> now i see why folks say it has constant time insertions and deletions (after a log n search)
<geist> it has a constant number of rotates when balancing the tree, which is the trick i think
frkzoid has joined #osdev
vdamewood has joined #osdev
[itchyjunk] has quit [Remote host closed the connection]
bgs has joined #osdev
lg has quit [Remote host closed the connection]
k8yun has quit [Quit: Leaving]
Iris_Persephone_ has quit [Ping timeout: 260 seconds]
<mrvn> geist: but that's still O(log n) then. just a better constant.
<sham1> WAVL trees? Do they use PCM samples?
<sham1> Also, isn't RB also constant time insertion and deletion after log n search?
<mrvn> "On the other hand, red–black trees have the advantage over AVL trees in lesser restructuring of their trees. In AVL trees, each deletion may require a logarithmic number of tree rotation operations, while red–black trees have simpler deletion operations that use only a constant number of tree rotations. WAVL trees, like red–black trees, use only a constant number of tree rotations, and the constant is
<mrvn> even better than for red–black trees." Yes, but more of them.
<sham1> Hmrm
<mrvn> geist: When you insert you search for the key until you hit a leaf node. Then you insert the value there and then rebalance. Doesn't that have to retract the path back to the root to find the nodes to rotate? It might need only a constant number of rotations but you still have to test each node in the path if it is one of those. I would call that O(log n)
<mrvn> time
<mrvn> "Thus, overall, the insertion procedure consists of a search, the creation of a constant number of new nodes, a logarithmic number of rank changes, and a constant number of tree rotations." You even modify o(log n) nodes, just don't rotate.
<sham1> Well as said, it did say O(1) after the O(log n) search. So yeah, O(log n) in the worst case
<mrvn> sham1: except if it takes O(log n) rank changes then that's not O(1).
<sham1> Right
bauen1 has quit [Ping timeout: 268 seconds]
<mrvn> Still an interesting tree. Less height than RB and you can use RW spinlocks and only need a write lock for rotations while using xcmpchg for other changes.
<mrvn> from 2015, no wonder I never heard of them before. :)
<mrvn> "Adding or deleting the node itself is constant time, the amount of rotations is always at most constant and it can be shown that the total amount of rank changes in the nodes is linear in the number of both insertions and deletions." Still O(log n) time but yet more shaving down the constant overhead :)
<sham1> Speaking of, what I don't always understand is why things like memory allocators don't use more balanced search trees. I'd say that it would probably be better than a free list, for example
<mrvn> sham1: using what as the key?
<sham1> Size, for example
<mrvn> Then how do you merge adjacent free chunks?
<sham1> How do you merge adjacent free chunks with a free list? After all, you'd have to linearly probe the free list to insert your new entry next to the adjacent spot
<mrvn> Every chunk has a header with prev/next, a flag if it's free and a canary. So you just check prev->flag and next->flag.
<sham1> Even if a sorted list, you still need to do O(n) insertion to keep the sorting
<mrvn> Keeping chunk in a list sorted by location makes everything O(1) except finding a chunk of proper size.
<sham1> Hm
<mrvn> malloc becomes O(n)
<moon-child> sham1: I considered tree-based malloc recently
<mrvn> sham1: you can use more than one data structure. E.g. keep all the chunks linked in a list sorted by location. But also insert them into a tree sorted by size.
<sham1> Although I could see the usage of both a free list and a tree for best fit would be interesting, although I suppose there would be complexity
<sham1> Yeah
<moon-child> though I think I am talking about something different from what y'all are talking about, as my imagined malloc was constant-time, same as a freelist
<mrvn> sham1: as in every node in the tree has a prev_addr and next_addr link.
<sham1> (Complexity not as in computational class but having to track it all)
<moon-child> (well, ok, amortised constant-time; there's a periodic O(logn) thingy)
<clever> moon-child: random idea, what if the free list, was a linked list in order of size,and all allocations always eat from the biggest hole?
<clever> you would need to maintain 2 linked lists at once, sorted by size, and sorted by addr, so prev/next merging upon free works
<moon-child> but then you have to sort the first list
<clever> hmmm, but re-inserting a free into that sorted list, yeah that would be expensive...
<clever> yeah
<mrvn> clever: insertion/lookup in a size sorted list is O(n)
<sham1> O(n) sorted insert
<clever> mrvn: the lookup would be constant time, if you just always pick the first entry in the pre-sorted list, which is the largest hole
<clever> but yeah, insertion then becomes a cost, to maintain that sorting
<mrvn> oh, no. that would be horrible in terms of fragmentation.
<clever> yeah, it would always grab the biggest hole, and carve it up into data+hole
<moon-child> would it? If you allocate a bunch of small objects, they'll all go right next to each other
<clever> until that object is the 2nd biggest
<moon-child> mmm yeaha
<clever> and then it ping/pongs between the top 2 biggest holes
<moon-child> well, depends on how long your tail is
<clever> repeat until the top 3 are now tied
<mrvn> moon-child: last = malloc(16); while(true) { next = malloc(16); free(last); last = next; }
<moon-child> you could ping/pong/pound between n different holes and then the fragmentation would get really bad
<mrvn> moon-child: that would use infinite amount of ram because it never reuses any.
<mrvn> (well up to half the size of the address space)
<moon-child> presumably you'd have some max node size
<moon-child> but yeah
<clever> i'm more fuzzy on the in-memory state, but zfs primarily uses just a log of every free/alloc for the on-disk state
<mrvn> For userspace malloc that would work as you only allocate a small amount to start. So the largest hole quickly becomes small.
<clever> it doesnt immediately deal with fusing consecutive free spaces together
<clever> so the on-disk state is cheap to append to, no need to serialize the entire thing and re-write it
<clever> but at load time, it has to parse the entire log, and re-create the size based trees/buckets in ram
<mrvn> clever: doesn't it have space grouped into clusters, each cluster can be data, metadata or mixed and it doesn't reuse a cluster until it's fully free?
<clever> mrvn: each metaslab has its own log of free/alloc
<clever> and it only keeps a few metaslabs loaded at a time
<clever> blocks within a metaslab are all some multiples of 2^ashift, such as 4kb
<clever> and within that 4kb, you can only have 1 type of data
<clever> [root@amd-nixos:~]# zdb -ul amd | grep shift
<clever> metaslab_shift: 24
<clever> ashift: 13
<clever> this says that each allocation block is 8kb, and each metaslab is i believe 16mb??
<clever> that feels a bit small
<mrvn> sham1: anyway, back to malloc. Most modern malloc have a bunch of buckets for small sized objects. 16, 32, 48, 64,... byte and small stuff you allocate from there. Can be a free list or bitmap based. You can even avoid overhead for allocated chunks (no header) if you detect the size of an obvject by the address range it is in.
<sham1> Right
<moon-child> address space trick is nice
<moon-child> can make one whole chunk of address space for all small objects, then carve it up into blocks some constant power of two (eg 64kb); then look at the base of the 64kb chunk for the 'next' ptr
<mrvn> Userspace stuff tend to have to do a tree search to find the address range of an allocation. In kernel you can encode the size in the upper bits of the address or something sneaky.
<moon-child> I just gave a way to avoid tree search :P
<moon-child> (tho you can argue if you tlb miss page tables are a tree :P)
<mrvn> moon-child: you assume you can allocate memory from the kerenl to an address of your choosing there, e.g. mmap()
<moon-child> not necessarily
<moon-child> I just need separate reserve and commit
<geist> yah: re wavl
<geist> constant rotates, o(log n) updates of rank
<bslsk05> ​github.com: lk/cmpctmalloc.c at master · littlekernel/lk · GitHub
<moon-child> say I reserve a giant 2tb region. I don't care where the kernel puts it, as long as it's all contiguous, and I can commit aligned contiguous 64k chunks within it
<mrvn> geist: amortized O(1) updates of rank
<clever> ah, found it, an example of multiple bucket based free lists
<moon-child> j allocator works that way too
<geist> yah the cmpctmalloc is a N bucket list, with coalescing
<moon-child> 'mutex_acquire(&theheap.lock)' this makes the thread god sad
<clever> free_list_bits is a bitmap, of which lists have at least one block
<mrvn> moon-child: yeah, that's what I call you choosing the address to use.
<clever> so you can skip parsing the empty lists, and go to buckets that have something
<moon-child> mrvn: I don't think you can allocate at arbitrary addresses on windows; but you can do separate reserve/commit there
<moon-child> yeah it locks on every alloc :\
<mrvn> moon-child: and reserve doesn't actually allocate physical memory, only commit does. :)
<moon-child> mrvn: sure, but I don't get to pick an arbitrary address
<geist> moon-child: it's primarily used in embedded situations. i dont think that's a large issue
<geist> most embedded situations you should avoid malloc in general anyway
<moon-child> I have to use one of the addresses that the kernel gives me
<mrvn> One thing I find most important is that you should have per-core buckets. You want to avoid having to lock on every alloc/free
<moon-child> yep
<moon-child> this pleases the thread god
<geist> per core buckets would be much much more difficult to merge and coalesce
<geist> would be extremely wasteful memory wise
<moon-child> do message passing
<geist> oh?
<mrvn> depends on how much ram you want to keep pre-allocated per core
<geist> yah but when you free a block what core's list do you put it on?
<clever> geist: and how would userland deal with per-core buckets, when a thread might change core mid-allocation?
<moon-child> its home core
<moon-child> also you have to batch em
<geist> and then if the next adjacent block is on another core's free list, do you reach across and pull it there?
<mrvn> carve up the address space into nun-cores chunks and lets each per-core structure handle one such chunk.
<clever> can userland even reliably know what core its on, on most arches?
<moon-child> to amortise the overhead
<clever> or would you instead do per-thread buckets?
<mrvn> clever: we write the OS, we decide that. :)
<geist> so now all thes eoperations have to be done while pinned on a cpu?
<moon-child> you have some outgoing queues and some incoming queues. Periodically you flush the outgoing queues, and periodically you flush the incoming ones
<moon-child> err home thread. Not core
<geist> while ig et what you're saying it means the code is an order of magnitude more complicated
<geist> home thread?!
<mrvn> clever: but yes, in user space you would do that per thread.
wxwisiasdf has quit [Ping timeout: 265 seconds]
<moon-child> yes, every object has a home thread. This is how mimalloc works (afaik), how snmalloc works, how the j alloc works
<mrvn> geist: oh totally. doing this with per-core or pre-thread pools is much more complex. But worth it.
<geist> how would that work in a kernel?
<moon-child> for kernel you'd probably do per-core
<geist> per thread doesn't make sense, because threads come and go at a ridiculous rate
<clever> mrvn: and i would probably limit how much can be "free" in each thread, and push free blocks back into a global pool, so when another thread runs out, it can pull from that, rather then the os
<mrvn> clever: you can also use a work-stealing queue so if one thread runs out it grabs half the memory of another thread.
<geist> i mean i dont disagree with what folks are saying here, but i am pointing out that what you're saying is faaaaar more complicated
<geist> and that doesn't necessarily mean yo unet wins at small scale
<geist> ie, building things that scale up may have much larger constants in the O(C) stuff
<geist> so it's always a tradeoff
<mrvn> geist: in kernel, assuming alloc/free isn't preemptible you can do per-core data quite easily.
<moon-child> the complexity only applies when you're doing multicore stuff
<geist> sure. i know this stuff mrvn
<moon-child> when you're all single threaded, you'd never hit those code paths
<mrvn> doing it for threads in user space is muczh harder because they are preemptible.
* geist senses that things are being talked past so goes to bed
<moon-child> mrvn: what's the difficulty with preemption?
\Test_User has quit [Quit: e]
<mrvn> moon-child: you can't steal another threads unused memory when one thread runs out because it might be in the middle of a malloc.
<moon-child> oh per-core vs per-thread? Yah for user-space you just do per-thread data and know that you won't get shuttled across cores too much
<moon-child> high perf is all one thread per core anyway, so no big deal
geist has left #osdev [#osdev]
<mrvn> moon-child: I mean you can but it's more complex if you have to handle threads that might not be running.
<moon-child> why do you care if a thread is not running?
<mrvn> moon-child: In kernel I can just take a lock and 99.99% of the time this will remain on the owning core. Once in a blue moon another core takes the lock to steal some memory.
<moon-child> oh lock, sure. Hence lockfree shit :)
gxt has quit [Ping timeout: 258 seconds]
<mrvn> which gets you into the problem of needing something like RCU.
gxt has joined #osdev
<mrvn> Without preemption you have a nice upper limit on how long other cores remain in the structure. So you can just free objects after some time (e.g. on the next call of the function). With threads you never know how long other threads might be holding a reference.
sebonirc has quit [Remote host closed the connection]
sebonirc has joined #osdev
xenos1984 has quit [Read error: Connection reset by peer]
m5zs7k has quit [Ping timeout: 252 seconds]
m5zs7k has joined #osdev
xenos1984 has joined #osdev
lg has joined #osdev
bauen1 has joined #osdev
Matt|home has joined #osdev
vdamewood has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
vdamewood has joined #osdev
\Test_User has joined #osdev
GeDaMo has joined #osdev
nyah has joined #osdev
zaquest has joined #osdev
frkzoid has quit [Ping timeout: 264 seconds]
potash has quit [Excess Flood]
potash has joined #osdev
Coldberg has quit [Read error: Connection reset by peer]
Coldberg has joined #osdev
zaquest has quit [Remote host closed the connection]
zaquest has joined #osdev
rurtty has joined #osdev
SGautam has joined #osdev
gildasio has quit [Ping timeout: 258 seconds]
gildasio has joined #osdev
elastic_dog has quit [Read error: Connection reset by peer]
elastic_dog has joined #osdev
fisu has joined #osdev
<fisu> Hi, quick question, does anyone have a clue what the error
<fisu> "unsupported graphical mode type 765043" means?
<fisu> multiboot flags that have been set are bit 1, 2 and 3
<fisu> which should cause grub to give me a buffer at 0x1024+16 (I'm skipping 1MiB) from 0
<fisu> (sorry, bit 0, 1 and 2), it seems that it's the video mode that is causing the issue
<zid> sounds like you tried to ask it for mode 765043 to me
Matt|home has quit [Quit: Leaving]
<zid> 32u32mode_typeif flags[2] is set
<zid> 36u32widthif flags[2] is set
<zid> 40u32heightif flags[2] is set
<zid> 44u32depthif flags[2] is set
<zid> you set flags 2 so you need to fill those fields out with something sensible
<fisu> ah, yeah alright, that's probably it then
<bslsk05> ​www.gnu.org: Multiboot Specification version 0.6.96
<zid> there
<zid> 3.1.1
<fisu> ah
<fisu> yeah thanks
<zid> It's the 4th result on ctrl-f for `mode`
<fisu> yeah, found it by searching for flags[2]
<fisu> for mode type I assume linear graphics mode means I'd have to actually draw letters? and text mode it probably works out of the box?
<zid> linear means the addresses are all in order
<zid> rather than planar
<zid> where you might have RRRRRRR GGGGGG BBBBB
<zid> or various rectangles
<zid> but yes, text modes are different to graphical modes
<zid> text modes are usually an 80x25 array of 2 byte entries, colour/attribute and character pairs
<zid> graphical modes are arrays of pixels
<zid> size depending on depth
<zid> the 'linear' part was a nice improvement over old cards, that used to have to bank-switch more memory into a hole at A0000 or B8000
<zid> to support larger resolutions than 320x240
<fisu> makes sense, so essentially when I get the basics working I should start making a switch to linear mode
<mrvn> Planar graphics are such fun. Damn you chunky pixels.
<fisu> yeah, just gotta figure out why exactly printing to 0xb8000 doesn't work :s
<mrvn> fisu: that's just x86 idodacy.
Matt|home has joined #osdev
<fisu> mrvn: hmm, what do you mean?
<Mutabah> Define "doesn't work"?
<mrvn> other archs don't have a framebuffer at some predefined address
<fisu> i.e. nothing is printed out
<Mutabah> qemu? do you have `cli;hlt` not long after?
<mrvn> Mutabah: it's in a graphics mode with the data at 0xa0000
<zid> those two things you said don't add up btw
<zid> linear modes are graphical
<Mutabah> Ah, didn't see that above?
<zid> (the opposite of planar modes)
<zid> simple is text modes
<Mutabah> fisu: if you're using multiboot, just write to the framebuffer pointer provided in the boot information
<zid> I just wrote a bochs display adapter driver cus it was easiest, and used text-mode during early init so that I could print things
<zid> because I was too lazy to set up a way to watch the serial port in realtime on the host, more or less
<fisu> Mutabah: yeah, qemu and I'm using multiboot, thanks I'll look into the framebuffer
<fisu> though I keep breaking my entire kernel by fiddling with stuff
<zid> good good
<zid> got a githoob?
<fisu> yeah
<fisu> wait I'll make it public
<fisu> the WIP branch has more to it, https://github.com/vikke1234/imperatrix
<bslsk05> ​vikke1234/imperatrix - Hobby operating system (0 forks/0 stargazers)
<zid> your stack is upside down
<GeDaMo> Maybe they're Australian :P
<zid> well maybe, but his cpu would need to be australian too
<zid> #ifndef __i386__
<zid> #error "Not building x86"
<zid> is that not inside out?
<zid> stdio.c:5 you've made 'out' a global for some reason
<zid> k I ran out of code to look at
dude12312414 has joined #osdev
<fisu> yeah, it's no longer global
<fisu> but thanks, looked at the barebones tutorial for the stack direction, I'll fix it
<fisu> started the project roughly last week but I've not had much time to work on it this week
gxt has quit [Ping timeout: 258 seconds]
gxt has joined #osdev
<bslsk05> ​www.google.com: india cable street - Google Search
freakazoid332 has joined #osdev
<fisu> ddevault: congrats
epony has quit [Read error: Connection reset by peer]
wxwisiasdf has joined #osdev
<wxwisiasdf> good morning kerneldev irc cha o7
heat has joined #osdev
<heat> what the fuck is up
<wxwisiasdf> yes
<bslsk05> ​news.ycombinator.com: Intel Laptop Users Should Avoid Linux 5.19.12 to Avoid Damaging the Display | Hacker News
<wxwisiasdf> our COBOL kenel grows in lins of counts
<heat> nah, no damage
<heat> they fixed it already but it was just a bug
<heat> with link training or something like that
<GeDaMo> wxwisiasdf: you're writing a kernel in COBOL?
<wxwisiasdf> i am
<GeDaMo> Neat :)
<heat> well, "fixed" they reverted it and cut out a new release
<wxwisiasdf> i's like python
<wxwisiasdf> but in the 60's, and made by peope in suits
<GeDaMo> I remember seeing that COBOL had acquired pointers at some point and wondered if someone would :P
<wxwisiasdf> they're surprisingly useless
<wxwisiasdf> the transpiler for COBOL uses dynamic linking to point at things and you can't establish fixed addresses for some reason
<wxwisiasdf> compiler*
<heat> is cobol 60s racist?
<wxwisiasdf> that sounds like a headline fox news would make
<heat> no
<wxwisiasdf> cnn?
<heat> fox news would defend that it's not and even it if were, is being 60s racist bad?
<wxwisiasdf> lol
<wxwisiasdf> COBOL is rad tho, also GeDaMo I had to port over the entire COBOL runtime which required me to put GMP on baremetal
<wxwisiasdf> i mean it's not a lot of work to put it on freestanding but it wasn't that smooth either :p
<heat> gmp lmao
<GeDaMo> Is this GNU COBOL or something else?
epony has joined #osdev
<wxwisiasdf> GNU COBOL
<heat> GNU/COBOL
<wxwisiasdf> because I don't have 10 million british quid pounds to pay for an enterprise COBOL compiler
<GeDaMo> I think Microfocus is the only name in COBOL now, right? :P
<heat> compiler for a language made by people in suits written by dirty communists
<wxwisiasdf> yes but microfocus bad
<heat> ironic
<wxwisiasdf> what, i am not a communist
<zid> I am
<heat> you're not a part of GNU
<GeDaMo> Huh, looks like Micro Focus has been bought
<wxwisiasdf> wait what
<zid> microfocus is the diagnostis my doctor gave
<GeDaMo> "In August 2022, Canadian software firm OpenText announced that it would acquire Micro Focus in a deal valued at US$6 billion, which is expected to close in early 2023." https://en.wikipedia.org/wiki/Micro_Focus
<bslsk05> ​en.wikipedia.org: Micro Focus - Wikipedia
<heat> something something micro penis something focus
<heat> there's a joke somewhere
<heat> please find it
<GeDaMo> And they own Unix :| "With the purchase of Attachmate, Micro Focus became the owner of the Unix operating system."
<zid> I can't it's too small
<zid> tilt it more toward the light heat
<wxwisiasdf> heat it up :D
<wxwisiasdf> i had to make that pun sowwy
<heat> GeDaMo, they could go bankrupt and even then we would not be able to see sysv's sauce
<wxwisiasdf> how to anger an osdever (10 easy tips), step 1: say somethin conroversial like "linux better than windows", step 2: watch the show unfold
<wxwisiasdf> also isn't sysv source code public domain?
<heat> last time i hinted a linux channel that windows isn't horrible they tore me a new one
<heat> absolutely fucking not lmao
<heat> i wish
<heat> i think they won't release it BSD licensed because of the possible legal issues
<wxwisiasdf> huh
<heat> although there's a leak, but it's a bad idea to look at it when writing budget unix :)
<wxwisiasdf> "writing budget unix"
<wxwisiasdf> what the hell is a budget unix
<zid> unix on a budget
<wxwisiasdf> examples ?
<heat> github.com/heatd/Onyx
<bslsk05> ​heatd/Onyx - UNIX-like operating system written in C and C++ (2 forks/53 stargazers/MIT)
<zid> github.com/torvalds/linux
<bslsk05> ​torvalds/linux - Linux kernel source tree (44912 forks/139077 stargazers/NOASSERTION)
<heat> this fucking bozo spends his time writing bad unix
<bslsk05> ​openbsd/src - Public git conversion mirror of OpenBSD's official CVS src repository. Pull requests not accepted - send diffs to the tech@ mailing list. (752 forks/2518 stargazers)
<heat> look at these fucking dudesss lmao
<heat> budget unix all the way down
<wxwisiasdf> :|
dude12312414 has quit [Remote host closed the connection]
alpha2023 has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
alpha2023 has joined #osdev
<fisu> dumb question, the multiboot boot information structure address should be in `ebx` after booting right? my issue now is that it doesn't look like the address is mapped?
Irvise_ has quit [Quit: Reconnecting]
Irvise_ has joined #osdev
<fisu> `__asm__("mov %%ebx, %0" : "=r"(boot_info));` results in `boot_info = 0x2f3630f0`
<heat> you need to get it in assembly
<heat> the compiler may trash ebx
<fisu> oh I see
<heat> your entry point needs to be assembly, if im not being clear
<fisu> yeah, it is, wait I'll get back to you in a moment
SGautam has quit [Quit: Connection closed for inactivity]
alpha2023 has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
<fisu> do you happen to know how multiboot works on riscv by the way?
<fisu> I don't really like x86, it's odd... though I imagine most of the material is for x86/x64 though
scoobydoo_ has joined #osdev
<heat> no idea
<heat> you usually don't use multiboot for riscv and arm
<wxwisiasdf> use u-boot
scoobydoo has quit [Ping timeout: 268 seconds]
<heat> but rather linux's boot protocol
scoobydoo_ is now known as scoobydoo
<heat> which is simple but can be a bit fucky sometimes
<fisu> oh I see
alpha2023 has joined #osdev
<fisu> heat: yeah it was corrupted by some odd function that the compiler inserted, just checked with gdb that `*($ebx + 96) = 0xb8000`
<fisu> I guess I'll pass it as a parameter to kmain then
<heat> yes
xenos1984 has quit [Ping timeout: 268 seconds]
xenos1984 has joined #osdev
<zid> someone in ##asm is listing cpus that "support assembly"
<zid> good news, the atari 2600 supports assembly
<heat> tbf old ass CPUs may not support assembly
<mjg> team atari o/
<zid> https://github.com/zid/bootstrap/blob/master/boot/boot.asm my boot.S is super complicated :(
<bslsk05> ​github.com: bootstrap/boot.asm at master · zid/bootstrap · GitHub
<mjg> i bet commodore still does not!
<heat> mjg, i'm up to 2.5M open3 and 2.8M open1 \o/
<mjg> that's ro?
<heat> as part of my "fuck the linked list and get a hashtable" thing
<heat> yes
<mjg> then fuckign name it openro3 and openro1
<mjg> motherfucker
<mjg> that aside, congrats
<mjg> what's the fg now
<wxwisiasdf> intrusive linked list :D
freakazoid332 has quit [Ping timeout: 248 seconds]
<mjg> what's your hashing func
<mjg> fnv will do fine for the time being, but it does come with a tradeoff
<heat> just a sec, I have realized I'm missing a tiny lock
<heat> yeah im doing fnv
<mjg> ... and back to < 2 mln
<heat> no
<mjg> :)
<mjg> fg me
<heat> I just need to check the d_parent when looking up, and I need to read_lock for that
<mjg> that is going to cost you
<heat> sure, but you need it
<heat> even linux does something like it
<mjg> i'm saying perf will go down
<mjg> so you are not at the above levle yet
<mjg> do you count open file descriptors?
<heat> count?
<heat> maybe?
<mjg> maybe?
<mjg> oh not file descriptors
<mjg> descriptions
<mjg> aka 'struct file' or however you call it
<heat> no
<mjg> that would be a perf hit if naively implemented (which is what fbsd is doing :>)
<heat> atomic add?
<mjg> but also means the test is slightly unfair against other systems
<mjg> yea
<mjg> linux has a meh scheme to make it scale in the common case
<bslsk05> ​gist.github.com: open1-4.svg · GitHub
<mjg> you are losing some perf because of your fucked cred scheme
<heat> i think I won some good perf by replacing the sleepable mutex in the file table with a spinlock
<heat> although this is processes and not threads
<mjg> therew ould be no change if your sleepable locks did not suck
<mjg> :>
<mjg> wut
<mjg> struct rlimit process::get_rlimit(int rsrc)
<mjg> }
<mjg> { scoped_rwslock<rw_lock::read> g{rlimit_lock};
<mjg> return rlimits[rsrc];
<mjg> this is also a huge problem
<heat> i need consistency
<mjg> you can handle both rlimits and creds with copy on write
<heat> sure
<mjg> see freebsd
<mjg> then synch goes away
<heat> freebsd is not real
<mjg> see thread_cow_update
<heat> mooooooooo
<mjg> right now it kind of sucks when it has stuff to do (which is almost never), but it can be patched
<mjg> anyway at this cost:
<mjg> if (__predict_false(td->td_cowgen != atomic_load_int(&p->p_cowgen)))
<mjg> thread_cow_update(td);
<mjg> you are sorted out
<mjg> in the syscall entry point
<heat> yeah
<heat> actually I found an extra lock
<mjg> i also observe your typical consumers only look at *one* int
<mjg> as in you you only need to return rlim_cur
<mjg> and that much you can do with a mere atomic_load
<mjg> most notably in alloc_fd
<heat> bbbbuut my object orientation!
<heat> my beautiful interfaces
<mjg> i'm sure your mom said your api is beautiful
<mjg> ask someone else's mom though
<heat> she did't
<heat> it's unix
<heat> hehehehe
<heat> i have almost 3M now on open1
<mjg> in fact all get_rlimit consumers i grepped only use rlim_cur
<mjg> wait, now that i think about it, your code is incredibly suspicious
<mjg> why is this even on the profile
<mjg> you are running _processes case right?
<mjg> so there should be no ping poing from it
<mjg> do you have these structs allocated separately for each rpoc?
<heat> it's sus
<heat> yes
<heat> can I map samples to instructions?
<heat> as perf would do
<mjg> ye-ish
<mjg> what exactly are you trying to do here
<mjg> i would recommend a borrowing a hack from dragonflybsd
<mjg> there is optional instruction sampling on clock ticks
<mjg> and a tool to dump it per-cpu
<mjg> which is basically poor man's profiler
<heat> I want to see what % of samples each instructions hits
<heat> for a poor man's intel PT
<heat> instruction sampling?
<mjg> you would need to generate that somehow(tm)
<heat> I have all the info
<mjg> i don't know of a cheap way modulo full blown tracing
<mjg> apart from the hack above which should be sufficient for the time being
<mjg> it will nicely showcase smp problems when microbenchmarking
<heat> I just want to go from symbol + offset to nice instruction visual thing like perf
<heat> I have literally all the information for that
<mjg> oh that's what you mean, i don't know what you can feed it to
<mjg> sorry man
<heat> no dtrace thing for that?
<heat> given I stole my format from dtrace
<mjg> no
<heat> wtf guys
<mjg> blame SOLARIS
<heat> ngl your tooling kinda sucks
<mjg> yes and no man
<mjg> for fucking around with cpu events i go for pmcstat
<heat> i think i'll need to go and disect the perf format so i can viably output or convert to it
<mjg> whoa
<mjg> well good luck man
<mjg> not a bad idea but probably too much work at this stage
<zid> fisu: push or riot
<mjg> as in bad bang for the buck
<heat> yeah im not doing that rn lmao
<heat> this must be sched_disable_preempt's doing
<fisu> zid: do you mean push to git?
<zid> yes
<fisu> sure, I'll upload my changes to the wip branch again
<heat> but this is trivial wtf
<fisu> though at this point it's less code because I can't seem to find what's wrong with the printing
<mjg> heat: this reminds me
<mjg> heat: context_switch1_processe
<mjg> heat: ty it
<heat> just a sec
<mjg> openbsd has (or at least had) a bug where it would keep bouncing the worker between cpus
<mjg> demolishing perf
<heat> my scheduler doesn't even migrate processes lmao
<zid> fisu: you changed that i386 ifdef but my point was you're checking if you're *not* building for i386, then erroring if-so
<mjg> heat: :D
<mjg> heat: ok, don't do it then
<zid> oh I think I got the aspect/tense/whatever misinterpreted?
<heat> it's scheduling everything in separate cores *by chance*
<mjg> to be revisite
<mjg> d
<zid> it's an error because we are not building, not that it's a statement that you are not building for i386, got it
<zid> hmm I don't have xorriso, what's that tool
<heat> mkisofs?
<heat> mjg, dude my rwspinlocks look "super optimal"
doorzan has joined #osdev
<heat> i genuinely don't see what's wrong here
<heat> maybe it really is cache bouncing
<heat> anyway not really a problem
<mjg> add a printf what's the addr
<mjg> on fork
<fisu> zid: oh, my brain seems to have malfunctioned
<heat> mjg, hm?
<fisu> zid: but basically grub uses xorriso for something when creating the iso
<zid> never heard of it, I use mkisofs and a copy of grub's stage2
<mjg> heat: printk("rlimit %p pid %d execname %s", ......
<zid> ah crap capstone updated to a new soname so my out of tree qemu now can't find it *rebuilds qemu*
<mjg> heat: in process_create
<heat> why?
<mjg> to validate you don't end up with the same rlimit obj
<zid> what build options do I use for qemu I apparently didn't write them down, oopsie
<heat> rlimits is embedded in process
<heat> i know it's not the same
<mjg> hm
<mjg> that's weird then
<mjg> well fix some other shit will get to it :D
* zid going on a journey to fix his shit
<mjg> will get back to it*
<fisu> zid: apparently xorriso is what mkisofs was called before
<zid> weird, cus you're using grub2
<zid> you'd think it'd use the modern name, grub 0.97's docs even use mkisofs
<heat> mjg, I think 3M out of 1M single threaded is already pretty decent
<fisu> yeah
<zid> make -j12'ing qemu's a good tst for my new cpu I guess
<heat> for a locked walk that is
<mjg> heat: wait that's 3m with -t 1?
<heat> no
<mjg> are you still pessimized with rdtscp?
<heat> 3M t 4, 1M t 1
<heat> absolutely
<heat> not even rdtscp
<mjg> hm
<heat> worse
<heat> lfence; rdtsc
<heat> lfence; rdtsc is rdtscp before rdtscp
<heat> and overall slower
<mjg> scaling factor would be ok to look at if your -t 1 case was sensible
<heat> why is it not sensible?
<mjg> you should be getting about twice that
<mjg> if not better
<heat> why?
<mjg> it is plausible you are mostly shafted by that dtscp tho
<heat> i'm beating net and open ez
<heat> do i need to beat freebsd now?
<heat> my cpu is kinda shit too
<heat> im mostly sure I'm not vmexiting there
<mjg> lemme find it
<mjg> test t c FreeBSD DragonFlyBSD NetBSD FvD FvN DvN
<mjg> openro3 p 01 2137897 869776 1263720 +145 +69 -32
<heat> you don't actually need to vmexit on rdtsc
<mjg> that was 2 years ago on cascade lake
<heat> i'm on a 4 year old kabylake R
<heat> ULP
<mjg> you should still be approaching 1.5 mln minimum then
<mjg> being faster than netbsd is not really anything to be proud of
<heat> it is
<zid> Interesting, grub goes "selected item cannot fit into memory"
<mjg> heat: well you know your worth!
<heat> 30 years of software development and field experts vs me, a single person
<mjg> dude what :D
<mjg> plz
frkzoid has joined #osdev
<heat> i dont need to seriously measure dicks with every operating system out there
<mjg> that's definitely a funny way to put it
<mjg> look you do you, just sayin there is definitely a lot of room for impeovement without R C U
<heat> sure
<heat> im not saying there isn't but this is already pretty decent
<fisu> zid: where did you find that? but yeah, that is interesting...
<mjg> look if you are happy with it, that's good for oyu
<zid> can I be bothered to debug grub
<heat> zid, you need more memory
<mjg> but don't claim you are winning against some level of expertise here, the code at hand is total crap
<zid> heat: let's try 4GB
<mjg> a rule of thumb if you can double it over the weekend, maybe it was not that good to begin with
<heat> you may not need more memory
<zid> 4g fails on the qemu side :P
<zid> pc.ram cannot allocate memory
<heat> mjg, *shrug*
<heat> i couldn't legally drink 2 years ago
<zid> This is linked all sorts of wrong though
<mjg> hmm
<zid> looking at the actual ELF
<mjg> heat: can you bench sortix? :D
<heat> one-man-showing this shit into a decent thing is pretty impressive IMO, at least I feel proud of it
<heat> mjg, it's going to get beat super easy
<zid> fisu: got a moment to explain "-lc -nostdlib"
<wxwisiasdf> sortix hmmmmmmmmm
<heat> sortix doesn't have a page cache, no dentry cache, no SMP, ext2 is done in user space
<mjg> heat: look man. you wrote a system from scratch which boots multi user, that's impressive in its own right
immibis_ has joined #osdev
<mjg> wut?
<mjg> huh
<heat> yes
<fisu> zid: I'm making my own standard library
<zid> yea but I'm not installing it as my system libc in order to build your kernel sorry
<mjg> what other kernel hangs around in there
<mjg> maybe haiku? :)
<fisu> oh, I figured if I passed `-Lbuild -lc` to it, it would look in there first
<zid> *maybe* but that isn't how you should do this
<zid> just pass libc.a directly
<fisu> ah
<fisu> yeah makes sense,
<zid> you can use -l:libc.a if you want it to check search paths
<heat> i would love to beat serenityOS's ass
<zid> but.. you know where it is
<heat> but I can't bother building their crappy system
<mjg> hmm
<fisu> yeah
<mjg> they don't have an installer?
<heat> they don't even distribute images
<heat> ForSomeReason
<mjg> let'/s take a look at the code
<heat> no hobby OS is objectively scalable
<mjg> ye i don't think they are doing perf work over there
<heat> did you get that from the " LibWeb: Make Fetch::Infrastructure::{Request,Response} ref-counted "
<mjg> :)
<heat> or the fact that the last 20 commits are 90% web browser dev
<mjg> from a quick look at locking primitives
<mjg> still haiku would be interesting
<j`ey> heat: yeah it does seem to have been taken over, shoulda made it separate
<mjg> maybe i'll bench myself
<zid> oh hey, I think I got it booting? maybe.
<zid> I had to hack your makefile to shit first
<zid> I have a flashing cursor at least, EIP=1000d3
<mjg> heat: i guess people don't write an os from scratch if the goal is multicore perfomrance
<mjg> heat: for fun anywy
<zid> ah that means kernel_main() returned, and it infinited in _start, okay
<zid> and kernel_main() is blank, so it worked as expected I guess, neat
<mjg> > FoxOS's goal is to develop an operation system that focuses on the terminal, performence and reliability. And hope to provide users with a functionnal, performant and stable OS.
<mjg> now that seems like a target :)
<heat> Process::sys$open()
<heat> is this a valid C++ identifier?
<zid> fisu: I had to do -ffreestanding -fno-PIE + libc.a hax to your makefile, but I am successfully booting now
zaquest has quit [Ping timeout: 268 seconds]
<zid> I could have just used my makefile but that felt like cheating :P
immibis_ has quit [Ping timeout: 268 seconds]
frkzoid has quit [Ping timeout: 268 seconds]
<heat> mjg, serenityos's vfs doesn't even have a dcache
<fisu> zid: lmao, but did you manage to get it to print hello world or something?
<zid> no but the code in the repo doesn't try
<j`ey> heat: seems to be implementation defined
<zid> kernel main is empty
xenos1984 has quit [Ping timeout: 250 seconds]
<fisu> but it's odd, I tried to do this `-l:src/stdlib/libc.a` but ld just says libc.a is not found
<mjg> heat: i'm looking at this foxos thinyg, does not look good either
<mjg> heat: so far it seems you don't have competition on perf front in homebrew os space
<mjg> everyone just doing what they like, and it happens to not be perf
<mjg> if you are not burned out by perf work, perhaps you can try a non-vfs bench against netbsd?
<mjg> page_fault1 would be a start
<heat> sure
<heat> do you understand what I mean now?
<zid> fisu: is ../../ in your search path thou\gh?
<heat> i'm not on equal footing to *any* of the BSDs
<zid> I mean
<zid> src/stdlib/../../ in your search path
darkstarx has joined #osdev
<mjg> heat: i'm saying you can pick any benchmark and likely beat non-freebsd with modest effort
<zid> such that src/stdlib/../../src/stdlib/liba.c finds src/stdlib/libc.a
<zid> phew
<mjg> heat: i know because i used to pick a random benchmark and patch freebsd to get a significant speed up on it
<zid> src/stdlib is where it looks, if you look for src/stdlib/lib.ca there you end up with src/stdlib/src/stdlib/libc.a
<mjg> heat: and it was easy
<mjg> heat: as in easy to do better than bsds tend to do, not necessarily easy to be anywhere near close to optimal
<zid> we need #mjgs-and-heat-flirting-over-locks
darkstardevx has quit [Ping timeout: 264 seconds]
<heat> :DD
<mjg> here is a funny netbsd tidbit to give you an example
<mjg> standard problem on i386 was the limited KVA and subsequent transient mappings for i/o
<fisu> zid: I got it now, I did `-L$(PWD) -l:src/stdlib/libc.a`
<mjg> when going for amd64 kernels would the direct map and use it to do away with the above
<mjg> ... except netbsd did not :D
<mjg> reads are turbo slow because of it, let alone parallel reads from different files
<zid> I'd have just done that but deleted the `-L$(PWD) -l:` part probably
<mjg> or at least used to be last time i checked
<mjg> they had a patch to fix it, buti t was disabled due to bugs
freakazoid332 has joined #osdev
<zid> lmk when I can pull and get your broken print
<heat> mjg, 930k on mine, 760k on theirs, t2
<heat> although this is processes so not much contention except on memory allocation
xenos1984 has joined #osdev
<mjg> page_fault1/
<mjg> what happens with the _threads variant
<heat> hm?
<heat> ah
<heat> let's see
<bslsk05> ​github.com: horizon/sys_get_file_size.cpp at 62f0607a1ed9eaf211093893c25386de71c4cb8a · TheUltimateFoxOS/horizon · GitHub
* mjg supports
<heat> dude is miles ahead of linux and freebsd
<zid> furryos?
<zid> yes, y es it is
<zid> both a furry os, and ahead of linux
<heat> 292k on net, 670k on mine
<mjg> heat: o/
<mjg> heat: right on
<mjg> heat: UVM
<heat> i dont play baby
<heat> fuck you cranor
<fisu> okay so it seems that this works https://pastebin.com/JbwQmpYM BUT, if I move the code into stdio.c like this it won't work anymore https://pastebin.com/GH3VKZMY
<bslsk05> ​pastebin.com: uint16_t encode_color(uint16_t color, char ch) { return (uint16_t)(color - Pastebin.com
<bslsk05> ​pastebin.com: // stdio.cuint16_t encode_color(uint16_t color, char ch) { return (uint16 - Pastebin.com
<heat> my kernel is built on good principles
<heat> i dont need them fancy uis
<mjg> can you fg netbsd from this
<mjg> to make sure it's not something st00pid disfiguring
<zid> fisu: Can you push that second one out?
<fisu> sure
<Ermine> heat: is shell an ui?
<heat> sure
<heat> not a fancy one though
<zid> watch -n2 git pull
<zid> wrong window
<mjg> not gonna watch
<heat> watch me whip, watch me git pull
<mjg> pretty weird usag :D
<fisu> zid: done
<zid> you force pushed didn't you? :P
<heat> oh no
<fisu> yeah.. I'm treating my WIP branch like gerrit
<mjg> we need #zid-fisu-collab
<zid> same
<zid> I don't actually know how to 'force pull' as it were
<mjg> zid: git fetch
<heat> you can't
<zid> I bet I can
<mjg> heat: you getting that fg or not
<heat> hold the fuck on
<mjg> OH
<fisu> git fetch && git reset --hard FETCH_HEAD maybe
<mjg> the mouth on you
<heat> goto holdthefuckonmjg
<zid> git fetch; git-
<zid> fuck you beat me
<mjg> heat: goto ihateyou
<fisu> ;)
gog has joined #osdev
<fisu> I wish github had something similar to how gerrit does things
<zid> build/imperatrix/boot/imperatrix is getting *old* to type, ngl
<heat> are you a googler
<fisu> oh... I usually just do `make run`
<zid> I'm ru nning tools on the files
<zid> like readelf, objdump, etc
<fisu> oh good point
<zid> The disassembly for printf is interesting
<zid> call __x86.get_pc_thunk.ax; add eax, 0x113b; mov eax, 0; ret
<fisu> huh
<Ermine> wtf is __x86.get_pc_thunk.ax
<zid> a thunk to put pc into ax?
<heat> it's how you get the current pc
<fisu> is it just optimizing out everything?
<Ermine> Is it compiler builtin?
<zid> yes
<fisu> zid: I changed it to `cp` instead of `mv` just for you, now you should find the kernel in the root directory
<zid> nice
<bslsk05> ​gist.github.com: netbsd-pf1-2.svg · GitHub
<zid> I think your makefile has its deps wrong btw
<zid> or the fact it's hiding so much output is confusing me, one or the other
<fisu> run `make HIDE=`
<zid> but changing src/stdlib/stdio.o didn't appear to rebuild as much as I would expect
<zid> can try next time
<zid> yea no it doesn't bother rebuilding libc.a it seems?
<zid> or doesn't print anything about building it still, at least
<zid> make clean does not delete libc.a
<fisu> hmm, yeah it seems there's a bug with that
<zid> hmm I don't have stdarg.h apparently
<zid> how did you manage to break that I wonder
<fisu> I haven't implemented it yet
<zid> you don't need to
<heat> i just wanna note that the author of foxos really is a furry
<zid> the compiler does, same with stdint
<fisu> I think I have enabled `-nostdinc` which removes everything iirc, maybe I'll change it to just use `-ffreestanding`
<zid> yea I was just fixing your makefile in that exact manner
<heat> yes
<zid> (2nd time, I forgot I went back to your 'new' makefile because of the reset stuff)
<fisu> but yeah you were correct, there was a bug with building the stdlib which caused it not to be updated correctly
<fisu> lmao
<zid> 99% of the issues so far have been the damn makefile
<fisu> yeah...
<fisu> back to the drawing board with that one I suppose
<fisu> thanks for your help <3
<heat> use a real build system
<heat> or if you're weird, bsd make
<fisu> which do you suggest? I heard meson is pretty good
<heat> idk
<zid> make
<zid> but don't be dumb
<heat> meson, gn, bazel I guess, cmake if you're a masochist
<heat> autoconf is you really like pain
<fisu> rofl
<zid> libc.a should be a requirement of kernel, libc.a should require libc/*.c
<zid> kernel should require kernel/*.c
<heat> no
<heat> it should require *.o
<zid> that too
<zid> I skipped an intermediary
<heat> .o requires .c plus whatever generated files you have
<fisu> I think my mistake was that I made it a "recursive" makefile or so, I have the separate makefile just for the stdlib
<heat> then if you're fancy you enable the dep files
<zid> oh is that why it keeps building it wrong
<fisu> yeah
<zid> where's that 2nd makefile
<fisu> src/stdlib
<fisu> heat: I'm using the .dep files
* zid deletes -nostdinc
<heat> kde got the big stupid
<heat> it's inverting the night colour filter
<zid> perrfect, now it's complaining about not finding libgcc, which is ideal, because I don't want it to link against libgcc
alphajuliet has joined #osdev
<alphajuliet> Operating System Development
<heat> fact
<zid> I guess x86 doesn't support va_arg without libgcc?
<zid> wait yes it does, my bootstrap does it
<alphajuliet> the statement x86 doesnt support without... is false in the core
<alphajuliet> because if it's support with something then well.. it's supports va_arg
<zid> man, the x86 target is fucky, glad I don't do anything more than load an elf in mine
<alphajuliet> and if zid can do it, so can i
<j`ey> zid: x86 target.. in what? qemu?
<zid> gcc
<alphajuliet> hey j`ey
<j`ey> hi albert
<heat> h`ey
<alphajuliet> heat: my bad ..
<alphajuliet> i have to ask ... are you guys utilizing makefiles in your workflow ?
<alphajuliet> or some equivalent?
<fisu> I'm using them
<alphajuliet> fisu: thanks
<fisu> zid doesn't seem to like them though :(
<alphajuliet> well zid is not the authoritative voice in #osdev
<dminuoso> If I were to do osdev again, I would use shake.
<zid> I like my makefile
<heat> zid is the authoritative voice in #osdev
<fisu> I was thinking of using meson but we use make at work so figured that I might as well get better at it
<zid> https://github.com/zid/bootstrap/blob/master/Makefile mainly because it fits onto a sheet of toilet paper
<bslsk05> ​github.com: bootstrap/Makefile at master · zid/bootstrap · GitHub
<fisu> it's not like meson will ever be safety approved
<alphajuliet> j`ey: what are you saying about makefiles and such ?
<heat> what do you work on?
<heat> aerospace shit?
<zid> it builds a 32bit boot.bin, 64bit kernel.bin, and produces a bootable ISO from it
<j`ey> alphajuliet: Makefiles are fine
<zid> in.. 41 lines
<fisu> no, cars
<zid> You poor bastard
<fisu> mhmm
<heat> >meson not safety approved
<heat> >gnu make safety approved
<zid> mkisofs graft points ftw btw
<heat> what's the manufacturer so I steer (ba dum tss) clear
<fisu> probably every single one almost
<zid> I don't copy the kernel around I just tell it to grab them out of the build dirs when it makes the iso
<fisu> it's MISRA that issues the approvals
<zid> (You can't normally do this because it'd mess with the filenames, your cd-rom would have an ../build/boot.bin on it)
<alphajuliet> since we are talking osdev, i almost sure that you guys containerize your kernels right for testing purposes ?
<zid> fisu: Anyway, I got your code as far as needing libgcc and I can't figure out precisely *why* it knows it needs libgcc
<zid> nm won't tell me
<heat> -nostdlib
<zid> libgcc isn't part of stdlib though
<zid> or does it disable the -l:libgcc.a anyway
<gog> i use makefiles
<fisu> I got stdarg to work actually
<alphajuliet> gog: but you are also a cat
<gog> works fine
<zid> oh yea that does fix it, weird
<zid> I'll look into that
<gog> mew
<alphajuliet> gog: meow
<alphajuliet> that's it
<heat> libgcc is part of stdlib
<heat> stdlib != libc
<alphajuliet> ok now seriously
<alphajuliet> ok i want to be useful
<alphajuliet> why the sudden quiet ? is it that surprising that i want to be useful ?
<alphajuliet> don't answer
<zid> oh yea I suppose, but it doesn't explain the behavior though
<fisu> hmm, I just realized I'll have to make some makeshift malloc or something
<fisu> probably
<zid> not yet
<zid> you can do a surprising amount with static blah x;
<fisu> yeah, true
<gog> if you never allocate memory then you never have to free it
<heat> do a slab allocatorrrrr
<gog> problem solved
<heat> bonwick best!!!
<zid> I'm getting the un DT_TEXTREL in a PIE warnings
<zid> fun
<heat> fno-PIE
<fisu> yeah I was just thinking of how I should implement int to ascii but perhaps I can just write directly to output instead of allocating a buffer
<fisu> yea, I was trying to fix that earlier but with no luck
<zid> yea it's all no-PIE
<zid> you need to do it to the linker and assembler too
<zid> with -Wl,-no-pie and whatever the assembler one is etc
<zid> and avoid certain things in the code
<heat> fisu, you don't need to allocate here
<heat> char buffer[32];
<zid> welcome to 30 seconds ago heat
<heat> thanks
<heat> what do i get
<gog> you can use my printf
<zid> 30 seconds of past
<gog> no dynamic memory required
<zid> can use mine too, no dynamic memory required
<zid> but I don't think that's the point
<fisu> gog: it's alright, I want to implement it myself
<alphajuliet> im going to prove that i can do shit
<gog> ah yes this is #osdev and we all have NIH so bad we're making kernels
<gog> i forgot
<fisu> NIH?
<zid> exactly
<gog> Not Invented Here syndrome
<zid> not-invented-honduras
<zid> oh I was close
<clever> gog: ive seen a talk on how to get more stable framerates in android games before, and the answer is the same, just dont allocate memory while running the game!
<gog> exactly!
<zid> I mean, that's what my OS does
<zid> and it even supports network traffic
<clever> gog: make every bit of state a field on a persistent object, and reuse them between frames
<zid> correct
<clever> the less the gc has to collect, the fewer times your going to miss a frame to gc
<zid> perf optimizing often does that naturally
<bslsk05> ​gamesfromwithin.com: Start Pre-allocating And Stop Worrying – Games from Within
<clever> do it right, and you can turn the gc off for an entire level
<fisu> `stdio.c:(.text+0xf5): undefined reference to `__stack_chk_fail_local`` huh
<heat> -fno-stack-protector
<fisu> thanks..
<heat> please get a cross compiler
<heat> thanks
<zid> you have stack hardening enabled by default
<gog> are you on a debian based distro
<heat> this is a fully pimped out distro gcc
<zid> and I have pie enabled by default, hence all the fucking around with nopie
<heat> default PIE, stack-protector default too
<gog> i use PIE
<fisu> I'm on manjaro
<heat> FUCK
<Ermine> I want PIE
<zid> the fuck is a manjaro
<heat> NOW*
<fisu> heat: :(
<gog> sssh don't tell people you use manjaro
<zid> is that like slackware for hipsters or something
<gog> we're a hated minority
<heat> its arch for
<heat> <redacted>
<fisu> lol, I have arch on my laptop
* gog peeks behind the redaction
<zid> oh I run gentoo, so I'm morally superior to all of you
<zid> ez
<bslsk05> ​www.kickstarter.com: Access to this page has been denied.
<zid> 2 levels of superior to fisu
<gog> zid: enjoy your funroll loops
<GeDaMo> "VisionFive 2 - open source quad-core RISC-V dev board"
<fisu> arch isn't difficult, cba to install it twice though
<heat> zid, build firefox with -O3 -funsafe-math -funroll-loops
<zid> gog: i am, it's part of O2
<gog> lol
<alphajuliet> GeDaMo is in the building
<zid> (I use -O3 -march=native)
<heat> -april=native is better
<heat> but you do you
<zid> shit my headphgones are falling apart
<zid> where is the superglue
<zid> and noodles
<gog> i ate it
<zid> ate the glue, snorted the noodles
<gog> yeh
<Ermine> let's make -may=native, I have birthday in May
<zid> fisu buy me some more hd206s
<zid> so I can break them again
<gog> sennies?
<gog> rip
<zid> ye the dirt cheap ones
<fisu> omegalul
<fisu> man I bought some sennheiser headphones, they've lasted me like 7 years now
<zid> do you fall asleep wearing them
<zid> and wear them 18+ hours a day
<fisu> I've had to buy the cable though twice
<fisu> I don't sleep with them but I do wear them like 10+h a day
<zid> and.. occasionally sit on them
<zid> okay so not a fair test
<fisu> lmao
<fisu> clearly
<zid> man, fucking tories, £25
<gog> i got nos h-600
<gog> they were the chepaest at elko
<gog> cheapest that looked decent
<gog> the build quality isn't the best
<gog> they sound fine tho
<gog> i should've done more research and maybe looked elsewehre though
<gog> spent way too much
<zid> I jsut spent all my money fixing my PC
<zid> headphgones will have to be noodles and glue for a while
<gog> i'll buy you a set but you would have to promise to be extra nice to me for a year
<zid> idk how to break this to you, but I am extra-super nice to you gog
<zid> it's heat I am mean to
<gog> ok you'll have to be nice to heat for a year
<gog> not even extra nice
<zid> I think that's worth 599s
<gog> oof
<zid> (I have no idea of those are good)
<gog> 4.7 stars on amazon
<zid> I just quickly searched for 'more expensive' to make that joke
<mjg> heat: ok, it's obvious: waiting off cpu for lock owner
<mjg> heat: that's the turnstile stuff
<zid> Those look basically the same as HD206s ngl
<zid> lots of 1 star reviews with the exact same issues the 201/206s have
<zid> hard to drive and they resonate enough to rattle at certain freqs
<fisu> heat: could you enlighten me, where can I find a cross-compiler?
<gog> that's not very good nah
<zid> You make them, fisu
<fisu> :s
<zid> build gcc with the exact options your kernel wants so you can just "gcc thekernel" basically
<zid> and install it as gcc-coolos-elf
<zid> like gcc-linux-elf
<heat> no
<heat> it's arch-os-gcc
<zid> then you install gcc-onyx_sux_user-elf for building user programs
<zid> then one for screensavers
<heat> you're doing everything in reverse
<zid> then one for drivers
<heat> x86_64-elf-gcc
<zid> I was talkign about the binary
<zid> and dropped the arch
<fisu> heat: oh it's AUR only, I see
<heat> no
<zid> The real solution btw, is to switch to amd64
<heat> it's not in the AUR
<bslsk05> ​aur.archlinux.org: AUR (en) - x86_64-elf-gcc
<heat> manjaro will not be able to DOS that one
<heat> oh fuck them
<fisu> hmm?
<zid> then your desktop gcc will be broken regardless, and there is no libgcc
<heat> you should build it manually
<zid> meh, tbh
<zid> it's what you "should" do
<heat> "manjaro will not be able to DOS that one" <-- manjaro devs have DDOS'd arch linux aur and repos many times with their incompetency
<gog> use clang
<zid> but it's much nicer if it just builds from your desktop by massaging the makefile long enough
<fisu> so on my laptop I could do it then?
<gog> friendshpi ended with gcc
<heat> yes
<heat> actually
<heat> maybe clang does work
<zid> All my shit just builds fine from gentoo's desktop gcc, so whatever
<heat> yeah just use clang
<zid> does clang still use plan9 assembly
<heat> --target=i686-elf
<heat> no
<fisu> yeah, clang seemed really nice, is there a reason to use gcc actually over clang?
<zid> momentum
<zid> clang is the hideous usurper
<heat> communism
<zid> trying to steal gcc's throne
<fisu> lmao
<zid> gcc is good old fashioned communism
<zid> clang is the shiny fascist tyrant
<heat> clang is a left wing caviar socialist
<zid> that's what clang wants you to think
<heat> gcc is a hard line USSR communist
<zid> it's actually putin in a wig
<gog> soyuz nerushmiii respublik svobodnyk
<heat> uhm
<zid> he's all like "I will save you from communism by doing politics correctly"
<heat> da
<zid> then you're in a gulag
<fisu> I'll try clang and see how bad it breaks
<Matt|home> <fisu> yeah, clang seemed really nice, is there a reason to use gcc actually over clang? <-- as a serious answer to that question, to my knowledge clang and gcc are fairly neck and neck and share similar market portions
<Matt|home> gcc's been around longer but they both get the job done
<Matt|home> and honestly probably both perform fairly equal
<zid> using clang makes you look like a hipster imo
<Matt|home> so personal preference imo.
<heat> getting the job done is the important bit
<heat> the size doesn't matter
<zid> so it's not a 50/50 choice
<gog> i'm a massive hipster
<zid> this is fully tribal at this point
<gog> i use .net
<zid> do you want a big furry beard
<fisu> I see, I'll try out clang then
<gog> no i want the opposite of that actually
<Matt|home> actually it's pretty crazy how insane the optimizers are nowadays
<zid> or a nice and tidy beard and check shirts
<fisu> are then't the flags a little different between the two as well?
<zid> slightly yea
<gog> slightly depends on the target
<Matt|home> the compilers just look at your code and figure out what the most efficient way to do what you want done is
<Matt|home> to the point where they'll flat out ignore functions and code blocks that either don't do anything or do something irrelevent or repetitious or whatever
<gog> i've been using clang because i don't want to keep my x86_64-elf toolchian up to date
<heat> and because i literally submitted a PR to do so
<gog> i guess that wouldn't be a problem anymore with my shiny new computer
<heat> i changed your life
<gog> oh that's right
<gog> zid: heat is responsible for me using clang
<zid> gcc = robert sapolsky
<zid> gog: you're a hipster though
<gog> yes
<zid> I bet you don't even HAVE a beard
<Matt|home> like you could have one function try to calculate the sum of 2 values, pass it back to main and print the sum and the compiler would look at it and be like "oh so you're just printing a number, i can do that in three instructions"
<wxwisiasdf> zid: i think they don't
<gog> i don't have a beard no
<gog> sorry
<zid> see, clang for you
<zid> gcc for me
<fisu> Matt|home: yeah, it's pretty crazy what they can do these days
<zid> sempai robert sapolsky will notice me eventually
<zid> s/m/n
<wxwisiasdf> you just replaced me with ne
<Matt|home> fisu : clang's fine. also, this might come as a contentious opinion, but even though nowadays people use cmake for their projects.. imo it's still worth learning make for smaller ones
<wxwisiasdf> what about msvc
<heat> msvc is fine
<wxwisiasdf> or ibm c++, or intel c++
<zid> actually if the word was sempai in *english* the japanese would be senpai anyway
<heat> tianocore builds with msvc usually
<zid> see: jump -> jianpu
<zid> and other examples
<fisu> Matt|home: I somehow figured that it might be easier to use make for this, though I might've been wrong though... seeing how much work it's caused me... but I plan on using `meson` for the next project
<fisu> I used cmake for one a while back and it was well... pretty painful...
<zid> cmake has stockholm syndrome
<Matt|home> im not super up to date on anything past 1986 so i can't comment :p
<zid> if it's hard to use and learn, it must be worth it in the end
<zid> else why would it be hard to use and learn
<Matt|home> it has improved considerably
<wxwisiasdf> cmake is doing node_modules but in c++
<zid> make is hard to learn but trivial to use
<gog> springsteen, madonna, way before nirvana?
<zid> that's why people write shite in it :P
<zid> fisu: did you ever look at my amazing bootstrap repo? (I linked its makefile a bit ago)
<fisu> yeah, the issue with cmake is that there's a 1000 ways to do things and it's difficult to know which one is the "correct" one
<wxwisiasdf> everything that is widely used has software written on it with the worst practices ever
<wxwisiasdf> eg. java
<zid> java people don't write software, that's the mistake
<zid> they write factoryfactorys
<fisu> zid: can you link it again, apparently I didn't control click it
<bslsk05> ​zid/bootstrap - AMD64 bootstrap example. Sets up long mode and paging starting from a 32bit ELF booted by grub. (0 forks/0 stargazers)
<gog> yo dawg i heard you like metaclasses
<zid> you can ignore the kernel bit, the boot part is equivalent to what you have so far
<zid> my boot part just happens to implement an elf loader after printf("hello world")
<alphajuliet> gog: yo dawg ?
<alphajuliet> try again
<fisu> yea, it's pretty simple, I wanted to have mine go into a build directory etc, which made it probably a bit more complex than it needs to
<zid> you could rm -rf k* and get your exact project, 32bit elf booted by grub that implements printf and is built by a makefile and makes an ISO
<alphajuliet> osdev is a white buisness
<dh`> zid, does that lot have a license? don't see one
<zid> dh`: yes, copyright
<Matt|home> so i'm going to make an executive decision.. to my knowledge there's no real easy way to switch between desktop environments on any OS. Even in ubuntu with a decent package manager there are a few dependency issues, duplicate files etc. What I'd like to do is embed some feature that let's you switch environments completely without technical problems, kind of like the windows old school xp/98 vs vista/7/8 aesthetics they let you togg
<Matt|home> le in the menus, but with a lot more options
<heat> nice legal trap
<zid> I wrote it, it's mine, email me if you want to sublicence it
<Matt|home> I really don't understand why this hasn't been implemented before apart from "because it'd be a pain in the ass to do"
<dh`> so, no
<zid> copyright is the licence, the government made me do it
<fisu> Matt|home: yeah, I remember trying to go from gnome to xfce once and it was essentially easier to just re-install ubuntu
<alphajuliet> p.s im not a racist
<dh`> copyright is not a license
<zid> sure it is
<zid> You have license to look at it but not distribute it or subvert its DRM etc :P
<fisu> dh`: you can upload the source without making it "free as in freedom"
<wxwisiasdf> abolish copyright, let everyone copy o7
<dh`> no, it is definitely not.
<zid> It's literally what the word means though
<dh`> fisu: sure you can, but nobody else can use it and maybe can't read it
alphajuliet has quit [Quit: WeeChat 3.6]
<wxwisiasdf> ah yes, copyright infirgment for listening music in the radio
<zid> It's technically already under license to github I guess, but I never actually checked the terms
<dh`> posting it on github is _probably_ permission for github to display it and _maybe_ permission for other people to look at it
<zid> my gameboy emulator is licenced to a penguin or to too
<GeDaMo> Something something co-pilot :P
<zid> it being buried in norway somewhere
doorzan has quit [Remote host closed the connection]
<zid> does norway have penguins?
<GeDaMo> No
<dh`> no, it is not what the word means. copyright is one legal concept, licenses are another
<GeDaMo> Maybe in a zoo
<dh`> anyway IANAL but you need to look at some legal FAQs
<fisu> anyway, I gotta go, cya probably tomorrow with more issues...
<Matt|home> also i noticed that in some cases core software like package managers aren't actually made for multi-core processors.. is there a reason behind this?
<zid> dh`: I never said licences, I said lincense, the verb
<zid> permit (someone) to do something.
<zid> lawyers love it
<Matt|home> bye fisu o\
<zid> fisu: Rub cream on it twice a day
<zid> oh wrong channel
<gog> ah i figured that alphajuliet was fatalbert
<dh`> zid, like I said, visit some FAQs
<zid> only now gog? lol
<gog> nah i had suspicion when they joined
<dh`> you just gave me permission to look at it (whether irc counts as written or not is probably an open question)
<gog> confirmed when they dm'd me something racist
<zid> I assume they immediately started with word salad diarhhea
<dh`> which is great but not helpful in general
<zid> cus you know, untreated schizophrenics be like
<gog> there are at least 4 of them istg
<gog> why do they gravitate here
<heat> can you not just ban the ipv6s?
<heat> it's *very* unlikely to fuck someone innocent over
<Matt|home> i'd appreciate it if you didn't..
<heat> individual ones
<zid> *highly* unlikely
<heat> not all :)
<zid> ban 2001:*
<zid> nobody uses that range
<gog> and 2a02
<gog> a lot of VPNs on 2a02 it seems
<zid> I am 2001:470:1c09:1cfb::/64 usually
<zid> but I haven't bothered to fix my ipv6 back up recently
<wxwisiasdf> where is ipv8
<zid> certain steam games' multiplayer just shits the bed if ipv6 is enabled
fisu has quit [Ping timeout: 264 seconds]
<zid> see, nobody uses 2001:*
* zid waves at fisu
<gog> lol
<wxwisiasdf> hey so uh
<wxwisiasdf> why is the wiki having internall error her https://wiki.osdev.org/User:Superleaf1995
<bslsk05> ​wiki.osdev.org: Internal error - OSDev Wiki
<zid> General failure.
<zid> I guess I need to reboot
<heat> because it tried to load block with invalid type
<gog> uhh
<gog> does oled have real burn in or just temporary burn in
<gog> currently have ghosts on my screen
<zid> sick
<zid> is one named clyde
<kof123> in some cases core software like package managers aren't actually made for multi-core processors. is there a reason behind this? <-- my guess is age?
<Matt|home> i've only used one oled component for an electronics project and it broke after a couple hours of usage. dunno if it was a broken connector or whatever but they're unreliable (biased opinion)
<zid> my guess is the age of the textbook you read that from
<heat> how are you making a package manager for multicore software?
<heat> what does that have to do with anything?
<Matt|home> well, let me back that statement up with some context
<kof123> re: desktop env. that sounds like "theming" of toolkits as a related thing perhaps
<zid> why can't I ping my gateway? :(
<Matt|home> I noticed that with ubuntu's apt package manager it seems to take longer to install even small programs than it normally should on an 8-core CPU. I haven't actually looked to see how the resource allocation is, this is just a timing/visual observation
<Matt|home> but if it is because it's running as single-core i wanted to know why
<zid> because it's fuck all to do with how many cpus you have, it's about walking a shit load of dep trees from a bunch of files
<zid> then reading/writing those files
<gog> ok they're gone phew
<gog> i do not want to call lenovo support
<Matt|home> yeah.. so the bottleneck there should be my harddrive's read/write speeds im guessing, and even though it's a magnetic drive that's still what, 7200 RPM?
<Matt|home> i dunno maybe it's observation bias
<Matt|home> or i dunno what im talking about, both are equally likely
<wxwisiasdf> apt-fast tackles apt's timings by a considerable amount
<zid> why my ipv6 general failure though? :(
<wxwisiasdf> highest bottleneck is internet speed
\Test_User has quit [Quit: e]
<gog> e
bgs has quit [Remote host closed the connection]
<wxwisiasdf> what if someone made an OS where it's just excel charts
<wxwisiasdf> like no windw management, no gcc, no posix, just charts about the oil sparseness over a topographical area being shown in fancy 3D rotating forever
<zid> so like every movie?
<wxwisiasdf> no but like make it underwhemlingly boring
<wxwisiasdf> something silly like, "Oil per water (pints per acre)"
<zid> so like onyx?
<wxwisiasdf> onyx is good tho
<zid> I finally let wireshark update itself
<zid> it updated to a version that no longer works on my pc
<zid> that's what I get for doing updates
<CompanionCube> wxwisiasdf: https://arcan-fe.com/2021/04/12/introducing-pipeworld/ relevant
<bslsk05> ​arcan-fe.com: Introducing Pipeworld: Spreadsheet Dataflow Computing | Arcan
<heat> i have now built onyx under onyx
<heat> well, the kernel
<heat> sorry for the clickbait
\Test_User has joined #osdev
<CompanionCube> heat: woo self-hosting
<heat> not yet
\Test_User has quit [Client Quit]
\Test_User has joined #osdev
<heat> but yeah, wooo
<heat> still a lot needed to exercise
<heat> mostly deadlocks when multithreading
<zid> exercising your code will make it tired and not work correctly
<zid> never put your code under load
<wxwisiasdf> CompanionCube: what
<heat> building myself will be a great test
<wxwisiasdf> thanks for sharing
<wxwisiasdf> i love it
<CompanionCube> the same person also does a 3D VR desktop UI
<bslsk05> ​arcan-fe.com: Safespaces: An Open Source VR Desktop | Arcan
<CompanionCube> very weird but also fascinating
<heat> >onyx is good tho
<heat> <3
<heat> your COBOL thing is also good
<zid> >COBOL thing is also good
scoobydoo has quit [Ping timeout: 252 seconds]
scoobydoo has joined #osdev
<gog> i should learn COBOL and work maintaining ancient bank software that will never be updated
<gog> i could probably get a million a month doing that
<GeDaMo> You probably couldn't :P
<gog> a million in the fake money they use here
<gog> which translates to about $85k yearly
bauen1 has quit [Ping timeout: 268 seconds]
zid has quit []
<heat> 85k yearly is very good in a lot of places
GeDaMo has quit [Quit: Physics -> Chemistry -> Biology -> Intelligence -> ???]
<heat> mjg, remember that select is huge on my make -jN fgs? i think it's not blocking
<dh`> that would definitely explain poor performance
<heat> :D
<heat> i need to inspect what's going on with make and pipes
<heat> and god oh god why does it use select
<dh`> rampant fuckery
<dh`> mjg has been warring on bmake's token pipes for the past like two months
<dh`> (if you're using gmake, the code in gmake is different but no better)
[itchyjunk] has joined #osdev
<wxwisiasdf> COBOL is amazing
<wxwisiasdf> it was made by people in suits, for people in suits
<epony> Fortran
<CompanionCube> inb4 add RPG and CL for the full IBM Enterprise(tm) experience.
<bslsk05> ​en.wikipedia.org: History of programming languages - Wikipedia
<bslsk05> ​en.wikipedia.org: History of programming languages - Wikipedia
<mjg> dh`: gmake is less abusive at the same scale, but same fundamental problem applies :[
<kof123> i wouldn't look at excel i would look there: "multi-dimensional" https://en.wikipedia.org/wiki/Lotus_Improv
<bslsk05> ​en.wikipedia.org: Lotus Improv - Wikipedia
scoobydoo_ has joined #osdev
<wxwisiasdf> aha
<kof123> :D
<wxwisiasdf> lotus bad
<wxwisiasdf> excel good
<wxwisiasdf> must. obey. microsoft overlords
scoobydoo has quit [Ping timeout: 265 seconds]
scoobydoo_ is now known as scoobydoo
bauen1 has joined #osdev
alphajuliet has joined #osdev
dutch has quit [Quit: WeeChat 3.6]
zid has joined #osdev
SpikeHeron has joined #osdev
<zid> There, ipv6
freakazoid332 has quit [Ping timeout: 268 seconds]
<gog> hi zid
bauen1 has quit [Ping timeout: 264 seconds]
bauen1 has joined #osdev
justache is now known as justHaunted
<zid> hig oog
<zid> I hve pket los
<alphajuliet> zid:
<mjg> hey heat i have a special for you
<heat> helo
<mjg> you mentioned being against BIGNUM years of field expertZZZ
<heat> yes
dude12312414 has joined #osdev
<mjg> here is freebsd 9.3, that's predating any of my perf work in that project
<heat> in freebsd?
<mjg> yes
<mjg> ./openro1_processes -t 4: min:27033 max:27873 total:110249
<mjg> that's 110k
<heat> lmao
<mjg> and here is the same running up to date main kernel
<mjg> min:1208148 max:1217113 total:4846346
<mjg> almost 5 mln
<heat> no wonder linux has you guys beat my 200000000000000%
carbonfiber has joined #osdev
<heat> by*
<mjg> so over a 40x improvement at the measily 4 thread scale
<mjg> as you can see from your own measurements the rest is not particularly good either, is it
<heat> wait im confused
<wxwisiasdf> wine is an emulator, we lied to you
<heat> its super slow here
<mjg> yea
<dh`> it would be fun to check how ass slow os161 is, but I expect the benchmark won't run plus there's nothing to compare it too
<mjg> it was released in 2014 and did not perform for shit
<mjg> and if anything it took a lot of shit shoveling to beat it up to shape
<heat> no, i mean here as in "right now, linux"
<heat> i'm beating this 3x
<wxwisiasdf> what's OS161?
<heat> dh`'s teaching unix OS
<mjg> heat: what exactly are you doing
<heat> ./open1_processes -t 4
<mjg> ro?
<heat> no
<mjg> switch that first then
<heat> oh wow that makes a big difference
<heat> but still slow
<bslsk05> ​dpaste.com: dpaste: 9ZYB973AD
<mjg> plop it in plz kthx
<heat> that's no ro?
<mjg> char *testcase_description = "Separate file open/close read-only";
<heat> O_RDWR
<mjg> FUC
<mjg> bad file
<mjg> :D
<mjg> sorry
<mjg> 1 min
<bslsk05> ​people.freebsd.org: Index of /~mjg/.junk/will-it-scale/tests/
<mjg> so. the openro1 case should scale perfectly on linux
<mjg> but single-threaded it may be shafted by mitigations for cpu problems
<mjg> however, it is plausible your distro configured shit like selinux or apparamor or ther stuff which causes an artifical smp slowdown
<mjg> if you don't get a good scaling factor, check perf top
<mjg> well not perfectly, they still suffer ping pong due to struct cred refing
<mjg> but defo better than onyx :)
<heat> nope, this is arch
<mjg> perf top man
<heat> maybe these are indeed mitigations
<heat> i have a flamegraph
<heat> it looks stupid normal
<mjg> url plz
<mjg> so what are the numbers -t 1 -t 4
<bslsk05> ​gist.github.com: communist-unix-4.svg · GitHub
<mjg> fsnotify
<mjg> something is shafting you
<mjg> do you have some form of file monitor running?
<heat> vscode
<heat> but that's not looking at tmp
<carbonfiber> from the point-of-view of the OS, is there then any difference between USB memory-thumb-drives and USB HDDs and USB SSDs? Will a driver for USB memory-thumb-drives also work with USB HDDs without any modifications? Is the OS wanted to would it then be able to detect in any way whether the USB device is a memory-thumb-drive, HDD, or SSD?
<heat> 379992 t1, 1317347 t4, 1604510 t8
<heat> I have 8 threads
<carbonfiber> if the OS wanted to, would it*
<heat> this must be mitigations
<mjg> heat: see fsnotify -> dget_parent
<mjg> heat: something is using fsnotify there and that ofrces serialization on the /tmp dir
<mjg> heat: i would say mkdir /lul and patch the bench to use that
<mjg> maybe that will make it gtfo
<dh`> carbonfiber, what do you mean by a memory-thumb-drive?
<mjg> heat: well mkdir /lul and mount -t tmpfs tmpfs /lul
<bslsk05> ​www.westerndigital.com: SanDisk Ultra Fit USB 3.1 Flash Drive (16 GB to 512 GB) | Western Digital
<dh`> those are SSDs in the sense that they're flash
<dh`> I don't understand the distinction you're apparently intending
<heat> those are not SSDs in almost any way except flash
<carbonfiber> with SSD, I meant an SSD with a wire, and which probably has a more advanced controller and wear leveling and stuff like that.
<carbonfiber> or cable*
<dh`> well
<dh`> usb devices are not sata devices
<dh`> is that the question?
<carbonfiber> no
<carbonfiber> I don't know how to ask the question in any clearer way than I already have.
<heat> mjg, it gets a bit faster
<heat> but I still beat it ez in onyx
<heat> its probably mitigations punching it down into shit
<dh`> well
<dh`> there are storage devices
<mjg> heat: what's the -t 4 for linux vs onyx on thiso ne?
<dh`> they might be made out of flash or spinning iron or both or other things
<heat> mjg, im like 1.7x faster
dequbed has quit [Quit: bye!]
<dh`> they are attached to the computer via various kinds of interfaces
<dh`> one of those interfaces is USB Mass Storage
<mjg> heat: ye that's not legit :)
<heat> how is it not legit
<dh`> that generally involves a USB cable
<heat> 1 second for me is 1 second for them
<dh`> one of those interfaces is SATA, that generally involves a SATA cable
<dh`> and there are a pile of others especially if you count old legacy stuff
<mjg> heat: you don't do retpoline et al
<dh`> for the most part these interfaces have controllers, and there are various kinds of controllers but in general they operate on blocks of data and you don't see what the underlying storage medium is
<mjg> heat: want a fair test get a vm and build a kernel which does nothing
<mjg> heat: ... of that sort
<heat> well, i obviously meant "the results are legit"
<heat> im not saying im faster than lunix
<mjg> ok
<mjg> kind of a bummer though
<mjg> that one can't just cmpare
* mjg shakes fist
<heat> cat /proc/cpuinfo
<heat> bugs : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs itlb_multihit srbds mmio_stale_data retbleed
<heat> i see why... lmao
<mjg> naaa i'm sure it changes nothing!
<dh`> swapgs is a bug? :-)
<heat> of course
<heat> have you seen the thing?
<dh`> yes
<dh`> have you seen 32-bit arm's trap handling?
<heat> something something heat angry rant something something x86 is a travesty
<mjg> heat: go the old unix geezer route and claim victory
dequbed has joined #osdev
<carbonfiber> dh`: thanks for the effort. but that doesn't really answer the question I asked.
<mjg> heat: i mean data is right there!
<dh`> carbonfiber: I have no idea what your question is
<dh`> so I am throwing information around in the hopes that some of it might be related
<carbonfiber> from the point-of-view of the OS, is there then any difference between USB memory-thumb-drives and USB HDDs and USB SSDs? Will a driver for USB memory-thumb-drives also work with USB HDDs without any modifications? If the OS wanted to would it then be able to detect in any way whether the USB device is a memory-thumb-drive, HDD, or SSD?
<dh`> if the question is whether you can detect what the storage medium is when you plug in a usb mass storage device, the answer is AFAIK no
<epony> aarch64 is like x86 in all travesty plus a bit more travestism in it including in the instruction sets and modes and what not, and more bugs too
<dh`> they do have device ids and you could theoretically try to assemble a table
<dh`> but there's also no reason to
<epony> think of arm64 as a 20 year delayed amd64 with worse performance on same level comparisons
<heat> what
<heat> are you high
<heat> arm64 is 10x cleaner than x86_64
<heat> >worse performance on same level comparisons
<heat> lie?
<epony> a-ha, but also you do not care, there are compilers
<heat> > more bugs too
<heat> lie 3
<epony> so your mom use arm64 cause she cares about your progress with computers ;-)
<heat> wtf are you on about
<epony> there is a reddit reading competition about the excellence of the arm architecture.. but nobody cares about that.. (in a marvin the depressed android voice0
<heat> i understand jackshit of what you're saying
<heat> but good for you pal
<heat> or sorry that happened
<epony> got any proof of the superiority of one architecture compared to another?
<epony> cause you can't find any desktop running arm64 or risc in general since the 90ies (need more proof?)
<heat> the ISA itself is 20x fucking cleaner, and apple 10-0's all kinds of CPUs drawing the same amount of power
<heat> did I mention it draws 20x less than whatever intel or amd put out?
<epony> that's as clean as it can get.. same thing, only on handheld and microcontrollers with 20 year lag
<qookie> carbonfiber: afaik they all should support the base usb bulk-only mass storage protocol, but for higher-speed devices there's some other faster protocol (which you pick by picking the appropriate interface)
<CompanionCube> has desktop apple silicon come out yet, that'd be a great counterexample
<epony> so clean, like with the same transient execution vulnerabilities and everything
<epony> jokes online
<gog> all computers suck
<epony> only the stupid marketing blows ;-)
<gog> y'all c# is rotting my brain i just tried to return an anonymous object in c++
<heat> have you looked at both? or are you talking out of your ass?
<gog> mvc razor not even once
<epony> what's there to look at, there are no such CPUs in popular hardware you can buy that are usable and long term reliable
<epony> it's a couple of unstable iterations and much hype about the "stability" and 'cleanliness' but it's failed market realisation outside embedded SoC small computing and power saving units
<heat> have you been alive these last 2 years?
<epony> are you picking these smart questions from a social chat list of funny questions ;-)
<heat> it's a legit question
<heat> open one at that
<gog> embedded soc and small computing???
<gog> what is apple silicon then
<heat> apparently inexistent
<gog> apple has made some questionable decisions in the past but changing cpu architecture was generally one that stood the test of time
<gog> and they've done that a LOT
<heat> the m1 is so superior even torvalds switched lmao
<gog> when it comes to cpu they don't sleep on which way the wind is blowing
<carbonfiber> qookie: ok. what about the SCSI part? do they all use the "SCSI transparent command set" and the SCSI "SBC" PDT? or is there some kind of sub-sub-type in SCSI that identifies that one device is using a rotating disk and another one uses flash memory?
<mjg> ye i keep hearing that cpu rocks
<gog> they dropped PPC when IBM couldn't deliver performance per watt anymore
<heat> intel and amd only pump the power up when they sense trouble
<gog> they've done the same with Intel for the same reason
<epony> rocks, but it's only found in one 5% market vendor
<carbonfiber> (ignoring USB Attached SCSI for now).
<heat> amd is fucking cleaning house
<gog> market share isn't a measure of quality
<heat> sorry, arm
<clever> carbonfiber: if you run `modprobe usbmon` and run `wireshark, then you can sniff any usb port on your system
<gog> fuck you for making me defend apple
<qookie> carbonfiber: usb uas is the second one i was talking about, forgot it's name
<gog> i'm gonna go tak ea hot shower
<clever> carbonfiber: it has full protocol decode for hid/msd and more, so you can see exactly what messages are being exchanged and what the bytes mean
<epony> nothing to defend, it's just a logo and a couple of ported software from other systems
<heat> and great sillicon that doesn't exist
<heat> (and good products, and the best unix desktop experience?)
<epony> hahaha
<gog> x86 is on its way out probably and that's fine
<gog> it'll take a decade probably
<heat> i'm talking to you as my kde is giving me an epileptic seizure
<epony> from the 6502 epoch onwards.. Apple has not made a decent compatible computer for 40 years
<carbonfiber> clever: thanks for the suggestion. I will do that.
<heat> lmao
<heat> great troll
<epony> all the wrong cables, interfaces, connectors, CPU arch choices and the failed products that last a couple of years and obsoleted on failed line endings, software and portability faults
<epony> heat, you're just uneducated
<gog> yeah, apple does all of those things
<epony> but keep supporting the fake marketing claims of Arm* architecture superiority and you might get cheaper better Apple computers next year ;-)
<gog> they're a bad company that generally makes poor decisions that harm the market in general. but changing CPU arches isn't something they just do for grift
<heat> you're capable of looking at the sky and saying it's red
<heat> i wish I had that skill
<epony> you are that skill
<gog> they do it because their suppliers can't deliver to their needs
<heat> no I am heat
<heat> which is also what intel and amd are these days
<heat> lots of heat
<epony> you mean users of TSMC and GlobalFoundries produce
<epony> muh arch is better than yours ;-) alright, that's a great RISC success comeback after 30 years of no hear
<heat> ah yes, you're stanning intell
<epony> it's just not suitable for general purpose computing due to inefficiencies in the arch and the sotware
<epony> it's for specialised use and embeded computing
<heat> sure thing sweetie
<gog> i'm stanning Power10
<epony> and it's used mostly to create lock in and proprietary platforms
<heat> gog, i stan the 486
<heat> the ideal cpu
<gog> yes
<heat> prior to the fuckups
<heat> old enough not to fuck up, new enough to invlpg
<heat> holy fuckingggg shitttttttt
<heat> a 20w cpu doesn't run on a supercomputer??? whahthattat'??
<gog> why is market share a more objective measurement of superiority in this case?
<heat> macOS is the only UNIX certified of {macOS, FreeBSD, NetBSD, OpenBSD, Linux}
<mjg> heat: hey mofo, if i shipped you with a linux config which has all mitigations and hardening disabled
<gog> the graph only goes to 2020
<mjg> heat: would you build that in a vm
<heat> no
<heat> 2much effort
<epony> you see the green with the black star, that's RISC to you
<heat> ok sweetie
<mjg> someone is in a bad mood
<mjg> lemme cheer you up
<heat> risc poopy argh risc vs cisc i love living in the 90s, they're great
<gog> we all know that intel does not have a superior product. they have a product that's produced at scales that make it really cheap to make supercomputers with
<mjg> sunos vm rewrite paper
<mjg> > Further, when one considers that we replaced a mature implementation with one which has not been subjected to several years of tuning, getting back to current performance levels appeared to be an ambitious goal, something later experience has proven correct.
<gog> they weren't even on that map until 2004
<epony> show a server made with Apple silicon ;-)
<mjg> :D
<heat> :D
<heat> maple tree moment
<epony> or.. show a gaming computer with Apple silicon?
<heat> you're repetitive
<heat> <heat> a 20w cpu doesn't run on a supercomputer??? whahthattat'??
<epony> can you show a workstation with Apple silicon..
<heat> <heat> a 20w cpu doesn't run on a workstation??? whahthattat'??
<gog> there's going to be one later this year or early next year?
<gog> i need to stop
<gog> i feel sick
<heat> yeah probs
<heat> same my dudette
<alphajuliet> heat you are doing some crazy shit huh ?
<alphajuliet> i always considered you quiet the newbie here
<gog> gotta wtach some louis rossman
<heat> i have 0 apple devices and defending them is making me die slowly
<dh`> I hear emacs is a good text editor
<heat> i like GNU nano
<gog> eat my shit and hair and use vim
<mjg> alphajuliet: heat is in on the forefront of beating BSDs in terms of performance
<epony> you're defending Aarch/Arm64 remember ;-)
<mjg> alphajuliet: with his custom os
<epony> Apple has nothing to do with the arch, it's just a consumer of Arm designs
<mjg> so... waste of time within waste of time
<alphajuliet> mjg: im standing corrected then
<alphajuliet> mjg: so i can join him to the high council of #osdev ?
<heat> i'll let you know my 1 user Onyx has more users than FreeBSD
<alphajuliet> heat i want to use your os
<heat> gog, can you ship me a bit of ur shit and hair thanks
<heat> i use vim i promise
<epony> HeatOS will be significantly delayed due to inability to be ported on processors that live only 2 years between product changes
<mjg> there is quiz before you can do it
<gog> :P
<mjg> alphajuliet: 1. who is theo?
<alphajuliet> mjg: theodore bagwell
<heat> theodore roosevelt, founder of openbsd
<gog> theo is the second most annoying calgarian i've ever heard of
<epony> maybe you can one up the defunct TempleOS with a bit of a porting of Redox to the Raspberry arm-boards
<alphajuliet> heat now give me the link to your os
<alphajuliet> as i passed the quiz successfully
<alphajuliet> i want to find exploits before it
<alphajuliet> getting too big
<heat> epony, listen qtpi, what's the booting environment in the reset vector?
<epony> but as far as it goes, you're succeeding very well in convincing me Arm64 is superior to.. MIPS
<alphajuliet> but you have nothing to scared as i all talk
<alphajuliet> zid: rigt ?
<alphajuliet> t
<heat> this thing of maintaing x86 firmware really gets me to question if I know x86 that well
<epony> oh, let me remind you, Raspberry boards do not have a PCI slot, and.. need a DOS bootloader
<epony> so clean, it stinks like shrinkwrapped socks
<gog> DOS?
<heat> naw
<epony> uDOS
<heat> you're getting ignored now lmao
<epony> you getting a clean 20 year speed up boost by Arm
<epony> party like it's 2002
<heat> write me a reset vector implementation and i'll unignore you, world-renowed x86 expert
<epony> I'll write you a couple of IRC lines of text.
<heat> anyway, as I was saying
<heat> microkernels are bad monolithic is the only way suck my shit you fucking idiot tannenbaum
<heat> vim good emacs bad
<heat> CISC best RISC bad for stupid heads
<epony> you mean you need a stack VM to run shit on a very clean and fine otherwise useless arch ;-)
<heat> am I missing any controversial topic?
<epony> add JVM to the mix of cleanliness
<epony> sprinke a bit of missing internal periphery buses
<heat> kqueue good design epoll stupid monkey brained design for stupids
<heat> /dev/poll best design
<moon-child> wer io_uring
<heat> what is io_uring?
<heat> this is the 90s
<epony> and compare the low standard adoption and portability, and you'll see how clean it has shot itself in both feet with one swift incompatible design
<mjg> ye fuck off with stuff which performs
<moon-child> oh sorry wrong century
<mjg> we gotta iterate on bad interfaces
<heat> is that why you guys want doors?
<epony> make me an office program for the Raspi
<heat> i dont want to do it, but i will do it
<mjg> heat: that much would be much appreciated
<heat> can i write a paper on that?
<heat> "Improving FreeBSD by adding a doorway into the future"
<gog> improving freebsd by throwing your computer off the nearest cliff
<heat> improving your computer by not using freebsd
<moon-child> :<
<epony> somebody needs a self-comforting kernel recompile ;-)
<gog> freebsd is good actually
<gog> don't @ me
<epony> get your lists of drivers exclusion to get it to work better on the arm (which has no periphery, it's all in the SoC)
<heat> @gog
<heat> i only use netbsd because i want networking
<mjg> if you want a paper you need more bullshit
<Matt|home> one thing i find pretty awesome is that the playstation uses freebsd actually
alphajuliet has quit [Ping timeout: 264 seconds]
<Matt|home> like an actual full scale OS installation as opposed to whatever the hell xbox uses
<heat> yeah they used a couple of freebsd CVEs to pwn the PS4 and 5
<heat> like a setsockopt race condition that allowed them root :v
<epony> the most awesome thing is never having to worry about Arm* portability ;-)
<epony> just Risc-V and enjoy LieF
<epony> think how clean it is, how lovely the ISA makes your binaries, how fantastic the porting effort and how fast it delivers new hardware..
<heat> i think xbox also does something similarish
<epony> and try to see if your vendor has any batches sent to a Chinese competitor to TSMC (which was a nice company prior to the Taiwan invastion)
<heat> an important bit is that PS's freebsd is at least a good bit modified
<epony> I heard you like UMC.
<heat> they have some extra 40 or so syscalls for instance
<epony> and 90nm processes ;-)
<epony> you always do the syscalls regardless kernel or userspace
<epony> unless you lack the periphery like on an Arm SoC
<bslsk05> ​en.wikipedia.org: Fabless manufacturing - Wikipedia
<bslsk05> ​'Accelerating AI and HPC with Wafer-Scale Compute from Cerebras Systems' by Tech Field Day (00:22:00)
<epony> you know you can technically watch video on a Rpi
<epony> it has a video graphics chip integrated in the SoC.. the only thing it can do is show graphics and do low throughput networking or storage but not at the same time ;-)
Ikkepop has joined #osdev
Coldberg has quit [Ping timeout: 268 seconds]
scoobydoo_ has joined #osdev
scoobydoo has quit [Ping timeout: 260 seconds]
scoobydoo_ is now known as scoobydoo
scoobydoo_ has joined #osdev
scoobydoo has quit [Ping timeout: 265 seconds]
scoobydoo_ is now known as scoobydoo
nyah has quit [Ping timeout: 265 seconds]
<epony> thus said, I used a 2.5W x86 1C2T 32-bit CPU system from 2008 without transient execution vulnerabilities on an open hardware standard PC-like system to delivery you the above detail runnin an OpenBSD operating system snapshot from today using standard lightweight applications
<epony> heat, you can compete with that ^
Matt|home has quit [Quit: Leaving]