<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>
GOG BE LIKE
<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
<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
<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
<heat>
THE GOVERNMENT CRANOR AND NETBSD FOUNDATION IS HIDING THINGS FROM YOU
<heat>
WAKE UP SHEEPLE
<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
<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>
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
<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>
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.
<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
<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
<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]
<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?
<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
<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>
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
<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
<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>
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
<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
<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