<geist>
was jsut about to wire up a spare machine for some osdev hackery. i should install tauros on it
<geist>
a proper 12/24 ryzen machine, think it'll run on that fine?
* sortie
is ready to reweet and all that good stuff
<sortie>
Today is klange's day
<klange>
Possibly, though usefulness is still dependent on PS/2 input devices - USB remains defered to 2.1.
<geist>
ah i think it has ps/2
<klange>
I can boot with all cores to a working GUI on my Surface, but can't do shit with it :)
<klange>
I recommend Grub for real system installations, and I haven't done a lot of testing on EFI systems so if you can CSM that'll probably work better.
<geist>
kk
<sortie>
Btw I've actually been doing some osdev this weekend! I added a signal handler to init(8) so you can send SIGINT to request a reboot and SIGTERM to request a poweroff. I even added poweroff(8) and reboot(8) convenience programs for sending those fateful signals.
<klange>
sortie: I almost rushed a commit to do the same but I'll wait until later to fix up my shutdown process :)
<sortie>
My new (years old, just unmerged) init(8) is rather neat because it does proper recursive dependency tracking of daemons where they can signal when they've come up and are ready.
<sortie>
Turns out implementing an unexpected requested poweroff was easy. Basically I just cut the implied reference to the default daemon and it makes the reference counts drop throughout the tree as everything becomes marked as not needed and then things are brought down gracefully in reverse order.
<sortie>
Sortix is really evolving towards being a cloud OS. These days there's like 3-4 VM instances running it at any given time, across two independent physical Linux hosts in cloud data centers.
<sortie>
OK downloaded myself a neat toary image.iso
<sortie>
Wow look at that bootloader
<sortie>
It did a neat flashy thing
<sortie>
Toaru booted up fine in VirtualBox although it was stuck on 'setting up networking' or such for a 15 seconds or so, seemed a bit long
<klange>
I think that's DHCP being hella slow in that environment and me being dumb enough to delay startup on it.
<klange>
Though 15 seems egregious, I usually get 5 or so.
<klange>
Random note: While the animation on the loader may look like it linearly tracks progress, that's only coincidental with the current ramdisk size, it's actually a loop animation.
<sortie>
OK timed it, in my VirtualBox VM where I usually develop Sortix, it took 54 seconds between "Setting up network" and the desktop popping up
<sortie>
In Sortix, DHCP just takes a couple seconds at worst to come up. I wonder if it's some AHCI/ATA driver thing?
mahmutov has quit [Ping timeout: 256 seconds]
<klange>
I don't even talk to disks at that stage.
<sortie>
Neat way of getting the secrets from my Sortix VM,encoding it in a stack trace
<klange>
Can you tell me how the VM's network is configured?
<sortie>
82540EM bridged adapter to enp2s0
<klange>
Can you switch to the virtualized NAT?
<sortie>
Lemme see first if it's reproducible
<klange>
Also, ah, that'll explain the slow DHCP - actually possibly failure based on the panel icon.
<klange>
Guess what the priority is for 2.0.x bugfixes~ [it's network stuff]
<sortie>
It appears your OS does unattended connections to the internet. Do you have a privacy policy or some sort of list of what it does so it's uh more consensual?
heat has quit [Ping timeout: 260 seconds]
<sortie>
Yeah the crash happened again after a while
<sortie>
The tutorial says something about "Beta users" but this is a stable release
<klange>
Two third-party resources (ip-api.com and api.openweathermap.org), one CDN for packages, and the main site as a fallback.
<sortie>
The slow boot and panic still happens with the network set to 'NAT'
<klange>
Huh. I will look into it.
<sortie>
My VirtualBox might also be old
<sortie>
Need to upgrade my distro big time
<sortie>
Alt + window drag doesn't seem to work in virtualbox, looks like my window environment gets the event instead, even in virtualbox full screen
<sortie>
I'm using VirtualBox 5.1.38 which is probably where you yell at me
<klange>
What WM are you using? VBox is usually really good at getting input, even on Gnome I get 'super' to pass through.
<sortie>
Cinnamon
<klange>
< sortie> The tutorial says something about "Beta users" but this is a stable release
<klange>
Oh shoot it also still mentions Python
<klange>
I decided to not bother until I have all the pthread lock stuff Python wants since 3.7, since I have Kuroko.
MiningMarsh has joined #osdev
<sortie>
Resizing the file browser is a bit funky, both with the rescaling of what it used to look like, and it kinda snapping to the right size afterwards which doesn't seem to be exactly the size I changed it to
<sortie>
OK let's qemu this thing
<sortie>
Boots instantly, got net, and weather
<j`ey>
booted in virtualbox, I get network, and weather
<sortie>
Cool promt for the password. Needs a bit of a flashing text cursor maybe cuz I was unsure if it got focus but it did
<sortie>
Hmm, the package manager doesn't seem very reliable for input? I kept clicking on binutils and it didn't do anything and then suddenly it worked
srjek|home has joined #osdev
<klange>
Are you single or double clicking?
<j`ey>
klange: is there a way to test sound easily?
<klange>
Install Doom.
<sortie>
I tried double clicking
<sortie>
Now it seems to work as I expect
<sortie>
Cool with a modern gcc and binutils
<j`ey>
klange: I did. I dont get sound. I'll record a little video
<klange>
Some versions of VirtualBox were disabling audio output by default on new VMs, that was fun.
<klange>
on QEMU you need to specify an audio device, you don't get one by default
<sortie>
Yay doom has sound
<klange>
and in both cases I only have drivers for AC'97 and the Ensoniq card VMware emulates
Burgundy has quit [Ping timeout: 256 seconds]
<klange>
HDA drivers are in progress, they're on the 2.1 roadmap
<sortie>
Hmm. Double clicking the top of the terminal window title doesn't maximize it. When I click the button for it, it does maximize, though it doesn't restore if I click again
<sortie>
Oh, ls seems to sort elements by row, not by column like I'd expect
<klange>
I don't have double click to maximize, that sounds like a viable feature request.
<sortie>
Seriously though, this is a super impressive osdev windowing environment
<sortie>
Works pretty well in qemu
<klange>
> though it doesn't restore if I click again
<klange>
huh that should work... unless it got confused about the unmaximized size
<klange>
I should look into getting opl2 emulation backported into this port. It's ozkl's doomgeneric which is based on 'fbDOOM' which is based on an ooold version of chocolatedoom
<klange>
(which is an ongoing project to provide a faithful source port)
<j`ey>
why is there a background 'gunzip -c' process running I wonder
<klange>
Probably a borked process from the package manager that failed to exit or get cleaned up.
<klange>
I think I still have some weirdness there.
<j`ey>
I went into VGA text mode, ran `top`, if you then hold a key (up down, whatever key) CPU usage spikes to 10%!
<sortie>
... I want to play with toaru
<sortie>
Looks like the third party build stuff is the absolute minimal, gcc and binutils, no make and other things
<klange>
make really wants a good sh to be useful, dash port is... working but not ready for prime time
<sortie>
The impression I get is that this environment really wants to be powerful but it's mostly self-contained with the stuff it has so far
<sortie>
That makes a lot of sense given how you redid everything and is really impressive
<sortie>
Definitely has bim, the terminal, koroku and so on so one can do some real scripting
<sortie>
fetch and tar also. I guess fetch can also upload data with some sort of POST request?
<sortie>
Yeah
<klange>
It has a little hacky thing for that I used to use to upload screenshots to a PHP page.
<sortie>
Thought about making a little nc(1)?
<sortie>
Handy way of getting data off to the local network
<sortie>
(Plus testing TCP)
<sortie>
I kinda want to try porting modern yutani, I bet it still relies heavily on shared memory (which is still pretty darn unstable)
<sortie>
I remember koroku ported pretty well
<klange>
The shared memory subsystem Yutani uses might get swapped out for a more standardized mmap approach eventually; same with IPC messaging switching to... something. Maybe local TCP sockets. Maybe Unix sockets if I bother.
<klange>
I did push some fixes for Kuroko, and while the Makefile may be iffy a good ol' bit of direct gcc'ing should build it nicely on Sortix.
<sortie>
The Julia fractals are super cool, could use a zoom feature
dude12312414 has joined #osdev
dude12312414 has quit [Remote host closed the connection]
<sortie>
Well big congratulations on the release
<klange>
Now I can work on all those things I put off :)
<sortie>
This is definitely a slick milestone where years of hard work comes together and makes it seem to easy and functional
<sortie>
The very best osdev get so well out of the way that users fixate on irrelevant details
<klange>
Bugs and feature requests always live at the edge of functionality :)
<sortie>
:D
pretty_dumm_guy has quit [Quit: WeeChat 3.3]
gog has quit [Ping timeout: 260 seconds]
<kazinsal>
:toot: congrats on the release
MiningMarsh has quit [Ping timeout: 252 seconds]
CaCode_ has joined #osdev
CaCode has quit [Ping timeout: 250 seconds]
Belxjander has quit [Ping timeout: 252 seconds]
MiningMarsh has joined #osdev
srjek|home has quit [Ping timeout: 252 seconds]
ElectronApps has joined #osdev
darkstarx has quit [Remote host closed the connection]
wikan has joined #osdev
nyah has quit [Ping timeout: 268 seconds]
darkstardevx has joined #osdev
darkstardevx has quit [Remote host closed the connection]
darkstardevx has joined #osdev
darkstardevx has quit [Remote host closed the connection]
darkstardevx has joined #osdev
darkstardevx has quit [Read error: Connection reset by peer]
darkstardevx has joined #osdev
darkstardevx has quit [Remote host closed the connection]
darkstardevx has joined #osdev
sonny has joined #osdev
Dreg has quit [Read error: Connection reset by peer]
Dreg has joined #osdev
<zid>
You guys are quiet today, should I set something on fire?
<klange>
Ah, dangit, should have tested on the desktop before release, had a little bug with >60GB of RAM where a sanity check was causing an early panic...
xing_song1 has quit [Read error: Connection reset by peer]
sdfgsdfg has quit [Quit: ZzzZ]
<moon-child>
ooh, new riscv core
<moon-child>
one-upping x86 with 128-byte vectors :P
<moon-child>
oh nevermind it's just 16 bytes apparently
Burgundy has joined #osdev
<sortie>
The feeling when I realize klange's monitor looks almost identical to mine although the model number is vastly different
<klange>
I have three of these
<sortie>
Neat I have a dual monitor setup
sortie has quit [Ping timeout: 250 seconds]
sortie has joined #osdev
the_lanetly_052_ has joined #osdev
ZombieChicken has quit [Remote host closed the connection]
YuutaW has quit [Remote host closed the connection]
CaCode has joined #osdev
Teukka has joined #osdev
<Affliction>
moon-child: sounds like a nice heater :)
Teukka has quit [Changing host]
Teukka has joined #osdev
dzwdz has left #osdev [WeeChat 3.2]
mahmutov has joined #osdev
zagto has quit [Quit: Konversation terminated!]
mahmutov has quit [Ping timeout: 240 seconds]
<Ameisen>
sortie: my monitors didn't come with sticky notes on them
<sortie>
You better keeping monitoring for when they pop up
<sortie>
It's critical you complete any tasks that appear on sticky notes on your monitor
<sortie>
This has been the special containment procedures
<Ameisen>
Which SCP is it?
<kazinsal>
SCP-7126: The Sortix Operating System
YuutaW has joined #osdev
CaCode_ has joined #osdev
CaCode has quit [Ping timeout: 240 seconds]
pretty_dumm_guy has joined #osdev
C-Man has joined #osdev
isaacwoods has quit [Quit: WeeChat 3.3]
zaquest has quit [Quit: Leaving]
zaquest has joined #osdev
CaCode_ has quit [Quit: Leaving]
gog has joined #osdev
C-Man has quit [Read error: Connection reset by peer]
ElectronApps has quit [Quit: Leaving]
ElectronApps has joined #osdev
<zid>
advent looks annoying
heat has joined #osdev
mimmy has joined #osdev
mahmutov has joined #osdev
mctpyt has quit [Ping timeout: 250 seconds]
srjek|home has joined #osdev
xing_song1 has joined #osdev
mimmy has quit [Ping timeout: 268 seconds]
Arthuria has joined #osdev
hbag has quit [Remote host closed the connection]
mimmy has joined #osdev
Oli has joined #osdev
the_lanetly_052 has joined #osdev
the_lanetly_052_ has quit [Ping timeout: 260 seconds]
<zid>
I genuinely can't do it
<zid>
I either short-count the paths cus I ban something, or infinite loop cus no bans
fwg has joined #osdev
Arthuria has quit [Ping timeout: 240 seconds]
mimmy has quit [Ping timeout: 252 seconds]
nyah has joined #osdev
heat has quit [Remote host closed the connection]
heat has joined #osdev
<amazigh>
I have a single monitor setup with a tiling wm
vdamewood has joined #osdev
ElectronApps has quit [Remote host closed the connection]
mimmy has joined #osdev
mimmy has quit [Ping timeout: 260 seconds]
mimmy has joined #osdev
mimmy has quit [Ping timeout: 268 seconds]
dude12312414 has joined #osdev
<sortie>
Hehe I got a contributor to set up their IRC bot written in python on a permanent Sortix server VM and connect it to my IRC network
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
vdamewood has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<heat>
i totally need python
zhiayang has quit [Quit: oof.]
zhiayang has joined #osdev
SpikeHeron has quit [Quit: WeeChat 3.3]
mimmy has joined #osdev
dutch has joined #osdev
mimmy has quit [Ping timeout: 260 seconds]
dude12312414 has joined #osdev
gog has quit [Ping timeout: 250 seconds]
xing_song1 has quit [Ping timeout: 250 seconds]
mimmy has joined #osdev
mimmy has quit [Ping timeout: 250 seconds]
mctpyt has joined #osdev
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
mimmy has joined #osdev
gdd has quit [Ping timeout: 252 seconds]
gog has joined #osdev
mimmy has quit [Ping timeout: 260 seconds]
gdd has joined #osdev
mahmutov has quit [Ping timeout: 268 seconds]
the_lanetly_052_ has joined #osdev
the_lanetly_052 has quit [Read error: Connection reset by peer]
<junon>
finally got fed up with microsoft terminal and as if the venerable and holy Dennis Ritchie himself was answering my prayers a new one popped up on HN that works perfectly: wezterm
<j`ey>
(written in rust!)
elastic_dog has quit [Ping timeout: 250 seconds]
<heat>
what's wrong with windows terminal?
elastic_dog has joined #osdev
<zid>
tbh what's right with it
mimmy has joined #osdev
<heat>
it's pretty and works
<heat>
integrates with WSL too
<GeDaMo>
I take it you didn't see Casey Muratori's rant about it :P
<heat>
if I pipe gb of data into my terminal, it's slow
<heat>
oh no!
<heat>
oh how will I hexdump COD Warzone now?
<junon>
Windows Terminal freezes on me randomly, individual panes too. It crashes more than once a week, which is once too many times.
<heat>
i haven't had any issues
<junon>
Border characters don't work unless the font is a ridiculously huge size
<junon>
Panes can't be adjusted using the mouse
<junon>
you can't control which direction new panes are created
<junon>
it's slow
<junon>
but mostly because it kept fking freezing or crashing for me was the final straw.
<heat>
welp I haven't had any issues when using it
<junon>
Lucky you xD
<junon>
also it doesn't have sixel support which I've wanted for a while. Wezterm still has issues with it but that's only because of (surprise!) conpty issues, which is developed by Microsoft for Windows Terminal
mimmy has quit [Ping timeout: 268 seconds]
<junon>
if you use wezterm to SSH directly instead of using a tty and a cli utility, sixel works correctly.
<junon>
Because it completely bypasses windows nonsense.
the_lanetly_052_ has quit [Ping timeout: 260 seconds]
fwg has quit [Quit: .oO( zzZzZzz ...]
hbag has joined #osdev
rustyy has quit [Quit: leaving]
rustyy has joined #osdev
mimmy has joined #osdev
mimmy has quit [Ping timeout: 250 seconds]
<heat>
TIL __attribute__((scalar_storage_order("big-endian")))
<heat>
no clang though :/
mimmy has joined #osdev
mimmy has quit [Ping timeout: 256 seconds]
mimmy has joined #osdev
mimmy has quit [Ping timeout: 268 seconds]
elderK has joined #osdev
mimmy has joined #osdev
mimmy has quit [Ping timeout: 268 seconds]
mahmutov has joined #osdev
CaCode has joined #osdev
mimmy has joined #osdev
mimmy has quit [Ping timeout: 268 seconds]
<geist>
good afternoon everyone
<junon>
good evening, geist
<sortie>
(checks notes) Oh hey I'm one of everyone!
<sortie>
How are you geist?
<geist>
pretty good. slept in and got up too late
<geist>
but otherwise it's a nice weekend
<geist>
lots of rain and cold. which is how i like it
mahmutov has quit [Ping timeout: 250 seconds]
<sortie>
Neat :)
<sortie>
They got new restrictions here so I did an osdev weekend :)
sdfgsdfg has joined #osdev
<sortie>
Been playing with a persistent cloud VM installation of my OS, been building missing pieces to make that work well, e.g. I added a shutdown(8) that sends a signal to init, and implemented handling that signal and shutting stuff down gracefully, so I can ssh into a VM and shut it down gracefully
<geist>
i started to write MSI support for the PCI stuff last night
<geist>
going to need an IRQ allocator and then should be able to see
<sortie>
MSI those were the cool fast interrupts thing right?
<j`ey>
yup
<geist>
yah but more importantly dont have to screw around with PIC or ioapic or stacked IRQs
<junon>
geist: do you work on a hobby OS alongside Fuchsia?
<junon>
Or is it Google all the way down for you?
<geist>
yah, actually fuchsia is a fork of my hobby os that i still work on
<junon>
Oh no kidding
<geist>
(well the kernel part, the rest of it is new)
<junon>
Zircon you mean?
<geist>
yah
<junon>
Neat :)
<geist>
it's diverged at lot at this point where it's hardish to see the relationship
<junon>
Yeah, especially with more hands in the cookie jar I bet it changes shape pretty quickly
<geist>
yah
<geist>
anyway doing hobby work on the side keeps me sane, especially as the fuchsia project gets bigger and it's less coding and more administration
<geist>
nice to just sit down and do something and get it done in the same day without project stuff getting in the way
<junon>
yes :)
gog has quit [Ping timeout: 252 seconds]
<geist>
yah it's been hard personally to watch/participate in your thing getting slowly overwritten and changed out from underneath you
<geist>
but... it's a growth opportunity
<geist>
just one of those things that seems like no big deal but sometimes it frustrates you
<junon>
I have a lot of questions I simply won't ask because I know you can't answer them or it wouldn't be appropriate to answer in a public setting. But I can imagine :/
GeDaMo has quit [Remote host closed the connection]
<geist>
also there is a fuchsia discord if you want to ask things there
<junon>
What's the link? I'd like to lurk at least :)
<geist>
hmm, always forget how to get a link to a discord server
<junon>
There's a little person with a plus sign icon next to the currently selected channel on the left side
<junon>
If you click that it'll generate one for you
<junon>
(if you're a mod, make sure the channel is a public channel... lol)
<junon>
unless you want to invite everyone in here to some super secret stuff
<j`ey>
I assume the secret stuff isnt on discord :P
<junon>
You never know.
<junon>
OOB fallback comms are common, especially after the facebook fiasco
<junon>
and iirc you can't restrict users from seeing message history, unless they've changed something
mimmy has joined #osdev
<Bitweasil>
<geist> but... it's a growth opportunity <-- If you want to get back to writing fun code, let me know. ;)
<geist>
a little person with a plus...
<Bitweasil>
IRC makes for nice fallback.
<geist>
well, if you google for fuchsia and discord you find it, since it's in a doc
<Bitweasil>
Matrix is nice for flagship modern multiclient stuff.
<Bitweasil>
Though I don't like the Matrix bridges to IRC, but that's mainly because of how I use IRC anymore.
<geist>
agreed
<geist>
at the minimum i find the [m] stuff pretty distasteful
<Bitweasil>
[m]: This user is likely to do something nonsensical. It's not them, it's their client.
<geist>
junon: it's pretty quiet most the time, but if you start asking kernel or technical questions folks usually blab
<junon>
does my username show up as [m]?
<geist>
i keep meaning to use it more for internal technical comms
mimmy has quit [Ping timeout: 265 seconds]
<geist>
but frankly i already have like 50 channels of internal chat rooms at work, so switching to discord and using it at the same time is additional brain cycles
<Bitweasil>
junon, no.
<zid>
wait junon is using matrix?
<zid>
I want my explanations about gdt and interrupts and stuff back
<junon>
yes
<geist>
guess it's just some bridges that add te [m] suffix? or it's a setting you can turn off
<junon>
I only use it because I need it for a few other things and it persists my irc connection for the most part
<junon>
so it's nice to have it all in one spot.
<junon>
but for other servers (e.g. oftc for #llvm) I use mirc.
<geist>
yah, and really the value of irc is a persistent connection
<geist>
or discord or slack or anything else. the ability to walk away and come ack and see what was said
<junon>
yeah
<zid>
my desktop is stable enough for that, but people whose aren't typically just used bouncers and stuff, what happened to them?
<junon>
especally since telekom can't seem to keep the lights on for more than about eight hours at a time
<geist>
yah and i also suspend my desktop when i'm not using it
<Bitweasil>
zid, nothing. ZNC works as well as it ever did.
<geist>
but more importantly i switch between 3 or 4 computers throughout the day
<zid>
I meant as
<zid>
fashion
<junon>
yeah same
<Bitweasil>
My home ISP sucks, and as far as I can tell I don't disconnect regularly.
<Bitweasil>
er.
<Bitweasil>
znc as fashion?
<Bitweasil>
DefconChic?
<geist>
in the Old Days I just didn't have 3 or 4 computers, or there wasn't an expectation of being able to use IRC outside of my dorm room or whatnot
<junon>
in fact mirc is my "is the internet up" signal. Every time the internet crashes, I hear "beepbeepbeepbeepbeep" over and over again
<geist>
but expectations have changed
<raggi>
Quassel is pretty good too
<zid>
yea mirc lets me know when my internet dies immediately :D
<zid>
"You have disconnected from EFnet. You have disconnected from Libera.chat. You have.."
<junon>
Yep haha
<zid>
"guess my internet is fucked"
<junon>
I hear it at 4am sometimes and it wakes me up
<zid>
hear it? hardcore
<geist>
yah reminds me i should probably disable the alarms on my UPSes
<zid>
I haven't had sounds enabled in mirc since I installed it 20 years ago
<geist>
i get enough power blips here that they all immediately start alarming at me
<Bitweasil>
I really need to add a toggle for the speaker on one of my UPSes.
<Bitweasil>
It beeps enough to be annoying.
<junon>
for whatever insane reason I continue to try to be as responsive as possible despite hating the very idea, so my notification sounds and whatnot are turned on for mentions and things
<j`ey>
I hate notifications
<junon>
I think it stems from childhood trauma. I turned off my first cell phone when I was younger just to enjoy some quiet time and my mother (she's a good mom, promise) called the police thinking I was dead in a ditch somewhere
<junon>
so I think I'm subconsciously afraid of that happening again
<zid>
were you dead in the end?
<junon>
sadly not
<zid>
ah well, try again next year
* junon
starts playing "Turn Around" and stares longingly out a rainy window
<geist>
haha
<geist>
thanks now thats stuck in my head
<zid>
EVERY NOW AND THEN I GET A LITTLE BIT LONELY
<zid>
SOMETHING SOMETHING AROUND
<junon>
TURN AROUND, BRIGHT EYES
<geist>
haha i nearly spit-took on my keyboard there
<junon>
:D
[itchyjunk] has joined #osdev
<kingoffrance>
DEFC04C41C is this the new 0xcoffeecafebabe
<kingoffrance>
*c0ffee
<junon>
defcoacalc?
<junon>
surprised DEFECA7E hasn't been used before.
<zid>
What's a Defé Cafe
<geist>
it's a reall chic place
<geist>
anyway to get back on topic. i need to start hacking a common PC peripheral driver with MSI
<zid>
great then you can tell me how to do it
<geist>
taking bets on: a) AHCI b) NVME c) e1000
<zid>
without me having to look it up
<geist>
which one should i do?
<zid>
e1000 seeing as I also have an e1000 driver
<junon>
e1000
<geist>
hmm, that seems reasonable
friedy10 has joined #osdev
<heat>
AHCI
<heat>
it's like IDE but better
<heat>
it's a storage controller driver for the 2000s
<heat>
also -machine q35 uses an AHCI controller by default
mimmy has joined #osdev
mimmy has quit [Ping timeout: 240 seconds]
dutch has quit [Quit: WeeChat 3.3]
mctpyt has quit [Ping timeout: 250 seconds]
<geist>
yah, that's why i have all three of them on the list. most of my existing storage/network drivers are virtio based, or arm soc specific
<geist>
which is why i hadn't really invested in PCI that much
gog has joined #osdev
<gog>
mew
friedy10 has quit [Ping timeout: 260 seconds]
<junon>
high level question: peripheral devices (NICs, PCI, etc.) don't really translate across different ISAs right?
<junon>
e.g. NICs found on x86 devices aren't going to also be found on ARM, right?
<heat>
they can
<gog>
there's no reason why they shouldn't
<heat>
if you have PCIe you can attach any PCIe device
<heat>
the only issues you can find are firmware/driver related
<junon>
So as long as the host understands PCIe then any PCIe device will work with that host?
<junon>
(assuming the host has drivers for that device)
<heat>
yeah I believe so
<zid>
pci-e devices are identical across ISAs
<zid>
at the very least
sdfgsdfg has quit [Quit: ZzzZ]
<zid>
because they're just memory mapped thingiers, they don't give a shit
<heat>
example: nouveau was enabled for riscv builds a few weeks ago in linux kernel iirc
<zid>
usb almost certainly the same, just a chip you're talking to about usb packets etc, usually even over a pci-e bus tbh
<gog>
nah it's not really dependent on any architecture-specific things and anything that is would be managed by the root complex
<zid>
pci is *sorta* x86y because the controller chips may be designed to talk on the io bus (ISA style)
<zid>
0xCF8 and 0xCFC or whatever the ports were
<zid>
may be, don't have to be
<gog>
yeah the pci config space
<zid>
but that's just the controller
<gog>
but that can also be memory-mapped
<junon>
gotcha okay, the 'transport' (IN/OUT et al) is different but the protocols are more or less the same in a lot of cases.
<gog>
like i had a PPC603 system that had PCI
<gog>
it was a cloned mac back when they allowed that kind of thing, late 90's early 00's
<zid>
yea, mac is a good counterexample to "x bus is PC only"
<zid>
they had ati gpus and stuff
SpikeHeron has joined #osdev
<zid>
as long as you can replicate how they wanna talk electrically, even if that means using another chip to do level conversion or some other nosense, it's possible
<heat>
if you use qemu arm64 virt you can pretty much attach any device you want
<heat>
hrmm I don't know if passthrough works without kvm
<zid>
junon: you should give me a patch to add madt parsing or whatever the table was that had the ioapic
<zid>
then geist should give me one to add msi ;)
<junon>
haven't gotten to madt parsing yeet
<junon>
yet*
<junon>
... yeet*
<zid>
YEET
<geist>
PCI isn't x86 specific, but for Real Devices it tends to be
<geist>
PCIe is starting to show up in some consumer arm SOCs though, though it tends to be highly specific. like the rpi4 for example
<zid>
yea you might end up needing an extra chip for pci
<geist>
what i was saying was i hadnt fiddled with PCI on LK because LK primarily hasnt run on that class of hardware much
<zid>
pci-e should 'just work'
<j`ey>
m1 macs have PCIe too
<geist>
and i dont generally do x86
<geist>
yes yes pci is *not* x86 specific, but it's extremely ubiquitous on x86-pc
<zid>
https://wiki.osdev.org/MADT I think from this you just look for entry type 1 and grab the apic address out of it
<bslsk05>
wiki.osdev.org: MADT - OSDev Wiki
<zid>
and that *should* be what you need, if you ignore all the crap
<geist>
i have been developing this PCI driver for LK to also work on ARM and riscv too
<zid>
Could probably just copy-paste the code I use to grab the pci-e base address and change a couple of numbers
<geist>
the initial discovering is different though
<geist>
because of lack of ACPI on the particular targets i'm fiddlig with
mimmy has joined #osdev
<geist>
but, device tree has the same infos, which can also be parsed
<geist>
basically i have a platform specific piece of logic that figures out where the PCI busses are and then tells the pci driver to initialize, so it's abstracted
<zid>
I have //pci_init(); \n acpi_init(); :p
<zid>
pci works, I tested it, but I don't actually deal with it in the build I use
<geist>
but... an annoying part about qemu arm/riscv is there's no firmware to initialize the bus
<geist>
so to make it go you have to actually do the full BAR assignment stuff
<geist>
which is of coursea bit more work
<zid>
that sounds kinda fun though
<geist>
but i'm designing the bus architecture to let that happen
<geist>
it's like layers of functionality. first layer finds everything, builds up the object model
<zid>
seems like it'd just work fine just with t = n; n += size; return t; though
<geist>
and then additional algorithsm can be run on it to assign things, etc
fwg has joined #osdev
<geist>
zid: alas no. it's more complicated than that
<geist>
it's great up until you have a bridge, and then you have to recursively solve the bridge's aperture
<bslsk05>
github.com: Onyx/pci-msi.cpp at master · heatd/Onyx · GitHub
<geist>
basicaly you need to drill into the bridges and compute the largest size of all the children, then assign that on the way out
<zid>
two passes when it's all memory mapped doesn't sound too bad
<geist>
yah i dont think it's too bad
<zid>
how does hotplug work with all that?
<geist>
what is a bit more complex is the range you can assign things may not be as straightforward as x86-pc
<zid>
or do you just need to give them enough headroom and play
<zid>
pray*
<heat>
with hotplug the bios needs to reserve space for the devices iirc
<geist>
though actually x86-pc is not as straightforward as you might think, since there are really two apertures for PCI based stuff
<zid>
we're talking about the "I have no bios" case heat
<geist>
32bit and 64bit stuff
<heat>
zid, you then
<heat>
whoever is doing the bios's work needs to do this
<zid>
i.e do you need to try and space the bridges out in-case they grow, or will the bridge just ask for a bunch to begin with and you can basically ignore it
<zid>
I'm unsure if the addresses used by the devices' BARs have to be within the bridge's range, I think so?
<heat>
yea
<geist>
right
<zid>
so adding a few graphics cards into a deeply nested bridge might be awkward
<gog>
i have no bios and i must boot
<geist>
if using a standard subtractive bridge, then each bridge needs to assign in it's BAR the range of all its children, including all sub bridges, recursively
<zid>
cat version: I have no food and I must scream
<geist>
anyway i'll tackle that a bit later, want to fiddle with MSIs right now
<geist>
someome here abot a year ago was doing all this PCI BAR calculation for riscv
<zid>
gpus have some weird new memory allocation thing they can do now though
<zid>
I forget what it's called
<geist>
right, prefetchable memory
<geist>
that's also a wrinkle, sicne the bridges track that separately
<zid>
no, a new mapping thing
<zid>
that lets them map all their vram
<zid>
they used to have to bank it
<zid>
pci-e 4 and up or something
<heat>
resizeable bars
<zid>
that's it
<heat>
that's a capability in the pci device
<zid>
yea but presumably it complicates precisely what we're talking about
MiningMarsh has quit [Read error: Connection reset by peer]
MiningMarsh has joined #osdev
* sortie
implements halt(8)
* sortie
. o O (STEVE HALT)
<gog>
there's always memory in the page file
<zid>
There's always lemonaide in my RAM
<zid>
it's surprising my PC boots
<gog>
that's not lemonade
* gog
zips up her pants
<heat>
apparently when resizing a bar you need to reassign the bridge's resources
<zid>
does that mean the address range the bridge decodes for, or something else?
<zid>
which was what I was worried about, you might run out of headroom.. but I guess you could just move it *literally anywhere else* on x64, just move it after the final bridge from its position
<heat>
zid, yea
<geist>
well, yes and no
<geist>
that's what i was talking about. there's some complexity there with the limited amount of 32bit space and essentially infinite 64bit PCI space
<zid>
I just wouldn't support huge BARs on 32bit, kind of expected imo
<geist>
and depending on the devices if they support it, or if the OS does, etc you can decide to put a bridge > 4GB and then you have a lot more space
<heat>
resizeable BARs can't advertise >4GB sizes for 32-bit BARs
<geist>
yah what i dont understand is what happens if you have say a 32bit only device on the other side of a bridge that has things also that need 64bit bars, etc
<zid>
If your device is asking for 36bits of memory by itself.. not a lot you can do about that
<geist>
seems like there are lots of invalid configurations that can be constructed if you try
<geist>
on x86 the location of the PCI bus *apterture* is more complicated and implicit. i'm not sure that's described in ACPI anywhere
<geist>
as in what bus addresses are available for you to assign to BARs
<zid>
PCI devices don't tend to have more than like 32MB of ram or whatever though so it can do what it likes for the most part
<geist>
from the logic i've seen in other systems it's a combination of parsing everything in ACPI and figurig out what isn't in use + some implicit per vendor logic (ie, TOLUD/TOLUD2 MSRs, etc)
<zid>
as a fraction of the address range it's ignorable, like using 64bit bars with modern gpus, the issue is modern gpus on 32bit bars
<zid>
In which case I'd just go "no bar resizing for you, sorry"
<geist>
FWIW some of the complexity of the PCI device tree entry is the fact that it seems to describe the valid range to assign PCI devices to, so that's nice
<geist>
since it can feed into your memory alloction algorithm
<zid>
"you get your 256MB window because I am a generous god, and that's it"
<geist>
side note, in case anyoe is interested i've managed to construct a fairly complicated bus topology via qemu command line
<geist>
i just keep adding things to it to randomly add things
<junon>
geist: any reason you don't use qemu config files?
<geist>
consider everything after -- to be directly added to qemu
<geist>
i have never used qemu config files. qemu supports config files?
<junon>
yes, surprisingly
<kazinsal>
same, that's new to me
<geist>
i usually just construct front end scripts that generate command lines for things
<junon>
they're an ini format
<geist>
that's what that `do-qemux86` script is doing
<geist>
oh ugh. then no.
<junon>
-writeconfig and -readconfig
<geist>
i mean i guess my life wouldn't be any better, because inevitably i want to have a script with a bunch of switches for things
<geist>
and then would have to have the same script just generate a config file
<geist>
and the command line works just as well
<junon>
I think they map 1:1 with command line arguments. Don't quote me though.
<geist>
well anyway i could see that being useful
<geist>
but doesn't really help me for this kinda thing
<junon>
e.g. -kernel foo.bin maps to [machine]\nkernel = foo.bin
<junon>
using -writeconfig
<geist>
oh i see you can have it spit out the config the command lines fed it
<junon>
not sure about everything else but I'd imagine it's the same. it'll be useful for writing automated test suites I think.
<geist>
and then reuse that. that might be helpful
<geist>
yeah
<junon>
yeah
<geist>
i might switch to that for my pile of VMs i run on my server
<geist>
but really right now i just have a set of scripts that do it
<junon>
I think they just treat it like a @cliargs file like a lot of utils do.
<heat>
it seems that any resource allocation in pcie goes like get sizes of the different resources (prefetchable 32, pref. 64, regular 32, regular 64, io), coalesce them into a single mini resource for the device, go back to the pcie port above you, coalesce every single resource address space of all devices under you into a single address space, ... until you reach the root bridge
<heat>
then you perform the allocation and distribute it all
<bslsk05>
github.com: edk2-platforms/Platform/Intel/PurleyOpenBoardPkg/Override/MdeModulePkg/Bus/Pci/PciBusDxe at master · tianocore/edk2-platforms · GitHub
sdfgsdfg has joined #osdev
<geist>
hmm, wonder if its possible for the capability list to change dynamically
<geist>
i dont think so
<zid>
I imagine they're not supposed to
<zid>
but the device could obviously do it
<geist>
so it's probably safe to scan it once and then hold pointers to various discovered capabilities (which is what im currently doing)
<zid>
I just build my own thing from the caps (which I then promptly delete because I only care about one thing so I just return it)
<geist>
yah last night i was going the route of building a whole object for every discovered capability, but really i think just an array of pointers to them would be sufficient
<geist>
and really not strictly necessary, since can still technically scan it every time
<heat>
i don't even bother building objects for the caps
<heat>
it's not performance critical
<zid>
I'll just keep it around indefinitely the moment any API requires it to exist
<zid>
but for now I just ignore most things
<zid>
PCI_CAP_COMMON_CFG is all I care about
<geist>
yah hvne't written code to scan the pcie caps. i dont think any of those are interestig to me at the moment
<geist>
though, virtio also has a bunch of vendor specific caps, so i'll probably need to add at least an api to get those too
<geist>
haven't looked into precisely what they're for or if they'r eneeded
<zid>
There's always the option of just requiring the virtio drivers to use a 'virtio' interface that grabs all those caps when the virtio master-code loads
<zid>
and don't bother with caps at all on the pci-e layer itself
<geist>
yah at the momenti'm just going to have the cap stuff be an api on the pci handle you get as a driver
fwg has quit [Quit: .oO( zzZzZzz ...]
<geist>
wanna look up your cap and access it? go for it, here's the api
<zid>
pci-e code grabs the caps entry from the pci-e device and shoves it into the device struct, virtio_net loads and uses the pointer to fill out a bunch of its internal stuff from that
<zid>
it's the only thing that cares about it so it makes sense from a compile time encapsulation standpoint too
<zid>
shove all the code into virtio-common.c or such, bam done
<zid>
if something else requires caps later, split virtio-common.c into pcie_caps.c and virto-common.c, blah blah
<heat>
i dont get it, why is memory base and memory limit on pci-to-pci bridges 16-bit?
<geist>
heat: there's another field that extends that
<geist>
adds the upper bits
<geist>
but i think those are also shifted 20 bits? so 12 of those 16 bits gets you a 4GB range
<geist>
and iirc 4 of the bits are unused or flags or whatnot
<heat>
hmm
<heat>
the shifted thing makes sense
<heat>
that's why memory base has no upper half
<heat>
64-bit BARs are required to be prefetchable
<heat>
therefore you have upper 32-bits for base, limit
<geist>
is my little code to dump it. warning may be bugs, but it seems to be consistent for the stuff i've dumped
<geist>
oh haha i see a bug right there on line 12
<geist>
buit there was some subtlety there with the 32 vs 64bit prefetchable thing
<geist>
ie, there's a flag in the bottom 4 bits that says whether or not the upper part is present, etc
<zid>
my netsec brain hates all this stuff
<geist>
at some point i'll go through it and write accessors and whatnot to encapsulate the calculations, but was just writing code to dump it, and explore the algorithms needed first
<zid>
It's a very strange mixture between the devices being pushy about how they will act, and you trying to be pushy back about where things will live
<zid>
and the devices can just ignore it, who knows
<geist>
yah
<zid>
pci-e is scary
<geist>
at least you have the disable button if the device is being really obstinate
<heat>
pcie is spooky
<heat>
i suggest platform devices and inshallah
<heat>
is it even a real platform if it has no .dtb
<geist>
i do recommend trying to grok the /pci* entry in device tree
<geist>
it is some hard to parse shit
<geist>
was designed in the 90s to be extremely flexible in how to describe things, and it shows
<geist>
lots of packed lists of things with variable sizes and some things build on earlier things you should have parsed, etc