<pmaz>
about how long would it take me to make an "operating system" that just displays "hello world" on the screen? would that take hours or months? sorry for the vague question
xenos1984 has quit [Ping timeout: 260 seconds]
<zid>
scales with how much you know what you're doing
<zid>
from 30 seconds to 3 days
xenos1984 has joined #osdev
xenos1984 has quit [Ping timeout: 260 seconds]
<pmaz>
i think 3 days is pretty optimistic for me
<pmaz>
things started to get pretty complicated somewhere between babystep tutorial 1 and babystep tutorial 2
xenos1984 has joined #osdev
wlemuel has quit [Ping timeout: 252 seconds]
<Mutabah>
For a bootsector, just using BIOS or VGA, it'd be a few hours.
ZombieChicken has quit [Quit: WeeChat 3.8]
<Mutabah>
For a 64-bit kernel using a framebuffer, probably a week or so (for a beginner)
<Mutabah>
but then, either of those are really an "operation system", and not really a kernel either
<Mutabah>
Maybe the smallest I'd call an OS/kernel would be having a working userland with a "print to console" syscall
wlemuel has joined #osdev
<zid>
"freestanding program" at best, but yea
<GeDaMo>
Forth! :P
<zid>
Mutabah: Mine has a 'print zelda to fb' syscall but no print
<Mutabah>
What zid said for an OS... for a "kernel" I'd accept loading a fixed program into userland
<zid>
(literally that's me)
<Mutabah>
for an "OS" it would have to load a replacable program (of disk, or from a module)
<zid>
Mutabah: can you make my kernel an OS for me
<Mutabah>
pmaz: Does that help answer your question?
<zid>
So far it runs zelda stored in a grub module
* Mutabah
glares at zid
<zid>
literally fixed program into userspace
<Mutabah>
Since it's from a module, I'd say it crossed the line between "bare kernel" into "OS" :D
<Mutabah>
But this is all personal semantics
<zid>
you're just trying to not need to do any work!
<bslsk05>
www.gnu.org: Multiboot Specification version 0.6.96
<zid>
which was updated into multiboot 2.0 that grub2 supports, but.. that's about it
<zid>
other things also support the regular multiboot proto
<zid>
importantly for us, qemu
<zid>
multiboot is just having a small data structure near the start of what you tell grub to load, and it sees it when it loads you and sets up the environment for you in specific ways
<pmaz>
it's probably obvious, but why is it called multiboot?
<zid>
it's a boot protocol that does.. various things?
<moon-child>
I assumed it was because it could boot multiple different oses
<GeDaMo>
Mooltipass!
<moon-child>
or multiple different bootloaders
<moon-child>
rather than being a protocol specific to a single os and bootloader
invalidopcode has joined #osdev
<pmaz>
so it wouldn't actually have to use grub, just a bootloader compliant with multiboot?
<zid>
yes, like, as mentioned, qemu can just do it directly via -kernel
<pmaz>
oh nice
<pmaz>
so the os would have to 1. tell whatever it's running on to set up a framebuffer and 2. get the location of the framebuffer and change it so pixels in the shape of "hello world" appear on the screen
Burgundy has joined #osdev
<pmaz>
is that right?
<zid>
if you wanted to do pixels, yea
<zid>
text mode is much more trivial
<zid>
'don't ask, just write text to 0xb8000'
<pmaz>
i think i want to use pixels so i can build on it easier
<pmaz>
thanks for all the info
<pmaz>
i have to go for now
wlemuel has quit [Ping timeout: 252 seconds]
wlemuel has joined #osdev
elastic_dog has quit [Ping timeout: 240 seconds]
elastic_dog has joined #osdev
foudfou has quit [Remote host closed the connection]
foudfou has joined #osdev
gildasio2 has quit [Remote host closed the connection]
gildasio2 has joined #osdev
<ddevault>
anyone have a simple NS16550 driver hanging around
gog has joined #osdev
<ddevault>
also, on ARM, if I have a device tree with no memory cells... how do I determine available general purpose physical memory?
<Mutabah>
That seems odd.
<ddevault>
oh I'm on EFI, right
<zid>
Using EFI instantly explains all insanity as usual
<ddevault>
ah, uboot has a relatively simple driver
<ddevault>
and the linux driver is not... not as bad as most linux drivers
<Ermine>
most are bad?
<ddevault>
if I liked linux too much I wouldn't be writing a kernel myself, eh
Jari-- has quit [Remote host closed the connection]
gnulinuxuser has quit [Ping timeout: 260 seconds]
invalidopcode has quit [Remote host closed the connection]
invalidopcode has joined #osdev
bnchs has joined #osdev
nyah has joined #osdev
eroux has joined #osdev
theboringkid has joined #osdev
slidercrank has quit [Ping timeout: 252 seconds]
pmaz has quit [Quit: Konversation terminated!]
bauen1 has quit [Ping timeout: 240 seconds]
goliath has joined #osdev
bauen1 has joined #osdev
dennis95 has joined #osdev
theboringkid has quit [Quit: Bye]
bnchs has quit [Remote host closed the connection]
invalidopcode has quit [Remote host closed the connection]
invalidopcode has joined #osdev
epony has joined #osdev
Brnocrist has quit [Read error: Connection reset by peer]
Vercas694 has quit [Remote host closed the connection]
Vercas694 has joined #osdev
vdamewood has joined #osdev
Arthuria has joined #osdev
Arthuria has quit [Killed (NickServ (GHOST command used by Guest684531))]
Arthuria has joined #osdev
Arthuria has quit [Remote host closed the connection]
Brnocrist has joined #osdev
kof123 has quit [Ping timeout: 268 seconds]
<netbsduser`>
xorg today drew its first checkerboard and 'X' cursor on my os
<netbsduser`>
and i am now in touching distance (i think) of getting xeyes to run
<vdamewood>
(o)(o)
<vdamewood>
Too bad I can't make the 'eyes' look up.
<nortti>
(°)(°)
<vdamewood>
Much better
<vdamewood>
Are those degree markers, or romantic ordinal suffixes?
<zid>
(>O_o)>
<vdamewood>
Google says degree markers
<zid>
romantic.. ordinal.. suffix? whaa
<zid>
oh romantic as in from rome I guess not smutty
<vdamewood>
zid: segundo --> 2º
<zid>
heh neat, it's gendered
<zid>
that's literally an o, as opposed to a ª
<vdamewood>
Yep, so you can also do 2ª
<vdamewood>
zid: FWIW, I've heard of these symbols being used in Spanish and Portuguese. Because French doesn't use a/o for gender, they don't use these symbols. I'm not sure about Italian or Romanian.
<zid>
This is the same confusion I got when the word digital is used
wootehfoot has joined #osdev
<vdamewood>
zid: Confusing fingers and number positions?
<zid>
vdamewood: I'm going to fuck you up, digitally
<zid>
So either over the internet, or I'm going to poke you to death, you get to live in fear until you find out
<vdamewood>
zid: At leat you're not going to fuck me digitally
<FireFly>
Gender: [ ] a [ ] o
bgs has joined #osdev
jcmdln has left #osdev [#osdev]
[itchyjunk] has joined #osdev
bauen1 has quit [Ping timeout: 255 seconds]
bauen1 has joined #osdev
kof123 has joined #osdev
wootehfoot has quit [Quit: Leaving]
Brnocrist has quit [Ping timeout: 240 seconds]
wootehfoot has joined #osdev
Brnocrist has joined #osdev
joe9 has joined #osdev
Burgundy has joined #osdev
Brnocrist has quit [Ping timeout: 255 seconds]
heat_ has joined #osdev
heat_ is now known as heat
<heat>
hello
<sakasama>
vdamewood: ... but that's the best kind. :(
* sakasama
hands heat a random pastry.
<heat>
you motherfuckers just found out about o/a
<heat>
cringºª
<heat>
thank you sakasama
<heat>
is it poisoned
<sakasama>
Not yet.
* sakasama
winks.
awita has quit [Ping timeout: 240 seconds]
Brnocrist has joined #osdev
<zid>
heat: I have more vindaloo
<zid>
are you proud that the goans fixed your cuisine and made it edible
xenos1984 has quit [Ping timeout: 265 seconds]
xenos1984 has joined #osdev
wlemuel has quit [Ping timeout: 252 seconds]
<heat>
yes
invalidopcode has quit [Remote host closed the connection]
invalidopcode has joined #osdev
xenos1984 has quit [Ping timeout: 246 seconds]
<heat>
my new lenses will take a few days to be ready :( i thought i was going to see well yesterday, but nope
<heat>
i've had poor-ish eyesight for 2-3 years now
wlemuel has joined #osdev
<heat>
the eyestrain has sucked :(
<GeDaMo>
Glasses or contacts?
<heat>
glasses
<heat>
i find contacts yucky eye shit so
<zid>
Have you considered getting new eyes
<heat>
yes
<zid>
some nice pretty ones out of a young girl, i'm sure you've got the people who can sort it
alexander has quit [Quit: ZNC 1.8.2+deb2+b1 - https://znc.in]
<bslsk05>
'Gary Gilmore's Eyes (Radio Edit)' by The Adverts - Topic (00:02:14)
alexander has joined #osdev
xenos1984 has joined #osdev
alturmann1729 has quit [Ping timeout: 255 seconds]
vdamewood has quit [Read error: Connection reset by peer]
vdamewood has joined #osdev
<heat>
i didn't know the shitty HTML docs on arm's website can be downloaded as proper pdfs
<heat>
lifechanger
<netbsduser`>
this is terribly frustrating, trying to run xeyes, libX11/xcb just waits forever on a socket waiting for a message from the X server which never comes (they do exchange a few messages before this)
<heat>
yes I've had similar issues
<heat>
probably a broken UNIX sockets impl?
<netbsduser`>
it's certainly possible
<netbsduser`>
i can't find any immediate issue though
<netbsduser`>
someone connects, all goes well, one guy sends, another guy receives, poll/select/read wait for the needful
<netbsduser`>
i don't know enough about x11 architecture to comment but it does appear that xeyes is waiting for a message at a time after it's already received data, when i wouldn't expect any further data to arrive since it has not sent any further data to the x server
<netbsduser`>
i built with XTHREADS 0 which i wonder whether that might be causing any problems, perhaps the threadless codepaths are bit rotted
<heat>
time to get threads? :v
<heat>
straying from linux/bsd codepaths sounds like it could go terribly wrong
<netbsduser`>
i think it might indeed be time
<netbsduser`>
i have kernel threads but don't expose the concept to userland so it hopefully wouldn't be *too* much effort
<heat>
haha
<heat>
so, erm, it depends on how you want to do things. also if your libc is your own, etc
<heat>
writing a pthreads impl is not trivial
<netbsduser`>
it's mlibc, which has the remarkable ability to turn a few basic sysdeps into a pthreads imlpementation good enough for managarm to run xorg
<heat>
ofc there's also the question if you want to do things a-la linux/BSD(?) with the processes that share a lot of shit
<zid>
heat wtf someone put spices in this vindaloo
<heat>
thank you goa
<zid>
like, it's REALLY hot, even for a vindaloo, wtf
awita has joined #osdev
Arthuria has joined #osdev
wootehfoot has quit [Ping timeout: 255 seconds]
vismie has left #osdev [#osdev]
invalidopcode has quit [Read error: Connection reset by peer]
invalidopcode has joined #osdev
slidercrank has joined #osdev
duthils has quit [Read error: Connection reset by peer]
vdamewood has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
vdamewood has joined #osdev
<geist>
mmmm vindaloo
<geist>
haven't had good vindaloo in a while
<jimbzy>
Same, and it's my own fault. I was working at an restaurant a couple of weeks ago and they offered me a free meal, but I had other calls to run. :(
<jimbzy>
a, not an
<heat>
geist, how do you know what IRQ the generic timer triggers? device tree/soc datasheet?
<geist>
heat: arm64 i assume. the 4 different timer vectors will map to 4 in the PPI space
<geist>
almost always something like 28-31 or something like that
<geist>
technically the device tree describes it, in practice i think it's pretty much the same 4 everywhere
<heat>
I think it's "compatible = "arm,armv7-timer";"
GeDaMo has quit [Quit: That's it, you people have stood in my way long enough! I'm going to clown college!]
<heat>
and i assume the interrupts property then properly describes it
<bslsk05>
github.com: lk/qemu-virt.h at f1431b81d0318b1c33d9ef01268efb773a93217f · littlekernel/lk · GitHub
<geist>
but yeah it's more properly described in the device tree, i dont remember how
<geist>
27-30 i guess. i dont know what tends to map to 31
<heat>
yeah but that's cringe because generic kernel images are kooooooool
<geist>
sure. if you wanna go that route by all means, just means you gotta parse more device tree
<heat>
device trees kind of suck but tis the way
<zid>
your one kernel image should support every single arm soc
<geist>
LK is torn between the two, because it's also frequently used *as* the bootloader that reads and/or configures the device tree
<geist>
so it has to also operate in the mode where it doesn't get to read it
<heat>
yeah totally
<zid>
even ones with less memory than the size of the kernel, due to how much shit you put in it
<geist>
but if i had the time/energy i'd probably do kinda what we did for zircon which is define a new platform called 'generic arm' and then have that one platform read everything from the device tree
<geist>
and then you get the best of both worlds, as long as each driver generically gets its config from somewhere else
<geist>
ie, no assumption of device tree or static or whatnot outside of the platform layer which is responsible for getting that info from somewhere
<heat>
yeah
<heat>
i have several drivers that take their info from ACPI and/or device tree, depending on what CONFIG features were enabled
<geist>
anywya for the ZBI structure for zircon in the generic timer case i think it basically passes on two pieces of info: which timer to use (virtual, physical, etc) and what IRQ its mapped to
<heat>
doesn't make sense to include device tree code for x86_64 builds
<heat>
likewise, may not make much sense to include ACPI on smaller arm/riscv boards
<geist>
yah same principle applies though: x86 generic platform would get its info from somewhere else (ACPI/etc) and the rest of the code would be pretty agnostic
<geist>
totally
<heat>
kernel PC is a weird mix of fully static + dynamic (ACPI)
<geist>
note that you can decide not to do that and end up smashing arch and platform together. there's even some folks asking at work why we maintain the two layers in zircon since there's now a 1:1 mapping of a single platform (arm generic) to an arch (arch arm)
<geist>
but i think the layering still helps, since it helps you logically separate the two
<geist>
other folks dont see the need for the distinction
<geist>
but that's debatable. that's basically the linux strategy: mash arch and platform together. id ont like it, but it works reasonably well in practice
<zid>
that's because linux is ruthlessly practical
<geist>
it's very x86 centric, where realistically there always was one platform for x86 arch
<zid>
rather than idealistic
<heat>
arch and platform aren't really together?
<heat>
the difference is that platform bits are spread out across drivers/ and (maybe) arch/
<geist>
yah the drivers are out of arch, which is good
<geist>
more like the core logic that says 'where does the config come from, how do i initially set up the hardware, etc' tends to live in arch/something
<heat>
like the gic stuff is in drivers/irqchip/, and you as the guy making the .config just say CONFIG_IRQCHIP_GICV3=y and dun
<geist>
arch/arm/board/... or whatnot
<heat>
hmm yes
<geist>
the BSDs tend to split the platform and arch like i do in LK, just with different names
<geist>
i like to think of arch as more of a leaf node library too, but that's just my pref
<geist>
probably because early on when was doing osdev back in the formative years i actually had in my possession a few machines (that i never really wrote code for but planned to) that were basically PCs with non x86s in them
<geist>
notably the Pegasos II PPC machine and a Sun Blade 100
<geist>
both of those were standard PC south bridges with a PPC and a sparc where the cpu was. so that had taught me that you could make a generic PC platform and arch was not quite dynamic, but at least a build config option
<geist>
they had PICs and PITs and 640k memory hole and everything
<heat>
woah
<heat>
that is something
<heat>
all the drawbacks of PC and none of the advantages of non-x86
<zid>
Try a PS3 then
<heat>
erm, advantages of x86
<zid>
It's x86 but isn't a P
<zid>
PS4*
<zid>
It's x86 but isn't PC
<geist>
i think that was more popular in the 2000s before x86 stuff started getting merged into the main x86 SOC. when the x86 was still just sitting on a bus and there was a proper northbridge (cpu bus + memory controller) and a southbridge (everything that was a PC) you could just buy a southbridge chip and build a machine around it
<heat>
isn't it still very-PC?
invalidopcode has quit [Read error: Connection reset by peer]
<geist>
PS3? no not at all
<jimbzy>
Ahh, I was gonna say.
<heat>
no, PS4
invalidopcode has joined #osdev
<geist>
PS4 is pretty PC
<jimbzy>
I thought the ps3 used cell microprocessors.
<geist>
yah ps3 was hella not PC
<geist>
PS4 still has some wonkyness where as a big PCI device there's this Marvell ARM chip that acts like a secondary IO processor kinda thingy
<geist>
i bet the got rid of that nonsense in PS5. haven't looke dat a good architectural teardown of that
<zid>
marvell aeoila
<zid>
it shows up as every single pci device
<zid>
and all the "normal" PC stuff that still wasn't onboard by then isn't there
<jimbzy>
One of the worst I've ever heard of is the Atari Jaguar.
<geist>
yah basically they're running some RTOS on the marvell cpu, and it shows up on PCI, which is a feature of that particular marvell chip
<zid>
like some of the PIT/PIC/etc stuff
<jimbzy>
I used to chat with a programmer and he absolutely loathed that console.
<geist>
also allows the PS4 main cpu to power off while the PS4 downloads stuff in the background, etc
<zid>
so the serial ports are over pci, not io ports, etc
<zid>
no superio thingy
<geist>
main storage and i think eth are over on the marvell too
<geist>
iirc that was one of the reasons it didn't really help to install a SSD on a PS4, the bandwidth was capped by the marvell SOC
<geist>
iirc ps4pro fixed some of that design, but i dunno how
<nortti>
"The data of indexed store instructions is not subject to any score-board protection. This means that the data written may not reflect what the programmer intended if the data is the result of a long latency instruction, that is divide or external load."
<jimbzy>
That's funky.
<geist>
yay manually scheduling instructions to avoid hazards!
<nortti>
"Description: The blitter pointer registers, which are written at addresses F0220C and F02230, appear for read at F02204 and F0222C. This error was also present on version 1 silicon.
<nortti>
Work-around: Read them at the incorrect addresses."
<jimbzy>
I always wanted to try one, though. That, and the Commodore CD32.
<jimbzy>
Erm Amiga CD32
<nortti>
"If either a JUMP or JR instruction is executed from external memory it is possible for this to align with the memory interface in such a way that the pre-fetch queue ends up holding invalid data. This means that these instructions can not be safely executed out of external memory."
<nortti>
"There is a bug in the divider: if it tries to do two consecutive divides without there being one clock cycle of idle between them, then the result of the second divide will be wrong."
<Griwes>
"we'll just fix that in software", said every hardware engineer ever
wlemuel has quit [Ping timeout: 240 seconds]
<geist>
thats why low level software folks continue to have jerbs!
<zid>
Imagine writing a compiler and then unwriting it
<zid>
because the software said your compiler is too perfect
rnicholl1 has joined #osdev
wlemuel has joined #osdev
dennis95 has quit [Quit: Leaving]
<heat>
geist, qemu tcg doesn't speculate does it? does it even have a tlb?
<heat>
well, speculate beyond what the native CPU does
<heat>
like if I map something on arm64 and don't dsb + isb
<heat>
heck, i don't even do proper break-before-make atm
<moon-child>
I wonder if there is a good strategy for emulating tso arches on non-tso arches
<moon-child>
taking advantage of the fact that most data is only ever touched by one thread. Maybe you make exclusive accesses way cheaper but concurrent accesses way more expensive
<zid>
make shm page fault
<zid>
deal with it there
<moon-child>
yeah something like that. I mean, not that, but something like that
<moon-child>
(mainly because threads)
bauen1 has quit [Ping timeout: 248 seconds]
bauen1 has joined #osdev
dude12312414 has joined #osdev
awita has quit [Ping timeout: 252 seconds]
<geist>
heat: i think it has a TLB. the page translation definiteily doesn't run on every access
<geist>
unclear exactly how big it is and/or how much you're likely to hit a TLB mis-management issue
<geist>
but it stands to reason you absolutely could
<geist>
as far as speculation, naw
<geist>
oh reminds me, qemu 8.0 was release
<geist>
as well as gcc 13.1
<geist>
kinda recently both
<geist>
qemu i didn't catch because i think they moved to a new git repo, and the github mirror hasn't been updated in some time
<geist>
(qemu moved over to gitlab it seems)
rnicholl1 has quit [Quit: My laptop has gone to sleep.]
<heat>
oh gcc 13 is out?
<heat>
"GCC now supports AMD CPUs based on the znver4 core via -march=znver4. The switch makes GCC consider using 512 bit vectors when auto-vectorizing."
<zid>
no?
<heat>
hahaha
<zid>
they build the changelog as they go, but afaik they have not cut a release have they?
<geist>
oh oh. sorry not out yet
<geist>
frozen for release. sorry
<heat>
thank you geist now im sad
<geist>
<pat pat>
<zid>
you can build it heat, we believe in you
<geist>
but qemu 8!
<zid>
If make's jobserver is active, parallel LTO WPA streaming communicates with it and thus avoids system overcommitting.
<geist>
but really the problem i have with RV is the fact that there's no way to detect this feature set. it relies on the string being found in device tree, etc and parsed
<mjg>
geist: irc has a line limit, i don't rmeember what it is. chances are the message would have been turncated otherwise
<geist>
so as a result *everything* needs a name, because you have to be able to discover it at run time by parsing that string
<geist>
technically it's more forward thinking than bitmaps in a register i guess, because new extensions can appear and you can ignore them
<geist>
and it can grow arbitrarily large
<geist>
and you avoid the mess that is layers of cpuid
<geist>
but still. it has it's own annoyance
xenos1984 has joined #osdev
<epony>
I sort my flags by year of addition to the arch..
<moon-child>
512 chars i think?
<moon-child>
or, no, 510 for some reason
<moon-child>
including the entire command, not just the content of the message
Halofreak1990 has quit [Quit: Konversation terminated!]
<geist>
built qemu 8 and ran some stuff on it. seems to work, not that i expected it not to
<moon-child>
why does having bitmaps in a register prevent you from ignoring extensions? I mean, some bits are reserved for future stuff, but that's fine, and you just don't look at those bits
<moon-child>
one thing I wonder about is
<moon-child>
whenever an extension is added that adds some new core-local state, the kernel needs to know about it, in order to save/restore that state per thread, so userspace can't just start using it right away
<geist>
yeah i know, but eventually you run out of registers so you have to add more, etc
<moon-child>
why not just have the core say the size of all the core-local state dynamically, and handle saving/restoring on its own?
<moon-child>
I guess one issue is the format isn't portable, so you can't easily do stuff like criu
<geist>
that's what x86 eventually arrived at after 4 or 5 variants of it
<geist>
(xsave, etc)
<geist>
but of course you need to save all the previous ones
<moon-child>
but that's not dynamically sized, is it?
<geist>
it is
<geist>
you have to do this dance of querying it to figure out the size, add extensions, etc
<geist>
it's a PITA but relatively clean. the hard part is then writing code to go inspect the contents
<geist>
since it's dynamically sized
<moon-child>
it looks like the format is basically tied down
<moon-child>
and the kernel has to say what stuff it wants to save/restore
<geist>
at least in the case of xsave it is tied down in the sense that there's a mechanism to discover where the subsections of the save state starts/ends
<geist>
right
<moon-child>
I'm saying it should just give you an opaque size, and the format is completely unspecified
<geist>
that's not usable, because softwaere frequently *does* want to inspect the contents
<moon-child>
if the cpu wants to add new registers later on, userspace software has to know about them if it wants ot use them, but the kernel should work unmodified
<geist>
it, reading the state of the vector state you saved
<geist>
alas it doesn't work that way in practice
<heat>
gcc 13 is coming out on the 26th
<heat>
we're almost there fellas
<heat>
we're this close to avx512 auto vectorization
<moon-child>
don't you have that already
<moon-child>
also autovec meh
<geist>
i dont have any machines with avx512 so it hasn't really excited me much
<mrvn>
moon-child: You mean like the way x86 saves FPU state?
<mrvn>
Could one say that PUSHA wasn't one of those too?
bauen1 has quit [Ping timeout: 265 seconds]
<mrvn>
s/wasn't/was/
<moon-child>
mrvn: no because both of those are fully defined architecturally
<mrvn>
heat: is that auto vectorization as in you specify the size of the vector you have and loop and it works in the max chunk size it can handle?
DynamiteDan has quit [Excess Flood]
<moon-child>
if you added a general-purpose register, you wouldn't be able to change pusha after the fact to push that register too
bauen1 has joined #osdev
<mrvn>
moon-child: sure you could. You would just have to have a register somewhere declaring the size PUSHA needs so kernels can reserve enough space.
<heat>
i hate device trees
DynamiteDan has joined #osdev
<mrvn>
moon-child: and all previous registers should end up in the same location as before.
<moon-child>
mrvn: you could make something like that
<moon-child>
but it's not what pusha is
<epony>
arm likes these
<mrvn>
push already does one thing for 16bit and another for 32bit
<epony>
seems to be adopting that from Windows device driver tree
<moon-child>
sure
<moon-child>
lots of things are different
<geist>
it's all sort of moot. neither arm nor riscv will ever add an instruction that does a huge pile of undefined microcoded work
<epony>
same mistakes and failures
<geist>
that is Not The Way
<moon-child>
mrvn: but pusha does the same thing for sse and avx
<mrvn>
as in nothing
<heat>
aktushally, i get it now. i love device trees
<epony>
no, you hate tables
<heat>
geist, have you seen a need for "proper" irqchip support or nah?
<mrvn>
Did x86 task gates save the FPU state when the fpu is enabled?
<heat>
i think the current scheme I have (similar to yours) with platform_unmask_irq, etc doesn't really model the hardware properly
<heat>
in some circumstances, that is
<geist>
heat: what do you mean irqchip that is?
<geist>
is that linux style nomenclature?
<heat>
yes-ish, also device-tree style
<heat>
irq controller, really
<geist>
so can you rephrase the question?
<geist>
sorry there's just a lot of implied something in the way you were asking it, and i can't tell what yuo mean precisely
<heat>
have you seen a need to properly model interrupt controllers in-kernel such that they make more topological sense instead of having an automagical platform_unmask/mask_irq
<geist>
topological as in heirarchial?
<heat>
yes
<geist>
or do you generally mean 'pluggable with a device model'
<geist>
ah. well, note that the platform* strategy doesn't not imply the heirarchial model
<geist>
it just becomes the platforms problem to sort that out
<heat>
for instance, in theory you can have two or more interrupt controllers in a system
<geist>
ie, question is does a *device driver* need to know about the way irq chips are wired up
awita has joined #osdev
<geist>
if not, then the api should be flat. but the sausage is made behind the api
<klange>
please do not make sausage with a computer
<heat>
the device driver? probably not. but the PCI driver, etc? maybe
<geist>
could be called something else other than platform, but something like irq_... and then there's some subsystem that sorts out the heirarchy (or not)
<geist>
perhaps in that model most drivers use the simple function that just takes an ordinal and does the job, and more complicated ones can reach in and grab a handle to the IRQ controller. probably still abstract, but.. you knwo
<geist>
LK is most certainly not a good model for any of this. it's far too simple for large systems
<heat>
yes
<heat>
I wanted to at least introduce the concept of an "irqchip" I could expose to userspace
<heat>
particularly because of irq rebalancing
<heat>
and pinning
* geist
nods
awita has quit [Remote host closed the connection]
<heat>
like, lets imagine a large system with 2 IO APICs. each IO APIC would have a single, internal irqchip representation. things like pci_get_irqn(device) would walk the firmware data (in the x86 PC case, MADT data), which would map INTA-INTD into a GSI, and then from the GSI you would be able to get the irqchip responsible for that
<heat>
i think this largely makes sense
<heat>
although I don't have enough experience to know if this maps mostly everywhere. for instance, I don't think device tree systems would enjoy the GSI idea
<heat>
as in those systems, you'd just have a different interrupt-parent. what's a GSI? who knows
<geist>
yeah though i think in the GSI case it's just flat outsode of PCs
<geist>
thats' just some layer of translation that you can hopefully hide away
<geist>
AFAIK pretty much no other modern arch has any sort of nonsense like that. external irq numbers are just flat
<mrvn>
or model it after the device tree.
<mrvn>
the device tree tells the driver where to get it interrupt from
Left_Turn has quit [Read error: Connection reset by peer]
<heat>
geist, 1) does inner/outer shareable, etc matter for qemu tcg? 2) what do I need to set for uncached device mem?
wlemuel has quit [Ping timeout: 246 seconds]
wlemuel has joined #osdev
terrorjack has joined #osdev
<Griwes>
> the lack of Liedtke-style masochism required for micro-optimising every bit of code
<Griwes>
presented without context
<Griwes>
are there any (actual or research) OS projects that attempt to allow for priority delegation through *asynchronous* IPC? I'm at a point where I'm wondering if I want synchronous APIs in the IPC thing most userspace ought to be using, and "can I do delegation without them" is one of the major questions I'm trying to wrap my head around, and google results aren't particularly helpful (the other major question is "are direct context switches necessary
<Griwes>
for good perf", but that one seems both more nebulous and also more of a "try it and see" question)
<heat>
ok i had a bug in my dt parsing code
<heat>
but I still need to figure out mmu attributes for uncached stuff out