<heat>
ok nerd i'm not kinkshaming your scat fetish
<bnchs>
inb4 i walk into osdev, talking about scat fetish
<bnchs>
okay bye!
<mjg>
heat: your mom introduced me to it
<mjg>
heat: she has a... weird taste
<mjg>
so there is this funny scheduler rolling with most pritmitive approach you can think of: round-robin
<moon-child>
heat: mjg
<mjg>
it happens to outperform something else, which has weird perf bugs
<mjg>
i tried to measure schedling latency but can't convince dtrace to keep up
<heat>
is that first one SCHED_4BSD
<mjg>
yes
<mjg>
anyhow the stats i did manage to obtain show over order of magnitude higher scheduling latency for the latter
<heat>
isn't that a multilevel feedback queue
<mjg>
as in time from showing up on runqueues to actually getting on cpu
<heat>
fwiw doing round robin in a multilevel feedback queue isn't weird
<mjg>
this one round robins across all cpus
<mjg>
0 affinity
<heat>
i do believe that most systems not named Linux do use such a scheme
<mjg>
or ht consideration
<heat>
huh?
<mjg>
it is a UP scheduler which got added provisional SMP support in early 200s
<heat>
thread 1 slice 0 runs on cpu0, thread 1 slice 1 runs on cpu1, etc?
<mjg>
before the new scheduler showed up
<heat>
or does it have a global thread list?
<heat>
is that what you mean?
<mjg>
it has a global runq list, but it does not push stuff around in the most primitive case
<heat>
i do find it super counter intuitive to have a global runq
<heat>
you need to go to weird lengths to not have a locking disaster there
<heat>
i guess you could offset the scheduler tick by some amount for each CPU, and that could help, but then irq latency, etc
<mjg>
first i'm going to get a full picture of what's going on, which demands i fix some bugs :/
<EthicsGradient>
mjg: F
<heat>
damn, you failed the class
<mjg>
i'm gonna enroll in different community college
<mjg>
anyhow there is botched assumptions all over
<heat>
capabilities are super unusable
<heat>
finally overrode my chrome flatpak's filesystem permissions
<heat>
i couldn't take the stupid ENOENTS due to sandboxing anymore
<mjg>
:]
money_ has joined #osdev
money_ is now known as money
Matt|home has joined #osdev
heat has quit [Read error: Connection reset by peer]
heat has joined #osdev
money has quit [Quit: late]
bnchs has quit [Read error: Connection reset by peer]
CalculusCats is now known as CalculusCat
CalculusCat is now known as CalculusCats
heat has quit [Ping timeout: 248 seconds]
heat has joined #osdev
money has joined #osdev
gog has quit [Ping timeout: 240 seconds]
money has quit [Quit: late]
crankslider has quit [Ping timeout: 240 seconds]
heat has quit [Read error: Connection reset by peer]
heat has joined #osdev
heat has quit [Read error: Connection reset by peer]
heat has joined #osdev
heat has quit [Ping timeout: 248 seconds]
bliminse has quit [Quit: leaving]
bliminse has joined #osdev
pg12 has quit [Quit: pg12]
zxrom has joined #osdev
elastic_dog has quit [Ping timeout: 240 seconds]
elastic_dog has joined #osdev
crankslider has joined #osdev
Sildara has joined #osdev
Sildara has quit [Quit: Konversation terminated!]
pg12 has joined #osdev
wootehfoot has joined #osdev
Ali_A has joined #osdev
GeDaMo has joined #osdev
gog has joined #osdev
Ali_A has quit [Quit: Client closed]
<gog>
hi'
<Ermine>
hi gog, may I pet you
<gog>
yse
* Ermine
pets gog
henloduud42069 has joined #osdev
henloduud42069 has quit [Client Quit]
henloduud42069 has joined #osdev
dennis95 has joined #osdev
* gog
prr
henloduud42069 has quit [Quit: Client closed]
<jimbzy>
yo
* kazinsal
gives gog scritchies
<gog>
hihi
* gog
prr
<lav>
nya
nyah has joined #osdev
<zid>
lav is some kind of summoner
<kazinsal>
we're entering the fractal catgirl dimension
<kazinsal>
the deeper you go the more headpats you have to give
<zid>
I tried to write a rust progrma yesterday, I got 2 seconds in before getting stuck
<zid>
The example uses () as a parameter to a function
<mjg>
i looked at rust after few months
<mjg>
forgot how atrocious the syntax is
<kazinsal>
I'd like to learn how to rust
<kazinsal>
what with my eventual plan to write a new, more performant kernel core and bolt my other crap onto it it would make sense to use a fancy modern systems programming language that does memory safety stuff
<kazinsal>
if the language can help stop me from writing horrible overflow bugs and shit it's probably a good language
henloduud42069 has joined #osdev
<mjg>
php has this property and is a great counter example
<mjg>
:X
<zid>
Wrapping all your array accesses in pascal checky stuff also does the same thing
<zid>
rust just does that for you
<kazinsal>
careful, we're nearing april fools
<kazinsal>
someone might decide to write a bootloader in PHP
<mjg>
or an os in rust
<zid>
OS in rust seems easier than a program in rust
<zid>
no need to return anything from mai
<zid>
main
<nortti>
< kazinsal> someone might decide to write a bootloader in PHP ← alas, have another project for this year
<kazinsal>
I was going to do Fourth Edition Unix for the IBM PC 5150 but work got in the way :(
<nortti>
oh, as in, taking the sources and getting it to run on a pc?
<kazinsal>
nah, was gonna do a complete clean room reimplementation
<kazinsal>
recreate v4 from the manual
<nortti>
ah, probably better idea yeah. from what I understand unices before v7 were not really portable
bgs has joined #osdev
henloduud42069 has quit [Quit: Client closed]
dutch has quit [Quit: WeeChat 3.8]
Left_Turn has joined #osdev
<gog>
how are you going to write unix for a 5150
dutch has joined #osdev
<zid>
I've never had that nokia
<zid>
how does it compare to a 3210
<gog>
well, it's built like a brick shithouse so you know it's a nokia
<nortti>
looks like there's no nokia 5150. there's a 5160 tho, which is the north american specific version of 5110
<zid>
seems 5150 is about the only model number they didn't use
<ddevault>
why am I writing another EFI bootloader
ss4 has joined #osdev
<ddevault>
why am I firing up hexdump to pick through a PE32+ header again
wootehfoot has quit [Ping timeout: 256 seconds]
ss4 has quit [Remote host closed the connection]
wootehfoot has joined #osdev
bnchs has quit [Remote host closed the connection]
henloduud42069 has joined #osdev
henloduud42069 has quit [Client Quit]
nightemissions has joined #osdev
<zid>
Because you love uefi
<zid>
It's your most favouritest thing ever
Ali_A has joined #osdev
Ali_A has quit [Client Quit]
<ddevault>
fucking EFI stubs
<ddevault>
I wish the loader would give any feedback at all
<zid>
Maybe I should make an EFI TOOL
<zid>
That prints a bunch of diagnostic about an efi image
<zid>
Zefi.0.log
<ddevault>
I guess I need to set up an edk2 build environment
<ddevault>
I am not happy about this
<zid>
I'd help but I am currently too blind
nightemissions has quit [Quit: Client closed]
wootehfoot has quit [Ping timeout: 240 seconds]
elastic_dog is now known as Guest9423
Guest9423 has quit [Killed (platinum.libera.chat (Nickname regained by services))]
elastic_dog has joined #osdev
Arthuria has joined #osdev
<Ermine>
ddevault: why are you writing another EFI bootloader?
nightemissions has joined #osdev
<ddevault>
for x86_64
<ddevault>
as opposed to aarch64
rnicholl1 has joined #osdev
dude12312414 has joined #osdev
xenos1984 has joined #osdev
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
<geist>
should be able to use more or less the same codebase
<geist>
with just a few ifdefs here or there
<zid>
#ifdef ARM entire codebase #else entire different codebase #endif
<zid>
:D
nightemissions has quit [Quit: Client closed]
<geist>
wel l my point is almost all of the UEFI stuff is the same between them
<geist>
except the final handoff, and maybe some oft he logic, so you should be able to have a single code base that you just compile for different architectures for UEFI
rnicholl1 has quit [Quit: My laptop has gone to sleep.]
rnicholl1 has joined #osdev
rnicholl1 has quit [Client Quit]
<ddevault>
the EFI stub is, per usual, the hardest part
<ddevault>
and lack of PIC for Hare on x86_64
<zid>
Hare?
<geist>
que esta hare?
<Ermine>
Bnuy
Brnocrist has quit [Ping timeout: 276 seconds]
zxrom has quit [Remote host closed the connection]
zxrom has joined #osdev
EthicsGradient has quit [Quit: WeeChat 3.7]
EthicsGradient has joined #osdev
xenos1984 has quit [Ping timeout: 260 seconds]
xenos1984 has joined #osdev
<gog>
hare hare
<gog>
hare rama
<lav>
kanin kanin
Brnocrist has joined #osdev
nightemissions has joined #osdev
duthils has joined #osdev
hmmmmm has quit [Read error: Connection reset by peer]
Arthuria has quit [Remote host closed the connection]
nightemissions has joined #osdev
bgs has quit [Remote host closed the connection]
GeDaMo has quit [Quit: That's it, you people have stood in my way long enough! I'm going to clown college!]
crankslider has quit [Ping timeout: 255 seconds]
zxrom has quit [Quit: Leaving]
<Halofreak1990>
I'm having a weird issue with my recursive mapping
<Halofreak1990>
So, I've mapped the page directory to itself, and I have a higher half kernel mapped in. My math says the kernel page table should be accessible in the last 4MB of virtual memory (0xFFC00000), at address 0xFFCC0000, however, Qemu tells me it's located at 0xFFF00000. Anyone have an idea what I'm doing wrong?
<gog>
what's the index of the recursive map?
<Halofreak1990>
it's the last entry in the page directory, which itself is accessible at 0xFFFFF000
<gog>
ok
<gog>
where are you mapping the kernel, 2GB or 3GB?
<Halofreak1990>
3GB
heat has quit [Read error: Connection reset by peer]
<gog>
cool, so the page table for the kernel should be at 0xfffff000 + 768 then right?
heat has joined #osdev
nightemissions has quit [Quit: Client closed]
<gog>
sorry, the PDE for it
<Halofreak1990>
yes
zxrom has joined #osdev
<gog>
ok, then think of it like this
<gog>
the page directoy is its own page table'
<gog>
each page table manages 4MiB of space
<Halofreak1990>
hmhmm
<gog>
so the page tables are going to be in sequence in the upper 4MiB of virtual memory
<gog>
FFC00000 is the start
<gog>
that's where the page table for 0-0x400000 would be
<Halofreak1990>
yeah
<gog>
so FFF00000 is 3/4 of the way down that area
<gog>
3GIB
<gog>
so that's the right place
<Halofreak1990>
Oh, wow. You're right
<Halofreak1990>
been staring at this for hours
<gog>
yeh
<gog>
wait til you try to do it in long mode
<gog>
:D
<gog>
it's actually the same tho, you don't have to map the PML4 to itself
<Halofreak1990>
thx for the help
xenos1984 has quit [Ping timeout: 240 seconds]
<gog>
np
gruetzkopf has joined #osdev
xenos1984 has joined #osdev
dutch has quit [Quit: WeeChat 3.8]
<heat>
recursive mapping is cringe and bad
<zid>
recursive cringing is heat
vdamewood has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<heat>
but srsly when will we stop recommending recursive mappings
<heat>
i'm fairly sure no real design out there does this
<heat>
and it has really non-obvious footguns like having to invalidate a bunch of TLB on page table changes
<clever>
what makes recursive mappings special? dont you just map the area of ram the tables are held in?
<heat>
well they're recursive because they use this hacky fact that you can map the top level page table on itself and have it work out
<heat>
like top_pt->entries[last_entry] = top_pt;
<heat>
versus doing direct mapping of page tables such that page N is mapped to one page, page N + 1 is mapped to another, etc
<clever>
so you have a chunk of physical memory, equal to whatever the top-level chunk size is, mapped at the last chunk?
<heat>
no
<clever>
the next level of paging tables, is stored starting at top_pt->entries[0] ?
<heat>
what ends up happening is that page table walking on that last entry will end up interpreting the top page table as the next paging level
<clever>
ah, yeah
<clever>
but that only works if you dont map page 0
<heat>
and this has the weird property of implicitly mapping page tables with $formula
<heat>
and, ya know, it's a cute idea but severely limited
<clever>
i might only use that as a bootstrap, so i dont have to recursively allocate each level before the mmu is online
<clever>
and so the top_pt is mapped, and the kernel can change the mappings once its in virtual space and has a proper memory management
<clever>
but in my last trip thru MMU code, the hugepages at the top level, where not too huge, so i was able to get away with only 1 layer permanently
<heat>
ok so doing the bootstrapping early on is super annoying
<heat>
i generally do this by making architecture code map $amount of physical space directly at boot time
<bslsk05>
github.com: rpi-open-firmware/mmu.c at master · librerpi/rpi-open-firmware · GitHub
<clever>
this just allocates the entire top_pt->entries in .bss, and then fills it with a simple incrementing pattern
<heat>
like, on x86 my first assembly stub maps the lower 4GB of memory, then I take those lower 4GB of memory and use a bit of those for auxiliary page tables that I may need to create the large direct mapping
<clever>
but this is also identity mapped
<clever>
but, i can picture how i might do basic init like this, in pure asm
<heat>
but once the large direct mapping is fully up, it's up, no need to bother with it again
<heat>
but ofc all of this bootstrapping is very fucky, in any case
<clever>
so i could implement what i linked in asm, and link the kernel to run at 0x800_0000
<clever>
oops, one more 0
<clever>
and once the kernel is running on that bootstrap table, malloc works normally, and the heap will stick around for the life of the kernel
<heat>
in theory, yes, could work
<heat>
in practice big kernels have a few more layers of indirection between "have MMU up" and "have malloc()"
<clever>
and the physical page manager is part of that
<clever>
but as long as you can survive on the bootstrap table, until then, it should be fine
<heat>
I recreate the MMU tables again, initialize the page allocator, then initialize vm allocation and slabs
<heat>
the first two steps still under a special bootmem allocator because early boot memory allocation is hard
<clever>
i think the main thing there, is that you need to know the physical->virtual translations, so you can pick a physically contiguous range, and then write to it in the virtual space?
<clever>
to re-create the tables
<heat>
well I recreate them early enough that the architecture code still knows more or less what needs to be mapped, without even looking it up again
<clever>
yeah, if everything is hard-coded with #defines or whatever, they will agree on things