<bl4ckb0ne>
sounds like evangelion with less daddy issues
* mrvn
wants to see Machete in space.
<milesrout>
what is the current state of RISC-V from an osdev perspective? is there any kind of common interface to hardware so you can get up and started, or would you basically need to write for one specific RISC-V board?
<heat>
the FDT does the job
<heat>
but no, no "common interface"
<heat>
as one would expect, ISA is dead and not coming back
dza has quit [Quit: Ping timeout (120 seconds)]
dza has joined #osdev
heat has quit [Quit: Leaving]
<moon-child>
wer pc 2
<zid>
Sony made it, it's called the PS/2.
<zid>
I like how everything about that is wrong but also right.
heat has joined #osdev
<milesrout>
ah i see there's like a virtual generic board in qemu called 'virt' which is a good starting point, then if you want to run on real hardware you need to write support for specific boards individually?
<Mutabah>
You need to support the hardware on the board
<heat>
milesrout, no.
<Mutabah>
Like ARM, RISCV has semi-standardized on using the FDT to communicate hardware layout
<heat>
in general boards should all be similarish
<heat>
probably may change on some details like the mmc controller, rtc, etc
<milesrout>
oh ok that's good
<heat>
but the basics are all there, and the device tree lets you know exactly what things this particular platform has, what drivers its compatible with, where these "things" are, where memory is, etc
<Mutabah>
it also has (iirc) SBI - Similar to UEFI's runtime services, except also handles things like SMP bringup
<heat>
yes, but better than runtime services, and also worse
elastic_dog has quit [Killed (zinc.libera.chat (Nickname regained by services))]
<bslsk05>
github.com: Onyx/kernel/arch/riscv64 at master · heatd/Onyx · GitHub
gxt has quit [Ping timeout: 255 seconds]
<heat>
it may fail to boot if you give it something it doesn't know (brand new interrupt controller for instance), or it may just fail to access the block device you want if you have a new mmc, or it may fail to get the time if you have an unknown rtc, etc
SerHack has joined #osdev
gxt has joined #osdev
<milesrout>
interesting
Iris_Persephone has quit [Ping timeout: 260 seconds]
divine is now known as Guest693
divine_ is now known as divine
Iris_Persephone has joined #osdev
sebonirc has quit [Remote host closed the connection]
sebonirc has joined #osdev
mlombard has quit [Ping timeout: 255 seconds]
Iris_Persephone has quit [Ping timeout: 248 seconds]
mctpyt has quit [Remote host closed the connection]
zaquest has quit [Ping timeout: 255 seconds]
joe9 has quit [Quit: leaving]
Turn_Left has joined #osdev
Left_Turn has quit [Ping timeout: 264 seconds]
heat has quit [Ping timeout: 246 seconds]
[itchyjunk] has quit [Ping timeout: 255 seconds]
[itchyjunk] has joined #osdev
Iris_Persephone has joined #osdev
Arthuria has joined #osdev
Arthuria has quit [Remote host closed the connection]
xenos1984 has quit [Read error: Connection reset by peer]
<bslsk05>
github.com: mem.c: Fix incorrect type in page_table() · zid/bootstrap@7127698 · GitHub
<klange>
c'mon zid, this is what things like uintptr_t and size_t are for
<zid>
no they're not?
<zid>
uintptr_t maybe
<zid>
I just fucked up and figured u32 would be fine for the input args, but that needs you to cast everything
<zid>
easiest fix is just to promote everything
<klange>
absolutely
<zid>
Like, those values are all <0x1FF, but because shift operator isn't psychic you need to (u64)p3<<30
<sham1>
> u32
<zid>
compiler doesn't catch it because the shift amounts are <32, and bounded to 1FF :(
<zid>
so there's no overflows or anything it can moan about
xenos1984 has quit [Quit: Leaving.]
Iris_Persephone has quit [Ping timeout: 255 seconds]
<moon-child>
obviously you should use u128 for everything
<moon-child>
futureproofing
<zid>
I'm surprised nobody told me to use rust instead ;)
Iris_Persephone has joined #osdev
<moon-child>
I mean, the fact that you named your type 'u32' already shows your rust envy
<zid>
uint32_t is a dumb type name, but I presume they did it because they didn't want to conflict with all the sane people who used u32
<zid>
which is very on-brand for the C committee
<gorgonical>
my advisor couldn't be less rust-inclined and we've used u64 etc forever
<zid>
"Let's do what people already standardized on, but worse"
<zid>
"20 years later"
<zid>
"maybe"
Arthuria has quit [Remote host closed the connection]
<sham1>
Well you can't exactly standardise u8 and such as is, because how would you deal with the least and fast variants
<geist>
zid: use rust, dummy
<moon-child>
u8_least
<moon-child>
u8_fast
<moon-child>
ez
<geist>
also u8 is somewhat ambigous
<geist>
i used to know a code base that had u1, u2, u4, u8
Iris_Persephone has quit [Read error: Connection reset by peer]
<gorgonical>
How do you even define a u1?
Arthuria has joined #osdev
<gorgonical>
Must be compiler-specific, right? C doesn't provide anything less than char, which should be byte-sized?
<Mutabah>
I think `u1` would be a `uint8_t`
<moon-child>
_ExtInt(1)
<Mutabah>
I.e. a 1 byte integer
<moon-child>
or is it _BitInt? Whatever they called it
<moon-child>
geist: I do that
Arthuria has quit [Remote host closed the connection]
<gorgonical>
Mutabah: ?? Doesn't u32 mean a unsigned 32-*bit_ integer?
<gorgonical>
I can't type but you know what I mean
<Mutabah>
gorgonical: In most conventions, yes.
<moon-child>
when I care, I find it more useful to know an integer's size in bytes, rather than bits, because what I care about is layout
<Mutabah>
but in the example geist referenced, u4 was probably the 32-bit (4 byte) integer
<sham1>
Yeah, _BitInt(1) would be u1
<sham1>
At least I hope it's unsigned
<gorgonical>
You can't be serious. uN meaning N bytes?
Iris_Persephone has joined #osdev
<moon-child>
what's wrong with it?
<gorgonical>
I'm gonna have to pour another glass of wine, that's preposterous
<sham1>
It'd be strange if it wasn't, but that hasn't stopped wg14 before
<Mutabah>
gorgonical: That is my interpretation, yes.
<zid>
Right I got my keyboard irq anyway
<gorgonical>
moon-child: That's not what my manpages say and so I cannot accept it as canonical
<zid>
I take it it won't give me another until I actually read the keyboard
<zid>
gog can teach me how to do that
<sham1>
Yeah, the buffer is full
<moon-child>
gorgonical: which manpage discusses 'u1'?
<zid>
Wikipedia describes u2 if you want
<zid>
It's an irish band that kills african children
<gorgonical>
moon-child: exactly my point
<moon-child>
absence of evidence =/= evidence of absence
<sham1>
Clearly we need a Wikipedia => man-page conversion
<gorgonical>
moon-child: what I mean is that the other ones analogous to the uintN_t types are conventionally known
<gorgonical>
holy GNU and whatnot
<sham1>
Would make it significantly faster as well as making searching things within articles easier. Oh and it wouldn't have that stupid new Wikipedia layout
<gorgonical>
I wish the info pages weren't just glorified manpages
<Iris_Persephone>
god I hate that new layout
<Iris_Persephone>
it's so ugly, there's so much dead space in the margins too
<gorgonical>
Iris_Persephone: I immediately installed an add-on that helps redirect you to the old one
<zid>
everyone hates it it seems
<Iris_Persephone>
hurts to read
<sham1>
gorgonical: no but they have hyperlinks! That totally makes them better
<Iris_Persephone>
if you have a wikipedia account you can set your preferred theme there
<sham1>
And yeah, the new layout is a clear case of modern web design. It's sadly a terminal condition 😔
<gorgonical>
Iris_Persephone: something about jimmy knowing that I dislike it bothers me
<sham1>
Jimmy Hendrix?
<gorgonical>
wales
<zid>
hendris is jimmi
<zid>
jimi
<Iris_Persephone>
who looked at this and thought it was a good idea
<sham1>
T'was the pun
<zid>
My dream (which shall go unfulfilled) is that we go back to webpages that don't reorganize themselves when you resize them
<zid>
if they contain reference information, at least
<zid>
you know what's fun? screenshotting fucking websites and resizing mspaint instead, because apparently browsers aren't allowed to do that anymore :P
<zid>
hope it's not a video!
<sham1>
Pixel layouting would also be bad though. My personal wish is that websites didn't have as much negative space. Our screens are adaptable
<zid>
bad why, I'm talking about reference data
<zid>
like if they had linked a .txt
<zid>
they instead put it inline now, and make the damn page reflow if I resize
<zid>
so I have to screenshot it
<gorgonical>
sham1: but there is actually something to column limits
<gorgonical>
that's the whole idea behind dynamic layouts
<zid>
cus they've certainly disabled copy paste with a huge transparent overlay too :P
<sham1>
Well for that I wouldn't even do websites but instead APIs that give the reference information in a standard and structured manner, so I can build my own viewer in Emacs
<zid>
9/10 I need it for like, 5 minutes
<zid>
or I just want to shove a video player on a website off into a corner
<zid>
so I can watch it while I do a thing
<gorgonical>
I have stopped using an independent IRC program these days and just use emacs, sham1
<zid>
nope, can't resize the window, that just makes the video tiny
<gorgonical>
zid: this is the only reason I have mpv and yt-dl installed
<Iris_Persephone>
honestly all I want is a wikia page that doesn't have a video that autoplays and sticks to your header that you can't remove and takes up somewhere between a third and half of your screen real-estate
<zid>
never seen that
<zid>
maybe it's a regional thing
<gorgonical>
wikia is extremely toxic
<gorgonical>
I agree
<Iris_Persephone>
why tf does it keep eating other independent wikis
<gorgonical>
Same reason all fora succumb to reddit in the end
<zid>
My main wiki issues are that the 'free' wiki hosts are all fuck-awful
<Iris_Persephone>
what about wikidot
<mjg>
lol @ reddit
<zid>
so lots of games' info dumps are on horrendous advert hells
<sham1>
You get what you pay for
<Iris_Persephone>
zid: literally this
<zid>
hosting is nearly free in this reality
<zid>
like, I could put this shit on a subreddit and custom theme it and have them host it and nobody would care :D
<marshmallow>
I have a couple of doubts, does the kernel ever send a signal to the current process when the kernel needs to notify a process (e.g., page fault)?
<marshmallow>
for instance, does it ever do this by using `kill_pid`?
nyah has joined #osdev
bauen1 has joined #osdev
elderK has quit [Quit: Connection closed for inactivity]
GeDaMo has joined #osdev
bauen1 has quit [Ping timeout: 246 seconds]
[itchyjunk] has joined #osdev
[itchyjunk] has quit [Remote host closed the connection]
bgs has quit [Remote host closed the connection]
fedorafan has joined #osdev
gxt has quit [Ping timeout: 255 seconds]
<klange>
finally got around to fixing two bugs in my menu library, and one was a silly one-liner...
gxt has joined #osdev
<klange>
Keyboard navigation now skips separators, and a very silly old bug where a submenu-type menu entry would remain highlighted if you used the keyboard to focus out of the menu and then focus another menu entry (was checking that the "current" child menu was the one associated with the menu entry to keep it highlighted when it's open, but then wasn't checking that the "current" child *was* open)
bauen1 has joined #osdev
vdamewood has joined #osdev
slidercrank has quit [Ping timeout: 248 seconds]
heat has joined #osdev
<heat>
marshmallow, yes
<heat>
how else would SIGSEGV get sent?
<sham1>
Or SIGKILL
Arthuria has joined #osdev
Arthuria has quit [Remote host closed the connection]
m3a has quit [Ping timeout: 252 seconds]
Arthuria has joined #osdev
* Ermine
looks at heat semigroup
<mrvn>
marshmallow: linux has a SEGV signal you can install a handler for
<sham1>
Why suddenly a semigroup?
<mrvn>
marshmallow: there is also eventfd and signalfd. I would except the function dealing with sending signals to have signal in it's name.
<Ermine>
sham1: because transition operators of Markov processes satisfy the semigroup property
<Ermine>
heat semigroup consists of transitional operators of Brownian motion. They are closely tied to heat equation solutions, hence the name
<marshmallow>
heat: is the same APIs used for both userspace and kernelspace?
<marshmallow>
(APIs for signals)
<heat>
obviously not
<heat>
the kernel implements the userspace POSIX API
<heat>
the internal signal logic you use to implement the userspace signals API is also useful for sending signals from the kernel
<heat>
i.e kill(pid_t pid, int sig) would use a kernel_send_signal(struct process *proc, int signal, siginfo_t *siginfo). if you want to send a signal to a specific process, there's little point in doing a pid -> process lookup if you can already send it directly with kernel_send_signal
<marshmallow>
so sending a signal from userspace to another userspace program always require kernel intervention?
<heat>
yes
elastic_dog has quit [Quit: elastic_dog]
<marshmallow>
but isn't `kill_pid` to some extent the equivalent in-userspace of `kill`?
elastic_dog has joined #osdev
<heat>
hrm? kill is the in-userspace equivalent of kill_pid. ofc you could and maybe want to have a kernel-side kill_pid (to implement kill and for other kernel usage)
bnchs has joined #osdev
<bnchs>
hi
Left_Turn has joined #osdev
Turn_Left has quit [Ping timeout: 246 seconds]
<heat>
hi
<bnchs>
hi heat
<heat>
warmth
<gog>
hi bnchs
<gog>
hi heat
<bnchs>
hi gog
<bnchs>
mew
* gog
pets bnchs
* bnchs
purrs
_73 has left #osdev [ERC 5.4 (IRC client for GNU Emacs 28.2)]
<mjg>
yo mrvn geist moon-child so not "scientific", but i ran a full system build with ht vs no ht (disabled in bios)
<heat>
omg omg omg its solaris-man
<mjg>
-j 104: 430986.12s user 35029.09s system 10178% cpu 1:16:18.22 total
<mjg>
-j 52: 245655.43s user 17328.20s system 5124% cpu 1:25:31.58 total
<heat>
what does this say, apart from "we live in a society"
<mjg>
important notes: 1. clang is doing stupid shit depending on found cpu count, i did not patch it yet. 2. there are bottlenecks which only get worse when you jump from 52 to 104. i have experimental patches for them from months back, will need to rebase and try again
<mjg>
heat: it says enabling ht for this workload shaves a little bit of time in total
<mjg>
it's not a microbench
<heat>
yeah
<heat>
also your clang doing stupid shit problem is either LTO or lld
<mjg>
76-ish vs 85-ish minutes
<mjg>
no
<mjg>
i mean not lto
<mjg>
it is their "fuckin' let's spawn as many threads as it gets bro'
<heat>
i don't think it does any threading in other contexts?
<mjg>
in lld indeed
* gog
spawns threads infinitely
<mjg>
gog: fuck you then!
<heat>
mjg, yeah, there's an option for that iirc
<mjg>
you can manually control thread count, which i can do for the test here
<mjg>
but which does not solve the general problem
<mjg>
i'll be writing to them about it
<mjg>
their discussionw hich led to enablement of threading was quite frankly embarassing
<heat>
the superior alternative would be to use the make job server
<mjg>
and they were even told that someone may run lld on a non-laptop and that willl result in useless threads
<mjg>
...w hich got ignored
<heat>
just like gcc can for LTO, and clang too(?)
<marshmallow>
apologize if it's a stupid question, but could processor B access cache of processor A?
unimplemented has joined #osdev
<heat>
no
<marshmallow>
never?
<heat>
not L1 at least
<mjg>
see, i think the terms are a little fuzzy in the question
<marshmallow>
so there is simply no need of locking the bus for L1 cache?
<mjg>
have you seen pictures how cpus look like inside
<marshmallow>
if you refer to every processor has its own cache, yes
<heat>
there is a need of locking the bus
<heat>
else you could have two cores changing the same cache line at the same time
<gog>
i tried writing a bus driver but he got a restraining order against me
<mjg>
lemme find some pictures
<heat>
gog, hehehehehehehehe
<marshmallow>
heat: wait, sorry, but aren't the cache lines different per-processor cache?
<bslsk05>
lwn.net: The search for the correct amount of split-lock misery [LWN.net]
<mjg>
haha
<mjg>
> It modified the warn mode to punish processes doing split locks without actually killing them. Instead, detection of a split lock would lead to a 10ms delay, then serialization via a semaphore.
<mjg>
i had an idea like that, but for a different problem
<mjg>
i shoudl implement that for freebsd
<mjg>
or perhaps you would be interested?
<heat>
that's an idea
<marshmallow>
heat: does AArch64 achieve something similar out of curiosity?
<\Test_User>
make it undefined behavior, and return a random value/write a random value when used? would be more fun :P
<heat>
but really I need to figure out a vscode dev environment on remote freebsd because fucking hell I can't use vim for shit
<heat>
marshmallow, no clue
<heat>
mjg, is desktop fbsd tolerable on virtio-gpu or something?
<heat>
i'm not vim-skilled enough to be able to go through a file/multiple files efficiently
<heat>
and the man pages lie
bnchs has quit [Read error: Connection reset by peer]
<heat>
and of course nano, despite the meme, is not really usable for this is it
<mjg>
you can do it on your linux desktop
<mjg>
and keep git pushing to the vm
<heat>
marshmallow, no: (quoting a rando in stack overflow, there's probably a better source on the arm arm) "The exclusive instructions will always fault if the address is not aligned to the access size"
alpha2023 has joined #osdev
<heat>
this means you will naturally never hit a split lock on ARM64 as it automatically faults
<heat>
if you have i.e a 64-byte cache line size, any aligned operation with alignment = size and size <= 64 will not reach the next cache line
<heat>
mjg, yeah, that's an idea
<mjg>
heat: KERNFAST=1 is your friend
<mjg>
by default the build is *not* incremental
<heat>
yep, you mentioned that
<heat>
something something insane build system
<zid>
3
<mjg>
want insane, check solaris. for real
<mjg>
they have a script named nightly.sh
<mjg>
it is doing TONS of very opaque work
<mjg>
figuring out how to do a fucking incremental kernel build is quite a challenge
<heat>
i do like that netbsd is super easy to build
<heat>
on cross compilation and stuff
<heat>
FreeBSD? lol
<mjg>
i concede build.sh is ok when it works
unimplemented has quit [Quit: fall into blackhole]
<mjg>
.. but it foten does not
<mjg>
and is turob single-threaded all over, so it takes way more time than it should
<mjg>
but it probably beats having to figure out what to do
<mjg>
fwiw freebsd on freebsd cross compiles no problem at least
<heat>
yeah I mean freebsd on linux or mac
<heat>
it's surprising it doesn't work considering how many freebsd devs use linux or macOS
<mjg>
it does work, but i don't know the steps
<mjg>
there are people who literally build it like that at work
mahk has quit [Remote host closed the connection]
gog has joined #osdev
<heat>
mjg, btw you killed itanium, congrats
<heat>
you are literally $pick_20th_century_dictator
<bslsk05>
Note by : "Remember, when the internet gets disbanded, don't blame Hasbro Interactive. They had nothing to do with it.  From the back of my Master of Orion II disc." https://icosahedron.website/system/media_attachments/files/109/867/104/638/976/321/original/230899fc38ee49e8.jpeg [A warning: "In using this CD-ROM, you may choose to use the Internet. You acknowledge that Hasbro Interactive is not responsible for the Internet or whether it should cont
<gog>
we're well on our way to getting taken over by governments and disbanded
<gog>
acclerate disbanding
<zid>
stop having the internet, be open
<zid>
close, the internet
<mjg>
heat: i'm spolsky. joel spolsky.
<mjg>
some people sell crack cocaine, meth
<mjg>
i sell a shitty qa platform
<gog>
i'm gog i slap a keyboard and get paid for the results of said key-slapping
<SerHack>
Curious, I get a sort of infinite interrupts (from 0xff... to 0xd), does anyone have an hint of what I touched?
<heat>
SerHack, wdym?
<heat>
mjg, btw how does the BSD dcache handle ephemeral entries (like nfs or procfs or sysfs or devfs, etc)?
<SerHack>
I enabled -d int option with qemu. As soon as I enable interrupts, qemu fires a lot of 0xd interrupts
<mjg>
heat: devfs does not use the namecache
<mjg>
heat: :s
<heat>
SerHack, so something is buggy and triggering a GPF
<mjg>
heat: nfs has entries which expire with other caches
<SerHack>
The error code seems to be related to IDT with number 12
<heat>
SerHack, I would recommend you look at the first exception and start from there
<SerHack>
Okay, then I need to halt as soon as I receive an interrupt, thanks for the suggestion
<heat>
SerHack, no?
janemba has quit [Ping timeout: 248 seconds]
<heat>
what if your interrupt routine is buggy? you just hide the bug!
<heat>
mjg, hrm. i guess BSD can work like that? since you don't require always present dcache entries like linux
<gog>
that was working for me
janemba has joined #osdev
<gog>
the bug was safe and snug hidden in a macro
<SerHack>
mh, good point, heat
<SerHack>
well, I find a way
<gog>
until i rudely barged into its house and sprayed pesticide in there
<heat>
SerHack, run, see a bunch of faults, ctrl+c, look at the first one
<mjg>
heat: right
<heat>
SerHack, redirect the log to a file if you need to
<mjg>
heat: the mandatory namez are a linux thing
<mjg>
heat: the REAL UNIX way is purely optional caching
<mjg>
heat: ... note it sucks dick
<heat>
mjg, I think linux dcache has a is_valid() that filesystems implement
<heat>
and proc/sys will just say "not valid" and force you to look everything up again? can't remember if that is actually the case
<mjg>
i don't know what they do there
<heat>
ah no, they actually do normal revalidation
<heat>
good to know
<heat>
mjg, i've actually wanted a procfs for a while although BSD people will say "hurr durr sysctl good"
<mjg>
depends what you want procfs for
<mjg>
i can't stress enough that the linux lollery resulted in (let's call put it mildly) redefinition of the term
<heat>
the sane way would be to emulate good bits of linux like freebsd has (for linprocfs or something like that?) for htop and other software
<heat>
but I'm not interested in classic sprintf-in-libc to do basic stuff like setting a thread name
unimplemented has joined #osdev
<CompanionCube>
iirc SOLARIS has a binary procfs?
<mjg>
what does that mean
<heat>
I think sysctlbyname is itself a really poor interface. you basically reimplement a simple dcache and path walking because you were stubborn enough not to make it a filesystem, and now it doesn't work with scripts without a binary and the performance will suck ass
<heat>
and you lose all sorts of filesystem-based isolation that has been developed over the past 20-30 years
<mjg>
are you serious mate
<heat>
no
<heat>
and yes
<mjg>
key difference between lolfiles in procfs vs proper sysctl nodes is what do you do with the data in there
<mjg>
you think exporting everything only as text is great?
<mjg>
because that's what they do
<heat>
having stared at kern_sysctl.c, the code sucks ass and has been abandoned over the last 30 years
<heat>
no.
<mjg>
and it makes for an uber loller in real code
<heat>
never said that
<mjg>
it does not have to b like that, but they do it
<mjg>
dawg i'm not gonna defend sysctl as implemented in the bsd land, i'm pretty sure i said the code is total crap
<mjg>
but certain ideas behind it are superior to text files
<heat>
it would be ok to me if you just have some sort of handle database and could query it for a handle, and then do ioctl operations for binary versions of data
<heat>
but if you need to do weird path operations you're probably barking up the wrong tree
<zid>
gog
<zid>
You forgot to praise me
<heat>
but yes, regarding text vs binary i'm totally with you: text as an ABI is hilariously bad
<heat>
at least for anything that is not a shell script
<mjg>
burp
<mjg>
i'/m not gonna flame anything today
<mjg>
already have 3 flamey emails to write
<mjg>
wanna flame it, catch me tomorrow
<heat>
ok mjg@ for the ia64 removal?
<mjg>
i have been putting them off for way too long
<mjg>
ok "with reservations" mjg@
<heat>
Reviewed-by: mjg@FreeBSD.org
<mjg>
Lolled-at-by:
<Ermine>
... myemail@example.com
<heat>
Nacked-by: tech-kern@netbsd.org
<Ermine>
Onyx mail when
<mjg>
tech-kern@onyx.org
<zid>
you guys are crowding gog out
<zid>
how rude
<gog>
zid
<gog>
i was busy sorry
<zid>
I posted another picture 6 minutes after the previous one that sort of has a working lt
<zid>
lut
<zid>
but space is somehow 6
<zid>
possibly cus control codes
bnchs has quit [Read error: Connection reset by peer]
heat has quit [Read error: Connection reset by peer]
heat has joined #osdev
<heat>
Ermine, you mean mailing list or email client?
gildasio1 has quit [Ping timeout: 255 seconds]
gildasio1 has joined #osdev
[itchyjunk] has joined #osdev
<Ermine>
heat: I mean you having an address with onyx-related domain name
<heat>
i'll do it when sortie does it
<heat>
osdev is all about genital-measuring
<heat>
until then I have little need for an onyx domain lol
<heat>
also onyx.org is taken
<mjg>
onyx.io?
<mjg>
onyxos.org
<heat>
OnyxBSD.org
<zid>
onyx-project.org
<mjg>
there used tob e a script named dicksize.pl
<mjg>
it would take a look at your storage, uptime etc. and compute hwo long your dick is based on it
<zid>
dicksize.pl | passwd
<mjg>
can't find it name
<mjg>
can't find it now
<zid>
too short lolol omg rekt
* geist
pets gog
<mjg>
'dick from a to z hehe..he?"'
<heat>
mjg, it should be if (current_os != "Windows") size = "0.1cm";
<heat>
so I installed my first flatpak a few days ago and I realize KDE helpfully tells me if i have flatpak updates and I only need to click a button to install them
<heat>
this is usable
<heat>
+1
<zid>
what's 9 inches in cm
<heat>
whats 9 inches in football fields per bald eagle
<zid>
my cable showed up, so I poured coffee on my controller
<zid>
pretty much exactly how it happend
* geist
retires itanium support
<zid>
and then my right headphone stopped working so I had to resolder the cable again
<zid>
I am finally sat back down
<mjg>
geist: that's mainstream
* Ermine
screams in snap
* geist
unmounts Ermine
* mjg
suspends writes to geist
* geist
stops the vm
<sham1>
Snaps? I hardly knew her!
<sham1>
Although annoyingly I have the pleasure of using Ubuntu at work, which means dealing with snaps
<heat>
"pleasure"
<mjg>
arch user detected
<sham1>
The dripping sarcasm was enough, I hope
<sham1>
Also eww, arch
<mjg>
that's what she said
<heat>
fedora user detected
<sham1>
Thanks
<heat>
also - fedora - solid distro, has my seal of approval
<heat>
i've never had an experience with ubuntu or any debian distro that has not been hopelessly broken
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
<mrvn>
heat: the only time for me any Debian was hopelessly broken was when libc6 lost support for 68060.
<mrvn>
you need more hope it seems.
<mjg>
ubuntu works great for me for years
<mrvn>
most problems I had in the last decade or more was grub update
<sham1>
Ubuntu works well enough. But the snaps tho. Why do I need them on desktop
<mjg>
snip snap
<mrvn>
At work we switched to the firefox ppa instead of the snap wrapper package in main.
<sham1>
I'm personally not that into flatpaks either, but they're not as aggressively pushed. While one needs to install for example Firefox from a snap
<sham1>
Oh yeah, that'd also work
jjuran has quit [Quit: Killing Colloquy first, before it kills me…]
jjuran has joined #osdev
xenos1984 has joined #osdev
unimplemented has quit [Read error: Connection reset by peer]
GeDaMo has quit [Quit: That's it, you people have stood in my way long enough! I'm going to clown college!]
heat has quit [Remote host closed the connection]
heat has joined #osdev
unimplemented has joined #osdev
<heat>
sham1, i'm not big on flatpaks but I wanted a solution to getting chrome on arch, the AUR sucked (manual updates, etc) so I used a flatpak for this. works very well
defaultxr has left #osdev [#osdev]
<mrvn>
I should work some more on my solution that takes a binary and builds a kernel out of it for kvm.
slidercrank has joined #osdev
<yuriko>
tbh Pop!_OS is Ubuntu without the canonical bs and therefore better
zid has quit [Ping timeout: 248 seconds]
<yuriko>
although I use OpenSuSE Tumbleweed just by habit
<heat>
ubuntu without canonical is just debian :v
<yuriko>
debian is for neckbeards, even more than arch tbh
<yuriko>
all the cool kids use pop
<heat>
it is
<heat>
but pop is verifiably uncool too
<yuriko>
how so
<heat>
it's the new cheap distro for "are you a GAMER and want to GAME your GAMING GAMES? Install Pop!"
<heat>
also, exclamation point in the name? really?
<yuriko>
gamers delenda est
DynamiteDan has quit [Excess Flood]
<gog>
i'm a gamer and i want to game my gaming games
<gog>
so i'm gonna write an OS that can run every game ever made
DynamiteDan has joined #osdev
<lav>
they should make an OS for gaming that can run all the good games and none of the bad ones
woky- has quit [Read error: Connection reset by peer]
woky_ has joined #osdev
DynamiteDan has quit [Ping timeout: 255 seconds]
<mjg>
geist: remember when i said firefox eats my ram?
danilogondolfo has quit [Remote host closed the connection]
<mrvn>
mjg: likle popcorn, news at 11
<mjg>
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
DynamiteDan has joined #osdev
<mjg>
967883 f 20 0 11,3g 179128 21372 D 23,8 1,5 5:00.94 firefox
<mjg>
620451 f 20 0 11,8g 242332 5976 D 19,0 2,0 252:34.12 firefox
<mjg>
950254 f 20 0 3589268 210720 17980 D 19,0 1,7 27:56.40 firefox
<mjg>
805894 f 20 0 12,1g 408512 59932 D 14,3 3,4 276:08.87 firefox
<mjg>
mrvn: well he claimed i'm making shit up
<heat>
geist DEFEATED by FACTS and LOGIC
unimplemented has quit [Read error: Connection reset by peer]
<mrvn>
Only been up a day or so and already eating 1G each
<mjg>
so i killed 3 and i'm at 6.4G free
<mjg>
up from < 100MB
<yuriko>
how much RAM do you have in total
<geist>
sure. thats about what i see
<geist>
the virt size is meaningless. it grabs a bunch of virt memory and then doesn't touch it
<geist>
the res size is yeah where it uses up a lot, per tab/window
<geist>
the key is how good does it trim off processes as the system hits full load
<geist>
since clearly you can't maintain 100 processes of 400MB a piece. the different browsers have various algorithms to deal with that, with varying degrees of okay
<mjg>
well it sits at ~500MB free and the system is usbale
<mjg>
suddenly they all start grabbing more ram and everything goes to shit
<heat>
i think firefox is worse at resource usage than chrome, at least in my experience
<mjg>
have to kill -9, assuming i manage tog et a terminal
<geist>
yep. i can't speak for how well firefox deals with that, since i dont use
<mrvn>
why and how would firefox deal with that at all?
<heat>
mjg, having kill -9 is luxurious
<geist>
chrome i'm fairly happy with, or at least i haven't seen it misbehave. i think it spends a fair amount of logic trying to trim its flock of processes according to system memory usage
<mjg>
nice
<mjg>
maybe will try it out again
<mjg>
i'm on firefox mainly due to inertia
<geist>
note it may still use up a sizable amount, but i think it tries not to hog everything
<heat>
i had hit a bug in linux 6.1 where kill or htop or any of that stuff would block the whole system for $time
<heat>
due to mmap_sem getting hogged for ages in some buggy khugepaged code
<geist>
though i admit i generally have the luxury of using machines with a lot of ram, but it's somewhat to avoid even having it to think about it
<mjg>
heat: that's a classic
<geist>
but i have a few 4GB machines with chrome and 20ish tabs and whatnot, and dont really seem much trouble
<mjg>
i have 12G
<geist>
it's using more than half the ram, but its not pushing the system into hard swap or whatnot
<geist>
it just kills off tabs faster
<heat>
geist, wasn't chrome getting rid of the adblock stuff?
<heat>
because if they haven't backed off of that, that's a hard nope
<geist>
i dunno i always use adblockplus
<geist>
means there's a whole other process doing the adblocking stuff but the net win is less ads and probably overall less memory usage
<geist>
so it's a net win
<geist>
firefox may have it to but there's a whole task manager that shows what its doing
<heat>
ah yes, manifest v3
<geist>
and there's a neat graph of all the interconnects between the processes that updates live... what is the url to that
<heat>
it's "delayed indefinitely" which is great news for everyone who enjoys using the internet
<heat>
yeah firefox has that
<geist>
ah yes: chrome://discards
<geist>
it's basically it's internal scoreboard of all the tabs and processes and which ones are on the hit list next, etc
<geist>
then there's a graph button on the righ that's kinda cute
<geist>
shows you the relationship between the processes and sites and whatnot
<heat>
geist, something that chrome doesn't have: on mobile, firefox also supports normal extensions
<geist>
with that discard page you can also force a cleanup at any time
<geist>
looks like, for example, the 155 tabs i have open here on this machine about 20 of them are loaded, and the rest have been unloaded due to me not touching it in a while
<heat>
can chrome sync tabs with other instances yet?
<geist>
looks like the line in the sand is 'not visible' + 2 days since last use
<geist>
oh yeah, it's had that for some time
<heat>
also >155 tabs lmao
<geist>
sure. but my point is it's not that much more expensive to have more tabs that are just not being used
<geist>
since they'll get culled
<heat>
yeah totally
<geist>
of course being visible is part of it. if you go to a window and just cycle through every tab that'll bring em all back in
<geist>
or if you dont use tabs but yuo keep like 100 windows then they're all visible
<heat>
how do you sync tabs with mobile btw?
<geist>
i dunno, it's just part of the ui. basically you go to history and then you can see the history of other computers (if you enable that) including things that are currently open
<geist>
but i rarely use browsers in mobile, so dunno
lav has quit [Quit: leaving]
lav has joined #osdev
<heat>
aha found it, "Recent tabs"
<heat>
good shit
<heat>
geist, btw, on-topic q, arm does not allow for split lock situations right?
<geist>
what do you mean split lock?
<heat>
atomic on two separate cache lines
<geist>
ah yes correct. atomics must be aligned
<heat>
ah great
<heat>
something something sane superior architecture
<mjg>
maybe it does not do it... yet
<geist>
i think the idea is though it's not explicitly stated, the atomic mechanism is clearly built on top of using exclusive cache lines and that underlying mechanism
<geist>
so nothing can cross a cache line
<mjg>
i note it was not that long ago where you could not do misalign accesses whatsoever
<mjg>
atomic or not
<geist>
since the cache lines on arm are generally at least 64 bytes, not in a huge risk of having any larger atomics than that any time soon
gildasio1 has quit [Ping timeout: 255 seconds]
<geist>
mjg: on arm? yeah like about 18 years ago now
<geist>
since having an external chipset doing the memory controller and SMP + multicore sockets would have been hard
<mrvn>
heat: dual socket boards, sure.
<geist>
ie, you'd have to basically have two sets of pins
<geist>
heat: oh yeah totally, back frm the beginning. i think even 8086 had the proper bus grant/release to let you do SMP or at least MP if you wanted
<geist>
but certainly by 386 folks were building SMP machines
<heat>
but you had no atomics by that point
<geist>
you always had LOCK it hink
<geist>
and that's an atomic
<geist>
LOCK XCHG was always there, or at least very early. that's all the atomic you need to build everything else
<heat>
i thought there were specific issues with doing atomics on i386 tho?
<geist>
dunno. possibly it didn't work very well, i dunno
<heat>
maybe that was just on the linux side
<geist>
dunno when say lock add came along or whatnot
<geist>
or if it was always there
<geist>
the real key is when did the LOCK# signal come along, because you basically want that for some sort of external synchronization with another cpu
<geist>
or at least something external that fiddles with ram, i guess
<mrvn>
How would that work with cache lines locking?
<geist>
well in the early days there were no cache lines, or they were on the chipset if present
<geist>
by 486 they started adding L1 data cache i think, so that's probably where it got interesting
<mrvn>
sure, but since then a LOCK# signal seems impossible to work right
<geist>
well, i'm sure they figured it out
<geist>
i'd start with a 386 or 486 data sheet and see if they talk about it
<geist>
should basically tell you because they're describing what the chipset would see, and then it should be telling you the bus transactions that the cpu puts out there
<heat>
yep, linked you to it
<mrvn>
do modern sockets even have the pin anymore?
<geist>
and thus you could probably figure out what the chipset would need to do
<geist>
you want the data sheet from the hardware poitn of view
<geist>
though the PM may have the info.
<heat>
why? it describes LOCK and LOCK# pretty clearly
<geist>
okay.
<heat>
including where it asserts LOCK# implicitly
<geist>
i'm thinking abou tit from a 486/586 point of view
<geist>
386 may be too simple because it didn't have a cache
<geist>
or at least not a full data cache with writeback
<geist>
a non writeback cache it could sniff the bus and watch the other cpus do things and evict its own lines
<geist>
including LOCKed transactions
heat_ has joined #osdev
heat has quit [Read error: Connection reset by peer]
<geist>
but anyway, justdoing it off the tp of my head. might be interesting
<geist>
last thing i deeply was reading the lines for was the 68030 which was about the same capability as a 386 from a bus transaction point of view
<geist>
and it has its own form of locked transactions, but the motorola docs pretty much tell you how to wire up SMP and what you have to do
<geist>
also somewhere i have a copy of some pretty good nitty gritty docs on the am586, which was 486 class, and i think SMP capabile too?
<mrvn>
geist: wana build a quad 68030 system?
<geist>
mrvn: kidna yeah. i have a pile of 030s, but really it's complicated enough that you need a FPGA to do the bus coherence
<mrvn>
I kind of would want that anway to interface with an Amigas system bus
<geist>
but the discovery of the rosco_m68k kinda diverted my attention, since he already has a board that does what i wanted pretty much exactly as i'd do it
<geist>
and at the time he was working on an 020 and 030 version
<geist>
since the original is an 010
<heat_>
SDM says: for the 486 and pentium, LOCK# was asserted on the bus; for P6 and newer, if the area of memory being LOCKed is cached and marked WB and completely contained in the cache line, it will not assert the LOCK# on the bus
<heat_>
but for other situations (memory not cached, memory not WB, or split lock) it seems that it will
heat_ is now known as heat
<heat>
although they do not say so explicitly, probably to not bind them to this contract
<geist>
ah okay. so P6 is where it started switching to the new mechanism basically
<geist>
re: atomics on uncached memory, riscv seems to allow this, and some of the sifive peripherals actually use it
<mrvn>
and ARM/AArch64?
<heat>
do they? I did not use atomics for any drivers
<heat>
i think
<geist>
first time i've seen it, actually. for example on one of the interrupt bits of the sifive uart i think you can do an atomic swap of the write register i think
<geist>
i dont tyink you *have* to, but it does state that yuo can
<geist>
as an optimization, less transactions
<heat>
yeah
<geist>
mrvn: absolutely not. atomics only work on cached memory
<heat>
x86 does seem to allow it too
<geist>
one of the peripherals in sifive stuff has a single register for interrupt read and ack
<geist>
which is normally ugh, but it lets you OR in an ack value without clearing any other bits
<geist>
that's a case where you must use atomics or you might wipe out another pending bit
<heat>
well, those registers are usually "write 1 for ACK"
<mrvn>
Normaly that works by having a register where writing a 1 bit resets that bit
<geist>
yeah there was something else about it
Terlisimo has quit [Quit: Connection reset by beer]
<geist>
but yeah maybe was just that
<geist>
but i do remember the uart had some of those. the data out register also has a field for the number of slots in the FIFO
<mrvn>
some hardware has 4 registers: read, write, set, clear.
<geist>
so it's kinda neat where you can just atomic swap your data in and simultaneously get the number of fifo entries left
<geist>
lets you write a single register polling loop basically
<heat>
is it not just a standard 16550?
<heat>
i know the qemu virt uart is
<geist>
no
<geist>
because you can't do an atomic swap with a 16550
<geist>
and the fifo status register is separate
<heat>
yeah
<heat>
weird choice then
<geist>
yeah it was like they were just trying to flex that their bus supports atomic transactions
<geist>
note that the sifive uart is not the qemu virt uart. that's the biggest difference you'll immediately see if you use qemu -machine sifive_u
<heat>
yep
<heat>
i am super satisfied that my qemu virt uart uses the same driver as the PC uart
<heat>
just needed to add devtree support to it
<geist>
yeah, the annoying thing is dealing with some mmio 16550s that want 8 or 32 bit spacing, etc
<geist>
but so it goes. eventually a 16550 driver that deals with a ton of impementations will have a lot of quirks, but so it goes.
zid has joined #osdev
<heat>
yeah
<zid>
good news, my PC is fucked
<zid>
might just walk out to sea I'm sick of this shit
<heat>
why
<zid>
mobo says 61, no cpu, different cpu, no ram, 1 ram
<zid>
always 61
<zid>
never does anything
<heat>
61 what? post code?
<zid>
yea
<zid>
nearly instantly too
<heat>
do you know what that means?
<zid>
apparently it's "initializing nvram", so bios is dead afterall
<heat>
heh
<geist>
!!
<zid>
or just random, bios codes are fucked always
<geist>
sorry zid
<zid>
I might throw it down a staircase
<geist>
walking out to sea does sound nice
<zid>
see if that helps
<geist>
do you h ave a window that opens?
<zid>
you know that's a euphamism for suicide right geist?
<geist>
preferably not ground floor?
<geist>
ah
<heat>
lmao
Terlisimo has joined #osdev
<geist>
well it would kill you pretty fast here since the water is so cold
<geist>
you only survive like 15 minutes or something
<heat>
could be another rail again
<zid>
very doubt it
<geist>
if you defenestrate it that might be pleasant
<zid>
I'll sit here reflashing random bios roms over and over for a bit
<zid>
then probably just walk into traffic
<zid>
even if I had the money to replace this shit I couldn't be bothered to search ebay for whatever mobo supports my weird dram and cpu
<zid>
oh thank god for that, I flashed a different bios and it did.. something?
<zid>
It's giving 0x0D, 'reserved for future'
<heat>
sounds like a \n
<heat>
or is it a \r?
<heat>
yeah \r
bgs has quit [Remote host closed the connection]
<zid>
okay that gives bios recovery screen which is where I started at
<zid>
"please insert a usb with r4g.rom on it and reset"
bradd has joined #osdev
<zid>
which you do, ezflash2 appears, you flash a new bios rom, and you go back to bios recoveyr screen
heat has quit [Read error: Connection reset by peer]
heat has joined #osdev
<zid>
been stuck on 06 and 9a and 79 so far at random on bios 1305..
woky_ has quit [Quit: Nothing in this world is hopeless!]
<zid>
1404 just stuck on 61
woky_ has joined #osdev
<mrvn>
zid: perfect time to switch to a Raspberry Pi.
<mrvn>
or a nice M1.
<zid>
oh he's not ignored here, unsurprisingly he said something stupid