<heat>
"Fast Allocation and Deallocation with an Improved Buddy System"
* gog
allocates heat
<heat>
noooooooooo
<gog>
hey buddy
<heat>
this is a heat_to_page()->flags &= ~PG_buddy; moment
<heat>
I was reading a bit about linux's buddy earlier today, they have this really dumb+smart optimization where they don't allocate bitmaps, they just use the struct page's flags
<heat>
it's stupidly simple and effective and I'm disappointed at myself for not thinking of that before
spikeheron has joined #osdev
<heat>
gog, are u really my buddy btw
<gog>
yes
<gog>
<3
<heat>
if we both get freed do we become gogheat
<gog>
heatgog
<heat>
why do you want me to go first
<heat>
is this a trap
<Ermine>
should I bring the rings?
<gog>
you're a lower address
<gog>
that's just how it is
<kaichiuchi>
ah, this place hasn't changed one bit
<kaichiuchi>
warms my heart
<heat>
gog, are you too good for DMA?
<heat>
is that it?
<gog>
yes
<heat>
are you too special to be in the direct mapping?
<bslsk05>
'Pretenders - Brass In Pocket (Official Music Video)' by Pretenders (00:03:01)
<gog>
i'm special, so special
Vercas6 has quit [Quit: Ping timeout (120 seconds)]
Vercas6 has joined #osdev
heat has quit [Remote host closed the connection]
heat has joined #osdev
<heat>
gog, good thing we're in the same zone as we're buddies
<heat>
so you're not special
<gog>
:<
binls has joined #osdev
xvmt has quit [Ping timeout: 264 seconds]
Brnocrist has quit [Ping timeout: 252 seconds]
jafarlihi has joined #osdev
<jafarlihi>
Hey, I got MSDOS 6.22 from archive.org and tried running it with QEMU using 'qemu-system-i386 -drive format=raw,file=msdos.iso' but it says no bootable device found, what am I doing wrong?
<GeDaMo>
Maybe it's not a bootable ISO
<jafarlihi>
How hard is it to write a 8086 emulator and run MSDOS on it? Are there any resources for that?
<bslsk05>
www.dosbox.com: DOSBox, an x86 emulator with DOS
invalidopcode has quit [Remote host closed the connection]
invalidopcode has joined #osdev
FreeFull has joined #osdev
furt_box has joined #osdev
jafarlihi has quit [Quit: WeeChat 3.7.1]
diamondbond has joined #osdev
binls has quit [Remote host closed the connection]
xvmt has joined #osdev
gxt has quit [Remote host closed the connection]
gxt has joined #osdev
gordea has joined #osdev
gordea has quit [Client Quit]
xenos1984 has quit [Ping timeout: 256 seconds]
xenos1984 has joined #osdev
diamondbond has quit [Ping timeout: 260 seconds]
Vercas6 has quit [Remote host closed the connection]
Vercas6 has joined #osdev
gxt has quit [Remote host closed the connection]
xenos1984 has quit [Ping timeout: 256 seconds]
Vercas6 has quit [Ping timeout: 255 seconds]
gxt has joined #osdev
Vercas6 has joined #osdev
gordea has joined #osdev
xenos1984 has joined #osdev
Vercas6 has quit [Quit: Ping timeout (120 seconds)]
Brnocrist has joined #osdev
epony has joined #osdev
invalidopcode has quit [Remote host closed the connection]
invalidopcode has joined #osdev
gxt has quit [Remote host closed the connection]
gxt has joined #osdev
diamondbond has joined #osdev
Vercas6 has joined #osdev
[itchyjunk] has joined #osdev
y0m0n has joined #osdev
Burgundy has quit [Ping timeout: 265 seconds]
mahk has quit [Ping timeout: 265 seconds]
Burgundy has joined #osdev
y0m0n has quit [Ping timeout: 265 seconds]
diamondbond has quit [Quit: Leaving]
Vercas6 has quit [Remote host closed the connection]
Vercas6 has joined #osdev
rwxr-xr-x has joined #osdev
Vercas6 has quit [Ping timeout: 255 seconds]
gxt has quit [Remote host closed the connection]
Vercas6 has joined #osdev
gxt has joined #osdev
<geist>
msdos didn't come in isos. you installe dit from floppy
<geist>
where did you get an iso?
<geist>
real 6.22 (i actually have real master disks for it) was on i think 3 disks
<geist>
back on those days computers didnt really have cdroms, and if they did the bios didn't know how to boot from it, so it wouldn't have made any sense to distribute it on an iso
<geist>
but if someone *did* put it on an iso and it's an actual cdrom image, you probably want to load it with `-cdrom msdos.iso` instead of -drive
<gog>
freedos comes in an iso
dude12312414 has joined #osdev
<geist>
interesting. guess that's designed to not run on old hardware, or at least would come with a boot floppy
<geist>
that was common for say early NT on cdrom: boot disk to get it started so it canread the cdrom
<geist>
boot floppy disk
<kaichiuchi>
those days make me happy
GeDaMo has quit [Quit: That's it, you people have stood in my way long enough! I'm going to clown college!]
dude12312414 has quit [Remote host closed the connection]
<mrvn>
It might be an iso with the frist floppy as floppy image.
<mrvn>
2nd+3rd on the cd
rwxr-xr-x has quit [Ping timeout: 256 seconds]
bauen1 has joined #osdev
<geist>
either way you probably need to make sure qemu knows it's a cdrom instead of a disk
<geist>
hard disk that is, hence -cdrom
gamozo has joined #osdev
rwxr-xr-x has joined #osdev
invalidopcode has quit [Remote host closed the connection]
invalidopcode has joined #osdev
<mrvn>
indeed. Unlikely the iso is also a hybrid HD image.
<mrvn>
can you mount the iso? What's on it?
<heat>
god I just had a great sleep
<heat>
how's everyone doing today
<mrvn>
went shopping, it's cold outside.
<mrvn>
still watching Wednesday, can recommend that.
<mrvn>
not getting any work done....
Vercas6 has quit [Ping timeout: 255 seconds]
<kaichiuchi>
i don't get any work done because I overthink every decision
<kaichiuchi>
instead of just accepting everything is terrible.
Vercas64 has joined #osdev
FreeFull has quit [Quit: Night]
<kaichiuchi>
for those of you who do kernel development in C++, how do you guys do anything like std::function? or do you guys just pass raw pointers as one might expect
<clever>
kaichiuchi: the only c++ feature i'm really using baremetal is classes, so functions are grouped with the state naturally
<kaichiuchi>
I see
<clever>
none of the fancy new c++ features
<kaichiuchi>
this is for an embedded project, and I'm quickly discovering that I'm almost writing C
<clever>
and ive gotten bitten by some legacy code that relied on constructors for global vars
<clever>
i have been accused of writing c in a .cpp file before :P
<kaichiuchi>
there can't be any dynamic memory allocation, and something like std::function *can* allocate
<kaichiuchi>
which honestly strikes me as, well, madness
<clever>
ive got dynamic memory allocation working in my code, but there is a line drawn, of when it can be used
<heat>
kaichiuchi, ok so std::function is very flawed sa you've seen
<clever>
because my code is also responsible for bringing the dram controller online
<heat>
and it's not good and not lightweight so I very rarely use it
<clever>
ultra embedded mode :P
<kaichiuchi>
heat: but then how do you handle lambdas with captures, if you even do
<kaichiuchi>
or do you just pass a userdata pointer like everything else
<heat>
what I usually do is for visiting-like patterns (imagine for_every_vm_region in a address_space class) I do something like template <typename Callable> void for_every_vm_region(Callable c)
xenos1984 has quit [Read error: Connection reset by peer]
<mrvn>
kazinsal: I think std::function is something you have to take from your compiler
<geist>
kaichiuchi: we actually solved that in fuchsia by building our own class template library that doesn't allocate. std::function is a particularly nasty one
<heat>
mrvn, wrong
<geist>
the solution we have allows for a finite size of args, but indeed it is not ideal
<heat>
it's entirely implementeable without compiler magic
<geist>
yah, it's particularly gnarly
<kaichiuchi>
I think std::function like stuff is the worst I'd ever have to write on my own for this project
<heat>
and, you know, honestly I haven't had many chances to think about std::function. I don't actually need it so to speak
<heat>
that iteration pattern covers 99.9% of the usecases in my kernel
<mrvn>
geist: isn't the size of args part of the template so you can make struct for it?
<geist>
yah we rarely use it in zircon, though partially because it's not generically useful, and partially because inlined lambda things work well enough
<geist>
mrvn: it's more complicted than that for reasons i completely forget
<heat>
mrvn, but that varies if you have a lambda, etc
<geist>
but what we have in ours is iirc a two word limit, which is also the limit of pass-by-value in x86/arm/riscv
<mrvn>
heat: lambda is the part I thought you need to use compiler stuff for
<geist>
so basically you can marshall up to a struct/class with 2 words before it bombs on you
<geist>
mrvn: nope. no builtins there
<heat>
if you can have a std::function<void(int)> f = [&](int a) {...}; AFAIK it's size is a lot different from a std::funcion<void(int)> f = [](int a) {...};
<mrvn>
i guess a lambda is a type like any other so you can store it too
<geist>
what you *can* do is lambdas with no capture will collapse to a regular function pointer, so you can use them nicely for things like 'register this interrupt handler' and then implement the handler in a lambda
<heat>
hmm, on this I'm not too sure about
<mrvn>
heat: [&] captures stuff but isn't the compiler doing that for you?
<heat>
but the gist of it is that you have like 2 or 3 different ways to call functions
<geist>
think of a lambda as the compiler generates an inline class with automatic captures and an operator () with a hidden type
<mrvn>
nod
<heat>
yes, I'm just unsure if the compiler does anything to copy it. maybe not
<geist>
with some special things like no capture means it can be just a function pointer, etc
<heat>
s/compiler/std::function/
<geist>
i have looked at a proper std::fuinction and ti's complicated as all hell
<heat>
yeah
<mrvn>
Does lambda have a copy constructor?
<heat>
having [](int a) -> int {...} be convertible is pretty cool
<heat>
implicitly
<heat>
I think C is honestly missing something like this, it's just neat and very useful
<mrvn>
heat: gcc has nested functions for that
<heat>
instead of having to separately define static callback functions etc
<kaichiuchi>
I think C could use a fair amount of things from C++, but only a small amount of things
<geist>
yah i've found it nicely solves the annoying 'need a static method that casts void * -> this and then calls the proper inner method' problem
<heat>
nested functions use shitty magic and always had
<geist>
hah yeah heat and i are no the same page here
<heat>
didn't they literally need an executable stack? something idiotic like that
<mrvn>
heat: they should be identical to lambdas so the same implementation from c++ should work.
<geist>
anyway just spent the last hour getting nvidia driver working on linux again after bios update
<heat>
yay
<mrvn>
auto name = [](...) ... is just a nested function
<geist>
forgot that this would wipe out my firmware TRM which then kills the signing of the nvidia kernel driver on linux
<geist>
so then it can't load it
<heat>
huh
<heat>
your firmware is buggy hahahaha
<geist>
the gist is had to find the right sequence of uninstalling and reinstalling so it'll re-run the script to generate a signing key and run a MOK installer on uefi
<heat>
a FW update shouldn't clear your fucking variables
<geist>
no, when you bios update it'll blow away firmware TRM modules
<geist>
it does
<heat>
but it's not OK
<geist>
sure, but that's whyy ou get a fixed TRM if you want it
<heat>
like all in all FW flash just gets divided into FLASH_CODE and FLASH_VARS
<heat>
you just need to flash FLASH_CODE on an update
<geist>
my guess is it's actually mandated, becaus eyou're updaing the firmware flash that's running the actual emulation
<geist>
so it probably by definition must drop all the saved state and start over
<heat>
afaik NO
<geist>
wouldn't be surprised if that's not specced somewhere
<heat>
let me see
* geist
shrugs, anyway, it's simply what happens. if i really cared i'd spend $5 and get a little module and plug it into the motherboard
<geist>
i already did that for my server, though haven't really figured out what to do with it
<geist>
honestly i dont really care, but this machine also dual boots windows and its definitely happier with secure boot enabled
<heat>
well, sure, it may happen but it's just poor behavior since you don't really need to do it
* geist
gets all upset and flips a table and kicks the dog
<heat>
praise the almighty IBVs
<heat>
nooo not the dog
<geist>
and then goes and cries on their bed, hugging pillow
<geist>
why! why you had to go and do that ASUS!
<heat>
it's not even ASUS
<heat>
blame AMI or Phoenix or whatever is doing that fw
<geist>
AMD i'm sure. the only real reason i applied it was it updates the AEGSA
<geist>
i'm guessing thats where the fTRM magic is done
<geist>
fTPM! that is. TPM
<geist>
i knew it was off, but forgot the acronym
<heat>
nah, AMD and Intel don't do customer solutions
<heat>
oohhhhhhhhhhhh
<heat>
ok yeah that's a whole different problem-set
<heat>
I was thinking of actual UEFI variables on flash
<geist>
yes that's what i keep saying. it's an emulated fTPM
<geist>
and thus that gets updated it wipes out its brains, if nothing else it may be a safety thing
<geist>
like 'version Y doesn't know what version X wrote so wipe it out'
<geist>
so in this case it lost the extra key i had added to it to sign the nvidia module in linux, etc etc
<heat>
yeah
<heat>
I didn't know you could store linux signing keys there
<heat>
I thought you were talking about the MOK and all that crap
<geist>
yah at some point during the module install it made me reboot and actually ran a little MOK installer UEFI app
<geist>
yes i am talking about that crap, but i suspect it's all managed in the fTPM
<heat>
well, not traditionally
<heat>
usually they are just variables in erm, flash
<geist>
ah, well i'd assume the TPM has something to do with it or you'd just be able to arbitrarily jam MOK stuff in the thing
<heat>
nah
<geist>
possible. in that case it's probably just because the BIOS lost all its settings, which it always does
<geist>
and thus your original hate is justified
<mrvn>
I want a B&W rubics cube like Wednesday has.
<heat>
so what happens is that you can only write to it in SMM because it's your trust boundary
xenos1984 has joined #osdev
<heat>
so you can tell if shit is getting jammed in authenticated (these kinds of secure vars) variables
<heat>
obviously as you may tell if your SMM gets compromised the attacker can do everything including adding its own secure boot keys or overwriting your flash with their own code
<heat>
praise be the SMM
<geist>
but i guess that's what secure boot is supposed to deal with, etc. if you secure boot everything nothing can compromise it in the first place
<geist>
the house of cards holds strong
<heat>
haha sure
<heat>
no exploits in SMM have been found, ever
<geist>
i dont believe it one bit, but hey nothing is better than easily compromised security that makes you feel better right?
<heat>
yeah totally, I'm definitely not saying secure boot is bad
<geist>
oh and also requires that you deal with MSFT, because they're calm and reasonable people
<heat>
it's just that the API surface of UEFI can be kind of big and SMM is a flimsy, insecure concept
<heat>
some vendors forget to lock SMM (so anyone in kernel mode can just use it), historically you've had exploits where you would move the APIC areas inside SMRAM and compromise that secure sandbox tht way lol
<jimbzy>
Talking about System Management Mode?
<heat>
yes
<jimbzy>
Ok. Just want to make sure I was on the same page.
<jimbzy>
I actually read the back buffer when I come around. :)
<geist>
oh yay new power supply for my apple 2 at the mailbox. i bought some replacement PSU bits from reactivemicro, which sells Apple 2 stuff for like 15 years
<geist>
and then turns out they ship from bremerton, which is like 10 miles away
<jimbzy>
Nice!
<geist>
so turns out when the RIFA caps blew the other day on my apple 2 power supplies (2! one after each other) they took out some other part of the circuit too
<kaichiuchi>
ugh.. I think for now I'm going to have to just say fuck it to lambdas with captures
<geist>
kaichiuchi: wise. this is where you learn what yuo can and can't do in bare metal C++
<geist>
think of it as a blank slate. dont assume you have any std:: available to you, and bring in only what you need and build up teh rest
<clever>
geist: my sound system has been glitching lately, some of the relays are turning off, cutting power to the amps, and they chatter a lot when turning back on
<kaichiuchi>
so I still need a `userdata` pointer :'(
<clever>
geist: cracked open the sub-woofer, and found that a high power resistor has toasted the pcb!
<geist>
kaichiuchi: yeah but this is where you can use a lambda to turn that back into a class pointer and call in
<geist>
works fairly nicely
<kaichiuchi>
right
<heat>
why can't you get lambdas with captures?
<kaichiuchi>
because this is bare-metal C++, I don't have access to std::function, I don't want to spend a lot of time right now coming up with an alternative
<kaichiuchi>
(to be clear, this is a game boy emulator that's supposed to work on an STM32 evaluation board for my own pleasure)
<heat>
i told you the nice pattern for doing things in a lightweight fashion
<bslsk05>
github.com: lk/e1000.cpp at master · littlekernel/lk · GitHub
<jimbzy>
clever, Is it newer hardware, because I have a friend who repairs audio amps who said he's been seing a lot of toasted R's.
<kaichiuchi>
heat: don't worry, I haven't discounted it
<clever>
jimbzy: old, to the point that the VFD has fadded
<kaichiuchi>
also another stupid question
<jimbzy>
Ah
veles2001 has joined #osdev
<heat>
geist, oh god that pattern is depressing
<heat>
and I do in fact have it all around the IRQ code
<geist>
yeah but beats the hell out of the pre-lambda mess
<kaichiuchi>
I really don't know the answer to this, but when using g++/clang++ bare metal, isn't `stdint` and the like still implicitly provided by the compiler
rwxr-xr-x has quit [Read error: Connection reset by peer]
<kaichiuchi>
let's assume I'm not using -ffreestanding for the moment
jafarlihi has joined #osdev
<heat>
yes/no/technically/theoretically
<heat>
ok, no -ffreestanding? no
<geist>
note you can -ffreestanding and then add back the compiler includes. that's what i do for the LK build
<kaichiuchi>
and with -ffreestanding I *have* to use `stdint.h`, not `cstdint`, right?
<geist>
basicallty start with a blank slate and add back includes and compiler bits as i need them
<jimbzy>
clever, I was just curious.
<heat>
-ffreestanding doesn't take away compiler includes
<heat>
-nostdinc does
<geist>
oh oh that yeah.
<clever>
jimbzy: with the way the relays chatter as it turns back on, i'm suspecting a voltage rail is weak
<jafarlihi>
For x86 "INC r/m8" instruction, if you provide CL register as r/m8, and if contents of that is 0b1111, will instruction make the CX equal 0b00010000?
<clever>
jimbzy: and its getting just barely enough voltage to turn on, but turning on also causes voltage drop, and it turns off again
<jimbzy>
clickity clacking is it?
<clever>
yeah
<kaichiuchi>
hmmmmmm
<heat>
kaichiuchi, anyway the stdint problem is complex
<kaichiuchi>
yes it is and I'm getting really sad about it
<gog>
on clang it does exclude stdinc
<heat>
so in GCC if you have a bare metal target it gives you a proper stdint that on HOSTED redirects to your libc's stdint
<heat>
if you don't have a bare metal target it doesn't give you a stdint at all
<geist>
actually now that i loko at it i dont use freestanding. though i dont see wherei pass nostdinc or whatnot either
<heat>
clang always gives you a stdint.h that is funnily enough good for every architecture through compiler voodoo and the C preprocessor
<heat>
although I think that the sysroot should be first in the search paths so you do get the libc's stdint.h if possible
<heat>
also re: cstdint, no clue. I know you can use a few C++ standard library headers as they are also part of freestanding
<heat>
type_traits and the like
<kaichiuchi>
huh that's pretty neat
<heat>
in practice, you can include them and I've never had any of that blow up on my face except when it did
<heat>
which is actually hilarious: if you disable SSE, etc and include i.e cstdlib it usually automatically just has inline wrappers like namespace std { void foo(int a) { __builtin_foo(a); } }
<heat>
which, without hardware floating point the compiler gets really sad about that
<heat>
(if you imagine a float instead of an int there)
<heat>
they have a separate malloc with a static pool
<heat>
they first try normal malloc then fallback to shitty malloc, if everything fails you randomly terminate
<mrvn>
kaichiuchi: Have a look at coroutines. That is fun. You can make them to not allocate, if you are carefull, because the optimizer cancels the alloc and free.
* mrvn
still thinks constructors should have a way to fail with no exceptions.
<veles2001>
I wish vtables didn't silently point to the wrong things in constructors
<mrvn>
veles2001: how do they do that?
<heat>
if your vtables point to the wrong things you may be fucking up
<veles2001>
They point to the base class methods instead of the derived
<mrvn>
The derived class isn't initialized yet
<heat>
in the base class's ctor
<heat>
which makes sense
<mrvn>
heat: ??
<heat>
????
<mrvn>
why does it make sense?
<heat>
because I can't expect the derived type to be initialized in the base type's ctor given that the derived ctor runs last
<mrvn>
Having each class in the chain set the vtable in turn seems wastefull
<mrvn>
Only the outermost ctor should set the vtable
<heat>
how else would you do it? how do you know what the outermost ctor is?
<mrvn>
it's the one named in the new or type expression
<heat>
the compiler can only know if its inling everything
Burgundy has quit [Ping timeout: 265 seconds]
<mrvn>
Foo() should turn into: set vtable, call ctor(s)
gxt has quit [Remote host closed the connection]
<veles2001>
It would be nice to be able to call overidden member methods from inside the constructor, I understand why it doesn't work but it feels unintuitive
<mrvn>
setting the vtable would be more part of the allocation of the object than initialization
jafarlihi has quit [Ping timeout: 265 seconds]
<mrvn>
veles2001: even with non virtual members that is a rather risky thing to do
gxt has joined #osdev
<gog>
constructing an object with the base's type but trying to call a derived type's overridden virtual?
<veles2001>
mrvn: How so?
<gog>
or are you constructing the derived object?
<veles2001>
Constructing the derived object
<mrvn>
veles2001: the class variables aren't initialized yet and any use of those not initialized is UB
Vercas64 has quit [Quit: Ping timeout (120 seconds)]
<mrvn>
gog: the base class might have hooks for the derived class that you might want to call in the cinstructor
<gog>
hm yes
<gog>
in that case is it semantically different to try to call it through this->
<gog>
i don't really know enough about the scoping rules to weigh in here
<mrvn>
gog: no. this-> does nothing but avoid problems witrh shadowing
<mrvn>
plus doesn't work with lambdas that bidn this
<gog>
ok
<mrvn>
Foo(int x) : x(x) { int z = x, y = this->x; }
<mrvn>
gog: which x is which?
<gog>
in the initialization list, the x on the left is the class scope, inside parens is parameter
<gog>
inside the constructor z = x, x is param
<mrvn>
I've even seen Foo(int x) { this->x = x; }
<mrvn>
personally I prefer the x_ way.
<gog>
i prefer the m_ way
<heat>
m way cringe
<gog>
yeah i'm cringe
<gog>
so what
<mrvn>
class Foo { int m_i, m_j; }?
<heat>
my buddy can't be cringe
<heat>
pull yourself together
<gog>
NO
<gamozo>
cringe is UB
<heat>
geist, did you see the enhanced buddy allocator link I posted earlier? you might find it interesting