<Mutabah>
j`ey: I don't like having to remember that a given piece of code is run without its address space being valid
lainon has joined #osdev
lainon has quit [Client Quit]
<heat>
I wouldn't write any of this code in rust either
<heat>
too high level
<Mutabah>
eh, you could do it the same as C. Might be a little bit more verbose, but not much
<heat>
I'm carefully balancing what kind of crap I can pull off without crashing anything
<heat>
this code is all running *at the wrong address*
<gamozo>
Hmmm. I wonder how QEMU's NVMe emulation compares to IDE versus virtio
<heat>
NVMe should be faster than virtio-blk
<heat>
virtio-blk is super simple, single queue
<geist>
hard to say, what is simpler for hardware is not necessarily simpler for software
<gamozo>
Hmm, yeah. I wonder if QEMU supports multi-queue NVMe
<gamozo>
It looks like it's a pretty thorough implementation of NVMe though
<heat>
yes it does
<gamozo>
Oh yeah it does, defaults to 64
<gamozo>
hot
<heat>
sus
<heat>
am I the only one who pronounces sctlr_el1 as scuttler_el1
<heat>
i need to know this
<geist>
gamozo: true, however it doesn't mean the added complexity doesn't just add up to additional overhead on qemu's side. most likely you wont see any perf difference in any of it except maybe additional/less cpu overhead in qemu itself
<heat>
it's workingggg
<gamozo>
For sure, I mgiht do a quick benchmark on it
<gamozo>
heat: is it!?
<heat>
PC=ffffffff80080098
<gamozo>
IS IT?
<heat>
fucking hope so
<geist>
nooooooice
<heat>
i should trust myself more
<heat>
I don't need no safety net at this point
<geist>
exactly!
<geist>
also i find it kinda fun to have to get creative debugging things
<heat>
geist, why do you invalidate the TLB before enabling the MMU?
<geist>
safety. in case there are stray TLB entries floating around from a previous set of code that had the mmu on
<clever>
heat: what if it has cached entries, that conflict with the new paging tables?
<heat>
hrm
<geist>
right, key is turning off the mmu doesn't implicitly flush the TLB, so if some previous firmware had run and turned off the mmu as soon as you turn it on the TLB is still active
<geist>
but you can flush the TLB without the mmu on. turning on the mmu doesn't really enable the TLB as much as it causes the cpu to start consulting it
<geist>
it's more of a stickshift vs automatic kinda thing
<clever>
what about the state of the TLB out of reset?
<geist>
was just about to say, it may also come up UNDEFINED
<geist>
i dunno what the ARM ARM says, but it's psosible it does
<heat>
UNDEFINED is scary
<heat>
IMPLEMENTATION DEFINED is also here be dragons
<geist>
there's some more subtle variant too, something like SPECIFIED UNDEFINED, or something
<heat>
ignoring an UNDEFINED is almost as scary as ignoring an RFC MUST
<geist>
basically it is undefined what the state is, but it'll be one of these N states
<heat>
oh shit just found UNPREDICTABLE
<heat>
even scarier
<geist>
but yeah if you think of the TLB (or the cache array) as being just a pile of SRAM then when you power up the core unless it actually goes through and resets it all, it'll come up with complete garbage in it
<clever>
geist: but there is also the trap, where the cpu consults the cache, even when the cache is disabled
<clever>
and an unexpected cache hit is an exception
<geist>
note as you power up secondary cores via PSCI and whatnot it's generally much more controlled, because the PSCI spec defines the power up state
<clever>
so the "cache line is valid" bit must be cleared, at a bare minimum, out of reset
<clever>
while the tag/data can be undefined
<geist>
in practice by the time EL1 code is running the cpu has been cleaned out pretty well, but if you're writing the EL3 firmware itself you have to handle the bootup state
<heat>
I like how gdb's info registers is way more detailed than qemu's
Likorn has quit [Quit: WeeChat 3.4.1]
<gamozo>
Makin some benchmarks now for disks. Why do I do this with my life
<heat>
you can just use fio
<gamozo>
nah, fio doesn't bench what I want it to. Well at least, from when I've tried/used it
<heat>
why?
<gamozo>
I don't know. But it doesn't seem to be an accurate indicator of disk performance from when I've tried it
<gamozo>
Maybe largely because I want to benchmark the whole FS stack
gxt has quit [Write error: Connection reset by peer]
<heat>
it can do filesystem, it can do raw block device, you can set it up in any mode, direct, with the aio library you want to use
<gamozo>
Personally, my benchmark is grepping the linux kernel
<gamozo>
I know it's powerful, I probably just am not using it right
<gamozo>
Random accesses inside of one big file is way different from many file accesses
<geist>
gamozo: be careful with zero blocks or not. IIRC qemu has a mode such that it detects zero blocks on the way out and nops it
gxt has joined #osdev
<gamozo>
Idk if there's a way to do that?
<heat>
gamozo, it's not way different
<gamozo>
geist: Like with qcow dedup/compression stuff? I wonder if I can ignore this with a raw dd image?
<geist>
i noticed it because it's the main use of -enable-avx512f. it has some avx512 support in qemu itself for some fast zero block detection
<heat>
at the end of the day, it's a random seek
<geist>
probably will, of course will also show up presumably if you do tests with and without zero blocks
<gamozo>
heat: Yeah, but that's benchmarking random accesses to one file through the disk. That's not really benchmarking the filesystem's metadata stuff
<geist>
also you might want to play with different caching schemes for the disk
<gamozo>
oh, I'll dd urandom to make my img then LOL
<gamozo>
then I'll format it with whatever filesystem
<geist>
iirc it runs in maybe some sort of writethrough mode?
<heat>
mkfs may try to discard
<geist>
by default?
<heat>
(I think)
<geist>
yah. a raw imge without discard set will probably not punch holes in the file, but worth double checking
<gamozo>
Idk, I'll be curious to test. I really want to benchmark my storage server, and I haven't gotten fio to really accurately benchamrk it. I don't know if that's because it's really bottling, or I don't use fio right, or I'm just wrong about how hardwarwe works
<geist>
easy enough to see anyway with a du of the disk image
<geist>
yah FWIW i have my disk images mounted over NFS v4.1 and it's pretty good
<gamozo>
I'm gonna build a custom image though. Legit I think I'm just gonna build ripgrep and ripgrep chrome/firefox/aosp/linux kernel
<geist>
not amazing, but i can get a few hundred MB off it and it generally takes advantage of caching along the way
<gamozo>
To me, what I care about is grepping source. That's where I feel VMs always feel terrible
<mrvn>
heat: the ARM ARM is worse in a pdf viewer where you can open a link in a new tab.
<mrvn>
geist: Are you sure the apple M1 isn't running some secret EL3 in secure mode from internal RAM/ROM that you can't access? 8-P
sympt9 has joined #osdev
<mrvn>
geist: can EL3 drop the secure bit on itself?
sympt has quit [Ping timeout: 256 seconds]
sympt9 is now known as sympt
<j`ey>
"EL3 exists only in Secure state"
<j`ey>
"D1.4.1 The Armv8-A security model"
<mrvn>
geist: the D bit might be a clever way to support hardware and software dirty at the same time in different ELx. The hypervisor might do software dirty handling and the kernel sets the D bit and lets the hardware do it.
<mrvn>
Also for COW you want the exception but for a a clean page you can let the hardware change the RO -> RW.
<mrvn>
heat: on ARM you have to set the access bit on all entries if you don't want to get an execption right away when enabling the MMU.
<gamozo>
I have no idea how it's so noisy? QEMU/KVM reschedules on the host? I have no idea.
<mjg_>
you should plot this for easier comparison
<gamozo>
yeah, I will once I add some actually good benchmarks. This is compiled and run as /init in a ramdisk, so there's nothing else in the VM (no other noise)
<gamozo>
The concept is kinda cool, now I gotta make it actually do good benchmarks ahahaha
uzix has joined #osdev
uzix is now known as mahk
mahk has quit [Quit: WeeChat 3.0]
hongzhi has joined #osdev
hongzhi has quit [Quit: hongzhi]
puck has quit [Excess Flood]
hongzhi has joined #osdev
puck has joined #osdev
vdamewood has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
gorgonical has quit [Quit: Client closed]
hongzhi has quit [Ping timeout: 272 seconds]
vdamewood has joined #osdev
<gog>
mew
<mrvn>
are you filling the queue(s) to the fullest?
* vdamewood
peers at gog
* vdamewood
pulls out fishy
* vdamewood
gives gog fishy
<zid>
I gave you a hello and you ignored it
mahk has joined #osdev
dennis95 has joined #osdev
arch-angel has joined #osdev
pretty_dumm_guy has quit [Quit: WeeChat 3.5]
Vercas has quit [Quit: buh bye]
Vercas has joined #osdev
Vercas has quit [Remote host closed the connection]
<zid>
actually LA is too easy, make it play gameboy in my pocket demo
eroux has quit [Ping timeout: 240 seconds]
eroux has joined #osdev
gildasio has quit [Quit: WeeChat 3.5]
gildasio has joined #osdev
eroux has quit [Ping timeout: 240 seconds]
vdamewood has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
zaquest has quit [Remote host closed the connection]
eroux has joined #osdev
gxt has quit [Remote host closed the connection]
mahk has quit [Quit: WeeChat 3.0]
gxt has joined #osdev
zaquest has joined #osdev
X-Scale` has joined #osdev
X-Scale has quit [Ping timeout: 255 seconds]
X-Scale` is now known as X-Scale
mahk has joined #osdev
dude12312414 has joined #osdev
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
bauen1 has quit [Ping timeout: 272 seconds]
gxt has quit [Remote host closed the connection]
gxt has joined #osdev
gog has quit [Ping timeout: 256 seconds]
arch-angel has quit [Remote host closed the connection]
xenos1984 has quit [Quit: Leaving.]
bauen1 has joined #osdev
_73 has joined #osdev
<_73>
In unix OS's I understand the concept of every process getting their own private version of "the kernel". However doesn't there still need to be an overarching "the kernel" that runs for example the scheduler? I don't see how the scheduler could be run on behalf of a user process.
<mrvn>
what is a private version of the kernel?
<mrvn>
Unix OSs just have a global kernel.
<mrvn>
There are microkernels with recursive schedulers.
<zid>
locks
<zid>
all things are possible through prayer and locking
<_73>
I thought that every process got its own personal version of the kernel mapped into it?
<_73>
<zid>
*mapped*
<zid>
it doesn't mean it's all unique physical memory
<mrvn>
no, they all get the same kernel mapped into it
<mrvn>
or in moderm OSes often just a trampoline.
<_73>
So the kernel has its own process?
<zid>
padun
<mrvn>
no
bauen1 has quit [Ping timeout: 240 seconds]
<_73>
So what process is responsible for running the scheduler?
<_73>
<zid>
any of them
<mrvn>
none. the scheduler just is.
<zid>
they all see the same copy of the scheduling info structures
<zid>
and they've all got the same code
<zid>
so they'd all make the same decisions
<_73>
ohhhh
<zid>
usually you'd trigger it off an irq though
<mrvn>
when an interrupt, exception or syscall occurs you step outside of the process and the kernel runs.
<zid>
so it'd just be "whatever process happens to be running on core 0" or whatever your timer irq routing is like
bauen1 has joined #osdev
<_73>
Ok now that is more clear. I have another question though about the system clock though. The system clock interrupts the cpu at some predefined interval and then some kernel code is run. What software/hardware is responsible for producing the clock interrupts?
<_73>
<j`ey>
the clock :p
<zid>
the clock
<zid>
You could make your own if you like, find a spare interrupt pin and connect your wrist watch up to it
<_73>
Ok so there is a `the clock` hardware which interrupts the CPU which then knows to dispatch some kernel routine, which I am assuming among other things runs the scheduler.
<zid>
could do, if you want, y ea
<_73>
Ok my understanding is much better now.
<zid>
or a process might do read(), set up some writes into some device's "gib data pls" registers, then needs to disappear until the data is ready
<zid>
so will kick itself over to the sched code to get swapped out
<_73>
Doesn't the kernel needs its own thread that is not a member of any user process for running interrupt handlers (specifically the clock interrupt handler)?
<mrvn>
_73: so it would only process interrupts when the scheduler decides to run the thread?
<mrvn>
17:35 < mrvn> when an interrupt, exception or syscall occurs you step outside of the process and the kernel runs.
<_73>
Isn't there a difference though between a syscall though which runs in a kernel thread that is a member of the calling process (every process has its own kernel stack).
<_73>
I don't know if my vocabulary for `kernel thread` here is correct but I mean in terms of every process having its own kernel stack.
<mrvn>
whether every process has a kernel stack or not is a design decision
<mrvn>
or even if there is a stack at all
<_73>
Ohh its for efficiency because it would be expensive to swap in/out the kernel stack state for every process that is sleeping/waiting for a interrupt/syscall to return.
<mrvn>
No. A per process kernel stack is for suspending a syscall mid call and running other processes.
Likorn has joined #osdev
<mrvn>
On x86 you can also set different stacks for interrupts and exceptions. You have to do that for the double fault handler at a minimum.
<_73>
Ok now I understand thanks.
<_73>
dennis95 has quit [Quit: Leaving]
gildasio has quit [Quit: WeeChat 3.5]
srjek has quit [Ping timeout: 248 seconds]
gildasio has joined #osdev
heat has joined #osdev
<heat>
I finally have an interesting PCIe layout to share
<heat>
my new work laptop uses another PCI segment
<heat>
i wonder if the firmware is using the SRAM for the temporary RAM instead of the CAR
<heat>
srs biz laptop has all the bells and whistles
<zid>
what's a 10000:
<heat>
pci segment
<zid>
what's a 10000:
<heat>
pci segment
* zid
stabs
<heat>
pci segment
<heat>
welp i can die in peace knowing I have seen a cool layout
<heat>
my life is meaningless now
<mrvn>
Is that non-volatile ram or an nvme disk?
<heat>
NVMe
<heat>
unfortunately it's not that fancy
<mrvn>
I want non-volatile ram
<heat>
also has a RAID bus controller
<heat>
me too
<heat>
also USB4 and THUNDERBOLT
<zid>
THUNDERBOLT is also what my computer uses
<zid>
like 40kHz thunderbolts and a capacitor
<heat>
THUNDA
<heat>
BOLT
opal has quit [Ping timeout: 268 seconds]
<zid>
SANDA BORUTO
sympt5 has joined #osdev
sympt has quit [Ping timeout: 240 seconds]
sympt5 is now known as sympt
<heat>
ok this laptop is spooky
<zid>
my PC is 1000% spookier I guarentee it
<heat>
it turns on the fans for half a second randomly
<heat>
1) cooling is effective; 2) spooky
<heat>
it's not getting to 100C before turning them on, that's for sure
Likorn has quit [Quit: WeeChat 3.4.1]
heat is now known as _Heat
<sbalmos>
_Heat: oh interesting. I need to look at the layout of my (3mos old newish) work laptop, see if it's the same
_Heat is now known as heat
k8yun has joined #osdev
Raito_Bezarius has quit [Ping timeout: 264 seconds]
Burgundy has joined #osdev
srjek has joined #osdev
opal has joined #osdev
<bauen1>
heat: my laptop is just cool enough that the fan doesn't have to turn on all the time if i leave it idle (with firefox and things still open), so the fans turns on every now and then. but even if i stress the cpu as much as i can the fans don't actually spin up to true 100%, there's a key combination that does that however
<bauen1>
maybe someone just over specced the fan but it's weird
<heat>
a key combination?
<heat>
interrupt storm? lol
Raito_Bezarius has joined #osdev
_xor has quit [Quit: bbiab]
<mrvn>
maybe it's designed to compensate for cooling loss over time
pretty_dumm_guy has joined #osdev
Serpent7776 has joined #osdev
<chibill>
My MSI laptop has a button the forces all the fans on to full. But other then that it does cooling normally and will ramp that fans as needed. Might be something simular.
heat has quit [Ping timeout: 240 seconds]
heat has joined #osdev
xenos1984 has joined #osdev
<heat>
my cpu has avx512
<heat>
i'm available for interviews
<zid>
What is it like having a crap cpu?
<zid>
Imagine if they'd used that silicon for something useful, like 768MB of L3
<heat>
feels pretty good tbh
<heat>
liberating
<heat>
having avx512 cured my depression
<zid>
Freed yourself from the shackles of having a sane cpu
<zid>
You should go for alpha next
<heat>
alpha?
<heat>
but im sigma :/
Likorn has joined #osdev
_73 has quit [Ping timeout: 240 seconds]
<mrvn>
and what software do you run that even uses avx512?
<heat>
mrvn the fun ruiner
<heat>
apparently this kernel I'm running has a bug and my CPU really likes getting stuck at 400MHz
<heat>
even under load
<heat>
can someone shoot me?
<zid>
heat: someone ran an avx-512 instruction last week
_73 has joined #osdev
<zid>
you'll be at 400MHz for a few more days
<sbalmos>
only if you agree to it beforehand so the police don't classify it as a homicide
_73 has left #osdev [#osdev]
gxt has quit [Ping timeout: 268 seconds]
gxt has joined #osdev
<heat>
why is all firmware mouse support horrible
<mrvn>
because you don't have an amiga
AppXprt has joined #osdev
<heat>
this interface is all mouse but the mouse feels like its gliding in butter
<heat>
oh shit this isn't even UEFI
<heat>
this is built on FreeRTOS
mzxtuelkl has quit [Quit: Leaving]
<sbalmos>
heat: HP?
<heat>
dell
<heat>
fucking why
<geist>
heat: so the 1000 segment thing
<geist>
we saw that at work the other day and looked at it. it's actually not real
<heat>
what
k8yun has quit [Quit: Leaving]
<heat>
not real?
<sbalmos>
great, so now our hardware is lying to us that much more
<sbalmos>
I don't know who to trust in life any more
<geist>
the segment 1000 is virtual, made up by linux. there's a device in the root bus that if it's enabled (which it is right now) pretends to be a new bus, but isn't actually doing it according to the pci spec
<heat>
ohh
<heat>
the RAID controller?
Likorn has quit [Quit: WeeChat 3.4.1]
<heat>
must be?
<heat>
this sucks huh
<geist>
it's basically a fake fictitious device that claims a set of mmio/etc and then there's a driver in linux that repubishhes that as a new device
<geist>
yes its the raid controller
<geist>
i think the idea is it takes the devices it's going to raid, squirrels them away under its own umbrella and takes the out of the pci space effectively, and then pretends to be a raid, i think
<geist>
but it still has to map them *somewhere* so that the OS can initialize, etc. i think
<geist>
or it's just some way to 'claim' the dvices so some software raid knows what devices are part of it, i dunno
<geist>
anwyay if you disable the raid stuff it goes away
<sbalmos>
and even wackier version of driver-driven not-quite-software RAID
<geist>
yah
<sbalmos>
Man what were those on-mobo "RAID" controllers back in the early 2000s that were all the rage? Rainbow?
<geist>
promise maybe
<mrvn>
crap
<geist>
they were for the while the defacto way to get more IDE and then sata ports on your machine
<geist>
and they also sold 'raid' versions of their cards which were just software o course
<heat>
what's SRAM good for?
<geist>
in what context?
<geist>
vs DRAM in a generic sense?
<heat>
yes
<heat>
I understand that its used for caches
<heat>
BUT its being served here as a PCI device
<heat>
so its not that
<bauen1>
heat: additional RAM that doesn't need the special dance DRAM requires ?
<geist>
dunno, i'm sure there's something more you're not mentioning
<heat>
I know that some server platforms use SRAM instead of cache-as-ram
<heat>
but apart from that, i dunno
<geist>
generically having sram on pci is probably not useful enoguh to make a pci device, but it may be used for some other purpose
<heat>
says Intel Corp....... Shared SRAM
<geist>
what's the vidpid?
<heat>
8086:a0ef
<zid>
can confirm, tiger lake lp shared sram
<zid>
how many volts does that thing want at 400MHz
<geist>
huh interesting dunnp, how big is the mmio apertureon it?
opal has quit [Remote host closed the connection]
<heat>
16k and 4k, both in 64-bit space
wowaname has joined #osdev
<heat>
actually most of this platform's BARs seem to be 64-bit
<heat>
cool
<geist>
yah makes sense. mostly stuff on bus 0 since it doesn't have to deal with bridges
<heat>
it only has a single device that's not on bus 0
<heat>
(and the fake pci devices)
<zid>
heat: did you dump the AML yet
<zid>
Mine has all sorts of fun things like TO BE FILLED IN BY MANUFACTURER number of usb ports
AppXprt has quit [Quit: Client closed]
pretty_dumm_guy has quit [Quit: WeeChat 3.5]
<geist>
ugh. well crap, server locked up again. i think i'm just cursed with this cpu being a server
<geist>
only remaining piece to start swapping out is the ram, though it's ECC and i *assume* that if there were overt errors they would simply generate ecc errors
<mrvn>
do you check for them? You have to enable the drivers for that
<geist>
for ECC? no. it just picks it up. no drivers needed
<geist>
or at least the drivers are built in
<mrvn>
no, for the errors
<geist>
in the past i've always just seen messages on dmesg
<mrvn>
probably automatic module loading
<geist>
though i see no message in the linux boot, but usually i just see a machine check when i get an ecc failure
<geist>
but i haven't seen one on this machine, which maybe is an interesting data point
<mrvn>
i think there is an edacd too that reports the ram slot the error was
<geist>
yah that beng said when i've seen ecc errors before they were with the previous cpu (ryzen 2700x) which is a Zen+. so possibly the Zen2 (3950x) that i replaced it with has a lesser/different/not functionting ECC
<geist>
however if it was really corrupted ram i'd expect to see the usual signs of ram corruptions, like random processes crashing, etc
<geist>
i see none of it. it runs like a champ right up till when it simply stops
<bslsk05>
lunduke.substack.com: Linus Torvalds threatens to punish developers by putting Rust in the Linux Kernel
<mjg_>
i thought rust already landed
<mrvn>
better rust than lua (zfs)
<Griwes>
ugh, I keep jumping around my unwinding and C++ abi library needs but after trying a bunch of things out, I think I need to probably just clench my teeth and write my own thing from scratch -.-
<mrvn>
Griwes: do you need rtti and exceptions?
<Griwes>
yeah, I'm at a point where I want to start building a serious C++ wrapper around syscalls
<mrvn>
you want to turn syscall errors into c++ exceptions in userspace?
GeDaMo has quit [Quit: There is as yet insufficient data for a meaningful answer.]
<Griwes>
Some of them, yes
<heat>
youre a crazy man with crazy ideas
<heat>
and i appreciate that
<heat>
we will be watching your career with great interest
GNU\Test_User is now known as \Test_User
<Griwes>
(mind you, in syscall *wrappers*; the raw form of syscalls will never do that)
<heat>
oh
<heat>
booooooooooo
<heat>
my idea was way crazier and cooler
<heat>
propagate exceptions through the kernel and into user-space
<heat>
how cool is that? very cool I'll tell you that
<\Test_User>
it's about as cool as requiring C++ for all programs
<heat>
it's about as cool as requiring C for all progr-oh wait
<bauen1>
\Test_User: I don't think anything prevents you from turning the exception into something actually usable such as a Rust Result ?
<mrvn>
Just return std::expected from syscalls. easy enough to provide a C wrapper for it as well
<heat>
nooooooooooo
<\Test_User>
bauen1: but that requires stuff inbetween :P
<\Test_User>
heat: current syscalls work easily through assembly and about 100 other languages that support working with a raw abi
<heat>
propagate exceptions
xenos1984 has quit [Read error: Connection reset by peer]
<heat>
\Test_User, in practice, current syscalls require C
<heat>
you're just replacing C++ with C here
<\Test_User>
using C with syscalls I find annoying due to errno
<\Test_User>
with the syscall abi it's returned then C sets it to the errno special variable thing
<Griwes>
mrvn, but then I need to care more about the ABI than otherwise
<Griwes>
the base abi of the syscalls will be far more stable than any C++ abis
<Griwes>
heat, lol. I don't have exceptions in the kernel :P
<mrvn>
\Test_User: syscalls don't use errno. that's a libc thing
<\Test_User>
yes
<\Test_User>
as I said, C sets it to...
<mrvn>
Griwes: that was for heat. But you could just return std::expected from your c++ wrapper
<Griwes>
not in ctors
<mrvn>
Griwes: a lot of errors in syscall aren't exceptional
<Griwes>
yes, hence "some"
<heat>
Griwes, that's not very C++ committee from you
<heat>
exceptions and RTTI everywhere
<heat>
pls
<Griwes>
lol
<mrvn>
heat: the c++ committee is working hard on making a freestanding without rtti and exceptions
<kingoffrance>
of course! the exceptional case is success. throw an exception on every success would simplify things so much
<heat>
throw EINTR works
<sbalmos>
ETEAPOT
<heat>
in fact it would super-work in a kernel
<mrvn>
Griwes: coroutines are nice for syscalls too, those that are async
<Griwes>
indeed
<heat>
I should play around with coroutines and async
<Griwes>
but, once again, that'll be in the wrappers :P
<mrvn>
obviously
<heat>
I have a dream
<Griwes>
I've done some coroutine wrapping of systemd dbus apis, you end up writing such pleasant code with those
<bauen1>
mrvn: tell me more about that, i haven't seen any attempt that makes the requirement of exceptions for error handling in constructors a thing yet ? Apart from that (and the lack of a try! macro) you can already have pretty decent error handling with a Result like type, e.g. expected
<heat>
a dream of a standard C++ system, where C++ exceptions can propagate from the microcode, through the firmware, through SMM, into the kernel, and ending in user mode
<Griwes>
you
* \Test_User
awaits that to turn into a js system where the cpu only executes javascript
<mrvn>
bauen1: constructors are bad. they can't return an error other than via exception
<Griwes>
you've got quite the insane dreams, heat
* \Test_User
runs
<mrvn>
bauen1: all your constructors need to be noexcept
<mrvn>
and never fail
<bauen1>
mrvn: well, just compile with -fno-exceptions for starters
<heat>
Griwes, and available for hiring
<\Test_User>
"constructors never fail" *runs out of memory*
<mrvn>
\Test_User: new can fail, that's different
<heat>
*tries to run out of memory*
<heat>
*memory doesn't run out*
<\Test_User>
ah
<bauen1>
mrvn: but yes, constructors are really bad, like there's some things rust probably doesn't do nicely, but the "lack of constructors" and error handling via Result are so amazing
<heat>
*malloc keeps returning valid pointers*
<heat>
*confused gaze*
<\Test_User>
heat: write 0 to them
<mrvn>
heat: turn of overcommit
<\Test_User>
then watch as stuff gets killed by oom-killer
<heat>
that won't work and no
<\Test_User>
perhaps not even the program doing it
<heat>
overcommit is good, and writing to memory doesn't mean it can't swap stuff out
<heat>
it totally can
<\Test_User>
it's not overcommit if you have swap for it
<heat>
yes it is
<mrvn>
heat: no, it isn't
* Griwes
mumbles something about rust evangelism strike force
<heat>
some systems even collect zero'd pages and replace those mappings with the zero page
<heat>
yes it is
<\Test_User>
it's committing the ammount of memory the system can possibly keep all at once
<mrvn>
heat: that's not how overcommit works on any sane OS
<\Test_User>
overcommit means committing more than you have ram+swap
<heat>
wrong
<heat>
Don't overcommit. The total address space commit
<heat>
configurable amount (default is 50%) of physical RAM.
<heat>
for the system is not permitted to exceed swap + a
<\Test_User>
it you set it to 300% it's still overcommitting
<\Test_User>
but at 100% it would not be overcommit, and that would be full ram + swap
<heat>
anyway, C++ exceptions strike force > rust evangelism strike force
<\Test_User>
good thing I'm on neither side of that >:)
<heat>
if you know of any codebase that uses -fno-exceptions or -fno-rtti feel free to write me a letter
<heat>
and yes, letters only
<heat>
i dont use email nor irc because those don't use exceptions
<mrvn>
heat: I will write you a bunch of letters: about every c++ kernel out there
<heat>
and we can fix that, together
* \Test_User
throws some exceptions at heat via IRC
<heat>
dynamic_cast is severly underutilized
<heat>
severely*
<j`ey>
heat: m8 ur on irc rite now
<heat>
oh
<heat>
but am i
heat has quit [Quit: Leaving]
<\Test_User>
"right now" not "in 30 seconds"
xenos1984 has joined #osdev
heat has joined #osdev
<\Test_User>
"right now" not "in 30 seconds"
<heat>
you're not going to believe this
<heat>
turns out
<heat>
C++ exceptions suck
<\Test_User>
s/exceptions //
<heat>
wtf
<heat>
C++ suck? seems 18+
<Griwes>
\Test_User, your substitution creates a grammatically malformed statement, I'm going to revoke your regex license
<\Test_User>
, s/$/s/
<Griwes>
I'm very sorry but I am required to do this
<\Test_User>
lol
<geist>
yeah it does interfere with my brain a bit too
<geist>
it's like a unmatched quote
<\Test_User>
it's
<\Test_User>
unmatched quote detected
<heat>
indeed, it's
<geist>
no, that's not a quote
<\Test_User>
it is, just not the " "
<geist>
LRN2PARSE ENGLISH
<\Test_User>
too bad, the key is a quote, just used as an apostr- however that's spelled
<geist>
it's a contraction, i know they don't use them on Vulcan, but we do here
<heat>
no, vulkan uses extensions
<geist>
eeeyooo
<geist>
so it's hot here. i'm melting. it's like 78F. MEEEEELTING
<heat>
25 is hot?
<heat>
25 normal units of course
<\Test_User>
78F isn't all that hot
<geist>
(it's a joke)
<\Test_User>
it was over 100 here not all that long ago :P
<geist>
tough crowd today
<heat>
booooooooo
<geist>
but it's the first time it's getting warm here in the PNW this year, so they have a HEAT WAVE WARNING and whatnot
<geist>
and it's like 78
<heat>
tbf it depends on where you're from
<\Test_User>
lol
<geist>
so the joke is i'm such a candy ass now
<geist>
being that i grew up where it was fucking hot all the time
<heat>
'murica
<geist>
well murica is big so it depends on where you are in it
<heat>
country built on extreme climates
<geist>
kinda yeah
<heat>
super hot, super cold, hurricane hotspot
<heat>
you can't win
<\Test_User>
or perhaps a mix
<geist>
dont forget tornadoes
<\Test_User>
and flooding
Likorn has joined #osdev
<sbalmos>
geist: I think they also classify a day without rain as a drought up in the PNW?
<\Test_User>
XD
<heat>
well, tbf from what I've heard, san francisco's weather isn't that different from what we have here
<heat>
so that's probably ok?
<geist>
kinda. yeah. thoug really here it does get quite dry in the summer. if symmer has really finally started here we probably wont get rain for 2-3 months before it starts again
<geist>
i think that's how everything keeps from rotting out. have to have a dry period of the year or it'd just turn into a swamp
<heat>
but then you live in the tech bro city so you may as well move out
<geist>
the secret is that PNW has fantastic summers, it just rains the rest of the 9 months of the year
<heat>
so its like the UK but with a summer?
<heat>
and minus the great accent bruv
<geist>
yah basically. i think a lot of UK ex-pats move here becuas eit's fairly close
<geist>
hmm, sbalmos is in SF?
<sbalmos>
geist: Cincinnati
<geist>
ah someone here was in SF. that's a bunch of weird microclimates
<geist>
i lived there for 3 or 4 years a while back and it was pretty weird
<sbalmos>
geist: I have a close friend in another channel who is an globe-hopper, sometimes spends time in SF. Yeah it's... weird. To put it mildly.
<geist>
most of the bay area is pretty much the same but once you go far enough north, north of about millbrae or daly city, you lose the protection of the mountains to the west and then you get this crazy fog that rolls in certain times a year
<sbalmos>
s/an/a/
gxt has quit [Ping timeout: 268 seconds]
<geist>
i rememer one day stanidng outside in the street and just watching this dense fog bank roll in. looked like one of those fantasy movies where the wall of fog just consumes everything
<jimbzy>
The Tule fog?
<sbalmos>
heh
<sbalmos>
Independence Day fog
<heat>
4/20 day fog
<sbalmos>
more likely
<geist>
tule fog (i just looked it up) is central valely, but i think it's the same idea. it's some sort of interaction with the cold water in the pacific and the warmer stuff that sits insde the bay basin
gxt has joined #osdev
<geist>
and the mouth of it is basically where the golden gate is. so some time during the day in the summer the wall of fog proceeds inwards and retreats later
<sbalmos>
geist: okay, more seriously, Daily Stupid Zircon Question time - why the separation of a channel from a socket? Aside from channel can send handles and socket can't.
<jimbzy>
Oh yeah, I'm thinking east instead of west...
<jimbzy>
Still not fun to experience.
<geist>
sbalmos: socket isn't datagram based like channel is
<geist>
it has streaming properties
<geist>
so it's kinda the diff between udp and tcp, kiiiiinda
<heat>
that seems confusing
<heat>
why not just a socket=
<sbalmos>
heat: That's where I was getting at
<geist>
personally i think sockets are silly, one of the cases where we were more pragmatic instead of pure
<geist>
i think some folks consider it a mistake, but it's load bearing now
<geist>
why not just a socket and not a channel?
<sbalmos>
geist: Being datagram-based, I guess I just see a channel as a "typesafe socket"
<sbalmos>
?
<geist>
no i mean they're pretty fundamentally different
<geist>
from a data carrying point of view, one is adatagram based, etc
<geist>
but channels have a lot of very specific properties, mostly in the way they can also carry handles
<geist>
and carry handles in a very specific packetized form
<heat>
can you splice() sockets or channels?
<geist>
which you wouldn't really be able to do with a socket easily without some complex packet boundary properties
<geist>
there is no splice()
<heat>
by design?
<geist>
well okay lets be alittle more clear. what part of splice are you thinking about
<geist>
splcie has lots of posixness in it that doesn't match up with zircon, but you're probably getting at one part of it?
<heat>
get page from socket-thingy and put the page into another socket-thingy (socket-thingy meaning socket or channel)
<geist>
ah. no. there's no reason we *couldnt* do that, but there are pretty specific properties of reading from a channel that would have to be carefully considered
<heat>
I don't know how networking is being done but splicing a page into a VM also seems useful
<geist>
for example if you had 8 handles in a channel message and you spliced it with another channel, would you consider the operation to be equivalent to unpacking the handles into the local handle spac,e and then repacking them (and thus going through the usual security checks we have in place)
<heat>
VMO*
<geist>
or would you explicitly state it as bypassing those checks
<sbalmos>
I guess conceptually it's the specialized handle-transfer behavior that really makes the big difference
<geist>
exactly. and there are specific constraints on the handle-transfer
<geist>
note you can do something like that with pipes in posix where you write FDs to it. and i forget how that works
<heat>
unix sockets, not pipes
<geist>
but this aside i think the sockets were a mistake because one *could* implement the entire sockets api on top of channels and perhaps shared memory
<heat>
SCM_RIGHTS
<geist>
but in a moment of pragmatism we added it to make network servers easier. in that case sockets are kinda like a posix pipe
<sbalmos>
geist: I think that's where I was also mentally going. A socket could just be bytestream-level channels
<geist>
which is basically what it is, except no handle transfer capability
<sbalmos>
oh well. like I said, Daily Stupid Question ;)
<heat>
but a channel is datagram based
<geist>
because then defining how handles get transferred gets complicated
<geist>
datagram based is easier to attach handles to, because you have these defined points where a packet of data is associated with 0 or more handles
<heat>
ancilliary messages work as fences between data
<geist>
also remember vmos are extremely easy to share, so it's very easy to transfer lots of data with channels by tossing a vmo handle with it
<dh`>
I think you mean "Operation not supported on socket"
<dh`>
sockets can only cry
<sbalmos>
ooo good point
<heat>
write works
<heat>
though not directly
<heat>
(hmmm... which is weird...)
<heat>
open should implicitly connect
<geist>
and there are lots of complex syscalls one can envision: for example what if yo uhad a combination syscall that read from a channel and auto-mapped each of the received VMOs into the target space?
<geist>
would be useful maybe. but being a µkernel, we have usual µkernel rules: implement the bare minimum for user space to do what it needs
<geist>
but then the caveat is if you have some feature you can add to the kernel that assists user space by some factor (ie, 10x easier to implement X if the kernel did Y) then we add it in
<geist>
and that's the pragmatic part of it
<geist>
hence how things like sockets came along, which technically overlap in feature set with channels
<geist>
and being designed by committe you end up with various warts. so it goes. cant win em all
<sbalmos>
it's 10x easier to implement a GUI if they kernel did graphics handling and widget definition
<geist>
right and you balance that against more hard rules like 'no guis in the kernel'
<geist>
or 'no drivers that aren't needed for kernel operation'
<geist>
however i do think there's room for kinda a middle ground of µkernels and monolithics: define a narrow subset of drivers that live in kernel space and put the rest elsewhere
<heat>
i bet there isn't a rule that stops you from adding a rust https server in the kernel
<geist>
like for example block devices or input devices: live in the kernel. filesystems? outside. build a largely IPC based system but places where it helps to shove lots of data through, avoid the context switching
<j`ey>
geist: can you link a userspace driver in fuschia?
<sbalmos>
geist: I suddenly had this bad vision of my VM allocator throwing off a E_NO_MEMORY_4_U permission denied error with a Soup Nazi-esque "no memory for you! Go away!" line.
<geist>
j`ey: what do you mean?
<heat>
j`ey, I like the nvme one
<heat>
src/devices/block/.../nvme.c
<heat>
something like that
<geist>
heat: oh side note, someone has rewritten it, i think it's in CL.
<heat>
oh fuck
<j`ey>
geist: sorry link *to* a driver, that I can look at
<geist>
it looks fine. mostly a modernizatino of it because it was clear it was in an unsupported state
<geist>
j`ey: you mean into the kernel?
<geist>
oooh lik as in url
<geist>
got it. i was thinking linker type of link
<heat>
geist, which language?
<geist>
yah //src/devices/block/.. are probably a good starting point
<geist>
/src/devices are where most of the drivers live
<geist>
yah it also has a mocked version and user space test cases, etc
<geist>
it is The Way
<j`ey>
so I assume 'zx_interrupt_wait' callls the kernel to be blocked eventually?
<geist>
yep. there's an interrupt object that you are bequeathed by the driver framework that you can block on
<geist>
there was some back and forth on why interrupt objects are special, vs just some event the kernel signals for you
<geist>
but it has some specific semantics that we decided to make it a dedicated object with a dedicated wait
<j`ey>
pci_map_interrupt(..)
<sbalmos>
The Last Will and Testament of Kernel Handle 0xff00887097f ... I bequeath this interrupt object to Foo
<geist>
yah all ukernels have to deal with the 'how does one get interrupts into user space'
<geist>
usually it's some sort of 'block on this and the kernel wakes you up' but for cases where you need to EOI it you usually have to have some sort of handshake to tell the kernel you're done
<geist>
i think that's what our interrupt objects do, IIRC. when you block on it again it'll intrinsically re-arm the IRQ
<sbalmos>
and that's not done through an Event Pair?
<geist>
that's not done via an event pair because otherwise you'd have to wire through some special cases of just that kinda event, etc for the re-arming effect
<geist>
iirc that may be the fundamental reason we have interrupt objects with their own blocking syscall
<sbalmos>
hrm
<geist>
for another ukernel i wrote a while back i had the kernel just deliver a fixed size message to a port (16 bytes iirc, standard ipc mechanism you could block on)
<heat>
you wrote another ukernel?
<geist>
but still needed some way to ack the IRQ or thekernel wouldn't easily know when it's ready to re-arm it
<heat>
open sauce?
<heat>
naw who tf is named sauce
<geist>
alas no. previous company to google, didn't get open sourced, and actually got thrown out because
<heat>
:|
<geist>
but learned a lot with that. was following the QNX model more than anything else
<sbalmos>
geist: ya I would think just another reply message to a port, like an IRQACK with an IRQ # payload or such
<j`ey>
it was probably a bootloader
<geist>
no, actually wasnt.
<heat>
believe it or not, there has been internal intel talk of using ring 3 in UEFI
<heat>
just sayin... the market is there
<geist>
it was a very deep cut of LK. removed all the primitives but IPC. VM was in user space, etc
<geist>
it was a pretty neat system
<geist>
was following the QNX model, synchronous ipc: two primitives, once is stream based, antother is fixed size messages. stream based connections were unidirectional and connetion oriented
<heat>
i should try stripping my kernel of its personality one day
<heat>
i... wonder if it works well
<geist>
if i were to build somethingl ike that again today i'd have to seriously ponder SMP though. this was pre-SMP so sync IPC is pretty straightforward in that model
<geist>
with SMP i think things get a lot more complicated there
<geist>
also makes it harder to build non-reentrant kernels etc which you can kinda get away from in a UP model
<geist>
get away with i mean
<heat>
how do you load the first program in a microkernel?
<heat>
do you flatten it to binary and the kernel then maps it
<geist>
couple ways to pull it off. one strategy is to have a 'smart' bootloader that simply pre-populates memory with the first program and tells the kernel 'pages X-Y have your process 0' and then the kernel simply creates a thread for it and starts it
<geist>
that's probably the cleanest strategy. your bootloader can then parse some sort of initrd and pick out /bin/init for the kernel
<geist>
but yeah i think most cases involve there being a flattened process 0 that bootstraps things further
<geist>
in the case of zircon it's somethig like that. process 0 is a flattened thing called userboot that is handed *all* of the priviledged handles the kernel has
<geist>
and then it has enough of an elf loader to load the real next process which then starts bootstrapping the real system and subdividing rights
<sbalmos>
the more I look at that, I like that idea myself too. userboot is the equiv of userspace stage 2 bootloader
<geist>
in the case of zircon at least userboot is fairly well paired with that exact kernel versino, so you can almost consider it to be the user half of the kernel
<heat>
bootloaders all the way down
<geist>
so the message it receives with all of the priviledged handles can be fairly specific
<sbalmos>
geist: how about userboot relinquishing its memory back once it's done?
<geist>
it does
<sbalmos>
crap I missed that
<geist>
well, didn't mention it, but it implicitly does when it exits
<heat>
SHAME ON THE HOUSE OF SBALMOS
<geist>
because handles are closed, refs go to zero, etc
<sbalmos>
heat: wouldn't be the first time
<geist>
the big memory blob that userboot gets is the handle to the initrd VMO, whch was created by the kernel at bootup
<geist>
it may be 100MB or so, and holds the bootfs which has all the important bootstrapping processes and drivers
<sbalmos>
right
<heat>
and userboot is just stuck to the kernel?
<geist>
so it passes it along to process 1 which among other things spawns proper driver instances and eventually yo uend up with a bootfs driver that holds a copy of the handle and vends out subsets of the vmo in file form
<heat>
through incbin
<geist>
heat: basically, though that'll change and it'll move out into the initrd itself
<geist>
but that was the initial strategy and works fairly fine
<heat>
but then you need a way to read the initrd
<geist>
same with the kernel VDSO
<heat>
microkernel checkmates itself
<geist>
yes, that's what our proper stage 2 loader (physboot) will do
<heat>
oh, so passed through a bootloader "module"?
<geist>
it's mostly just organizational cleanup, but it's moving in the direction of moving the VDSO and the userboot out of the kernel itself, but just putting it next to it
<heat>
that's what I was thinking of
<geist>
basicallly
<geist>
note in NT for example this is the sort of thing NTLDR does
<sbalmos>
ya that's nicer
<geist>
it even loads the root registry hive and finds where all the essential boot drivers are, loads them into the kernel, so that when the NT kernel properly starts it's handed a list of drivers that are already in memory
<geist>
it avoids the initrd style pivot that linux does, by just arranging for the drivers to already be there by the time NT kernel starts
<geist>
there's a table in there somewhere that has a list of drivers and if they're essential for boot or not
<geist>
downside is of course NTLDR.exe needs to be able to use the BIOS (or i guess UEFI, haven't thought about it in a while) to read the C: and parse NTFS to find drivers
<heat>
ntldr isn't a thing anymore
<heat>
I think
<sbalmos>
bootmgr
<geist>
oh possibly. ah
<sbalmos>
since Win 7 I thin
<heat>
correct
<geist>
ah, presumably it just does the same thing though? i doubt the kernel changed its architecture fundamentally
<heat>
bootmgr.efi
<geist>
in that NTFS.sys and your AHCI.SYS and whatnot are still separate modules that must be loaded by someone
<sbalmos>
bootmgr is the bootloader. But I think it's... winload.efi now? that does the detect and loading
<sbalmos>
just Googling back around at old info, it used to be ntldr was the loader, but there was ntdetect that did the initial hardware and core device driver detection
<geist>
so what happens when it's loading off of bios? it still supports that, at least up through 10
<geist>
11 i assume is uefi only
<heat>
arm64 question: is addr -> page table indices math still the same as x86_64 and riscv64? assuming 48 bits
<j`ey>
9 bits
<j`ey>
(with 4k page size)
<heat>
ok, so something is up and I don't know why
<heat>
what weird shit do I need to pull off after I map something?
<geist>
maybe that unisigned int i getting shifted is truncating to 32bit?
<geist>
make it uint64_t
<geist>
i think you were doing it your #defines but be very careful to use proper ULs and whatnot when defining these bits because of implicit intness of 1 and whatnot
<geist>
one of those things that bite you when switching from 32 to 64
<heat>
it's not even mapped though
<heat>
I get a data abort
<heat>
the permissions look right I think?
<heat>
even after going from uint -> ulong
<geist>
well what TTBR are you loading it into?
<geist>
or oh this is the kernel page tables
<heat>
TTBR1
<geist>
so what address do you expect this to be mapped to?
gildasio has quit [Quit: WeeChat 3.5]
<heat>
0xffffd00000000000
<geist>
hmm, why there?
<heat>
but then my fdt code hits a data abort on 0xffffd00048000000 (the FDT)
<heat>
idk, always used that
<geist>
that's what i'm getting at. make sur eyou're computing that properly. where is the kernel now?
<heat>
wdym
<geist>
where did you map the kernel?
<heat>
-2GB
<geist>
okay, so is anything else mapped 'below' the kernel?
<heat>
below meaning <? no
<geist>
okay, so then what top level page table entry did you use to start the physmap?
<heat>
I still have the trampoline page tables, but those shouldn't do anything here
<heat>
like index?
<geist>
yes
<heat>
I don't know, i'm blind here. could probably that code in godbolt and find that out
<geist>
basically what i'm getting at is a) 48 bit page tables in arm start at 0xffff.0000.0000.0000
<heat>
but it's taken straight from x86_64 and riscv64
<geist>
instead of 0xffff.8000.0000.0000 that you may be used to from x86 and riscv
<geist>
yes. that's my point
<geist>
each TTBR in arm gets a full 48 bits
<geist>
instead of being split in the middle like it is on x86/riscv
<heat>
ok so the math is different
<geist>
so if you start from index 0 in the TTBR1 it'll be at 0xffff.0000.0000.0000
<geist>
so double check your math that you're mapping it where you think you're mapping it
<heat>
but the top index should still be the top 9 bits, yadda yadda right?
liz has joined #osdev
<heat>
actually
<geist>
12 + 9 + 9 + 9 + 9
<heat>
yeah I think the math still checks out
<geist>
it just gets the full 512 entries per half
<heat>
yeah
<geist>
then why 0xffff.'d'...
<geist>
where is the 'd' coming from?
<heat>
shrug
<geist>
okay so then... fix it
<geist>
what top level index are you using?
<geist>
0? if 0 then your physmap will start at 0xffff.0000.0000.0000
<geist>
'd' is some.. oh i dont want to do the math to figure out which index that is
<heat>
looks like 416
<geist>
okay then secondarily, how much ram are you using on your qemu machine?
<heat>
512M
<geist>
if 0xffffd00048000000 is correct, then the 0x08000000 is 512MB into it. you ran off the end of ram
<heat>
actually, I know why it doesn't work
<geist>
sicne ram starts at 0x4000.0000 physically
<geist>
0x4800.0000 is top of ram
<geist>
er wait. no. never mind that's not right
<heat>
that's the FDT
<geist>
1GB == 0x4000.0000
<heat>
I figured it out
<geist>
anyway, cool
<heat>
my budget virt_to_phys doesn't work here
<heat>
it points to some rando place in memory
<heat>
(that doesn't exist)
<heat>
i forgot I'm not doing things like in the other archs
Burgundy has quit [Ping timeout: 240 seconds]
<heat>
I usually keep a 1-1 of physical to virtual in -2GB
<heat>
this time since I want to be physical load address independent I'm mapping myself at -2GB, period
<geist>
ah yeah. i'd suggest putting physmap at 0xffff.0000.0000.0000 that way the math to convert is very easy
<geist>
and yeah you basically have to do the independence because there's not a fixed load address on arm
<heat>
ok I may want to turn off all the debug flags now
<heat>
slow as ballz
<heat>
-d int,mmu,cpu that'll do it
xenos1984 has quit [Remote host closed the connection]
<heat>
geist, do you know how different the PL011 is from the riscv virt's uart?
<geist>
yes. completely
<geist>
just straight up a different uart. needs a different driver
<heat>
crap
<geist>
though *usually* if you just want to blat out some character syou can find the Tx fifo one and slam a character out
<geist>
works okay, though you usually want a loop on some sort of status bit to wait for the fifo to clear
<heat>
yes, I had that for riscv
<geist>
so usually on almost any uart ever made you can write a two line output driver, assuming the uart is already initialized: `while (!status.txfifo_empty); txfifo = c;`
<geist>
pl011 is no different. it's a pretty simple device and you can find the dox online
<heat>
yeah, found it
<heat>
what's the pl031?
<geist>
i forget. look it up
<heat>
oh rtc
<geist>
oh yeah. RTC
<geist>
IIRC its simply a 32bit counter that ticks at 1Hz.
<heat>
qemu's info qtree doesn't seem to have a valid pl011?
<geist>
so doesn't hae any of this H:M:S nonsense
<geist>
it's there
<heat>
mmio ffffffffffffffff/0000000000001000
<heat>
wtf I can't believe it
<heat>
"why is nothing changing?" *looks at the file's name* "arch/riscv64/virt-uart.cpp"
<j`ey>
*_*
mrvn has quit [Ping timeout: 264 seconds]
<heat>
ok I have a uart now
<heat>
gr8
<heat>
traps time?
<heat>
probably a wise choice
<heat>
i'm starting to actively enjoy porting to new architectures
<geist>
see? i dunno why but it's kinda a fun procedure
<geist>
and you see how different arches accomplish the same thing
Killaship34 has quit [Remote host closed the connection]
<heat>
yeah
<heat>
I think I just needed to get the hang of things
<heat>
the formula is usually the same
<heat>
learn enough of the mmu to make a bootstrap page table, get a physmap, uart, traps, mmu
<heat>
and then you're golden
<heat>
when I started with riscv it was kinda tough since I didn't even quite know what I needed to implement/stub out
<heat>
my kernel is arch-independent but the interface isn't very well defined of course
<heat>
but yeah, now with some practice I'm starting to find it enjoyable. but i'm a kernel weirdo of course
<heat>
doing platform bringup should also be fun but I don't have the secret sauces :(