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