<heat>
is there a point of doing a proper TLB shootdown/invalidation when harvesting A bits?
Arthuria has joined #osdev
foudfou_ has joined #osdev
foudfou has quit [Ping timeout: 260 seconds]
gog has quit [Ping timeout: 256 seconds]
Arthuria has quit [Remote host closed the connection]
<geist>
probably not, depends on how accurate you want to be
<geist>
a cpu will only writeback the A bit when they go to fetch from the page tables on a tlb miss, if the A bit isn't set they'll write ti back
<geist>
so it has to age out naturally for that state to happen
<geist>
on one or many cpus
<geist>
that being said may as well at least invlpg on the local cpu since that's probably 'free'
Arthuria has joined #osdev
goliath has quit [Quit: SIGSEGV]
<heat>
yeah linux agrees, no tlb flush on x86
air has joined #osdev
<heat>
they do do it on other archs (e.g arm64) and there are vague mentions of data corruption, so i imagine things may not be so crystal clear on other architectures
<zid>
Clearly they should communicate with the mmu and make it so it stealthily updates the A bit only if it gets read
<zid>
(or on purge out of the TLB still)
edr has quit [Quit: Leaving]
janemba has quit [Read error: Connection reset by peer]
<osdev199>
Hello, is there a status register in NVMe to know if the NVMe subystem is executing the submitted admin command? Like it is set to 1 if it is else it is set to 0 when it is idle.
janemba has quit [Read error: Connection reset by peer]
m3a has quit [Ping timeout: 260 seconds]
janemba has joined #osdev
zetef has joined #osdev
zetef has quit [Client Quit]
<chiselfuse>
i read that rsp must be aligned to 16 before executing a call instruction. does each function assume that it starts with rsp misaligned by 8? because otherwise how would it know?
m3a has joined #osdev
<chiselfuse>
i'm also not sure why it's important. is it the fact that the function must "know" which alignment the stack is at a moment to reduce the overhead of testing the value of rsp so that it can put data at optimal offsets for SSE instructions?
goliath has joined #osdev
<Mutabah>
Correct that the function assumes misalignment after the call
<Mutabah>
and the first operation is usually `push rbp`
<Mutabah>
the alignment is to improve performance of SSE etc, so the functions don't need to test the alignment and manually align
<sortie>
chiselfuse: Yes it's e.g. for SSE instructions so it can unconditionally just store 16-byte aligned data at an offset and know it's that aligned. It also affects anything where you might use attribute aligned and the compiler will know that piece of data also has the sufficient alignment
<sortie>
chiselfuse: If you're wondering if you can avoid doing this, including on 32-bit x86, the answer is do not skip 16-byte alignment, it's undefined behavior to not do it (even on 32-bit!), the compiler will assume the stack is aligned like that, and you will have weird ass bugs if you don't do it every time everywhere.
Left_Turn has joined #osdev
CryptoDavid has joined #osdev
foudfou_ has quit [Remote host closed the connection]
foudfou has quit [Remote host closed the connection]
foudfou has joined #osdev
janemba has quit [Read error: Connection reset by peer]
<chiselfuse>
hypothetically, if the abi had no alignment requirements whatsoever for executing `call`, what's the most optimized way for a function to place data on the stack in an aligned way? i can think that since branches are slow, it might instead mask rsp with FFFF FFFF FFFF FFF0 and or with FFFF FFFF FFFF FFFC if it only cares for finer alignment
<chiselfuse>
i have 2 questions. is there a more efficient way?
<chiselfuse>
and also i vaguely remember reading assembly somewhere that already did this, which abi does this and isn't this more efficient than system v since every function aligns it only if it needs alignment as opposed to always having to do it regardless whether the next function needs alignment?
<gog>
in the few places where i use assembly, i mask store base, stack pointer to rbp, mask rsp unconditionally
<gog>
it's at most a waste of 8 bytes of stack
<chiselfuse>
i know that you must have at the very least some alignment requirement from the previous function, but why isn't it just alignment requrirement to 8
<gog>
because SSE registers are part of the amd64 ISA
<gog>
they have to be spillable to the stack
<pdziepak>
callee can align the stack if it wants to spill, that's not a valid reason
<pdziepak>
but i think it is as simple as "all x86_64 have sse, let's make 16byte values first class citizen"
<pdziepak>
and then you align stack so that all values you care about can go there without any further alignment
<gog>
what you refer to does happen with AVX256 instructions, the compiler will emit alignments in the callee
<chiselfuse>
do you know which abi does masks rsp instead? i remember something of the sort
<gog>
the abi doesn't require the masking, it only defines the requirements
<gog>
any way that accomplishes that is implementation-defined
<gog>
defines the alignment requirements*
<chiselfuse>
i don't understand what you're saying gog
<gog>
the ABI doesn't define _how_ the alignment has to happen
<gog>
only that it has to be aligned
<zid>
and rsp, -16 for life
<pdziepak>
gog: yes, but the point is that you could have abi that requires only 8 byte alignment, and sse, avx2, avx512 need to do alignment in callee, so the question is why sys v abi went for 16 byte alignemnt instead?
<chiselfuse>
zid: what's `rsp, -16`?
<zid>
what
<zid>
one is the stack pointer
<gog>
i guess it's because they figured that SSE would start to be the go-to for optimized copies and moves
<zid>
one is the number you add 16 to to get 0
<zid>
-16
<zid>
I'm *sure* you've heard of negative numbers? right?
<chiselfuse>
< zid> and rsp, -16 for life
<gog>
but they didn't figure on microcode making movsb really fast
<chiselfuse>
what did you mean by this message
<zid>
0x48, 0x83, 0xE4, 0xF0
<chiselfuse>
since you keep trolling, i don't care
<zid>
so why the fuck are you asking me shit
<gog>
he's saying the instruction "and rsp, -16" is the way
<zid>
I went out of my way to assemble that for you
<zid>
Literally directly asked me what I meant, I explained it, you then asked me AGAIN so I assembled it for you
<zid>
"fucking troll"
janemba has joined #osdev
<chiselfuse>
gog: so you're saying that some compilers will mask rsp to align it before a `call`? why would they need to do that since they are aware of rsp's alignment throughout the function and can just `sub, rsp, _` to adjust it before `call`? is masking a faster instruction?
janemba has quit [Read error: Connection reset by peer]
<pdziepak>
mask rsp in the callee if you need stronger alignment than calling convention gives you (e.g. working with avx2 and need 32 byte aligned stack)
<chiselfuse>
zid: oh you meant the opcode `and`..
<gog>
the compiler may not necessarily always know the alignment of the stack pointer, and subtraction may inadvertantly misalign
<gog>
masking with a negative always results in an aligned value
<zid>
or rather, there may be multiple possible alignments
<gog>
also that
<zid>
so it's easier to just do one instruction that deals with both
<zid>
you could imagine like f(int a) { if(a){ char buf[8]; g(buf); ... } beep(); }
* Ermine
gives gog a piece of cheese
<zid>
you can just do the mask before beep, and regardless of whether the array was created, your stack is still aligned
<chiselfuse>
gog: why wouldn't it, it's guaranteed that at the beginning of the procedure rsp is at misalignement 8, or isn't it?
<zid>
C99 allowed variable length arrays
<zid>
so it only 'knows' in the sense it has the value in a register
<gog>
and you can omit the frame pointer
<zid>
presumably you don't want your compiler to spit out if(buffer_size == 1) rsp -= 15; if(buffer_size == 2) rsp -= 14; ...
<chiselfuse>
zid: so you mean that it still knew at the beginning of the function but that it didn't know after having filled up the array which varies at runtime?
<zid>
just round the buffer size to 16, done
<zid>
yes
<zid>
char a[b]; is legal C99
<gog>
it's not good
<gog>
but it's legal
<zid>
b will be in a register somewhere, so you need an easy operation to round either b or rsp to a multiple of 16
<gog>
i call it C99's second amendment: one may own and bear footguns
<zid>
the 'easy operation to round to 16' is and r, -16
<chiselfuse>
lol gog
<chiselfuse>
i don't know what that translates too but i suspect -16 is something like FFFFFFFFF...0 or something
<chiselfuse>
because 2's complement?
<zid>
I literally assembled it for you
<zid>
0x48, 0x83, 0xE4, 0xF0
<zid>
yes, it equates to ...F0
<zid>
because it's the number you add 16 to to get 0
<chiselfuse>
oh now i get it
<zid>
0xFF is -1 because 0xFF + 1 = 0
<gog>
and because of sign extension you can just use the F0
<gog>
and the ALU does the rest
<chiselfuse>
what do you mean
<chiselfuse>
use F0 instead of -16 how
<gog>
i mean how it's encoded
<zid>
those.. are the same number
<zid>
you *can't* use one instead of the other
<pdziepak>
int8_t -16 is uint8_t 0xf0
<chiselfuse>
yea but you can't do 0x0F0
<gog>
sure you can
<gog>
AND is a signed operation
<gog>
actually idk what the assembler would do with that
<chiselfuse>
isn't uint16_t 0x0F0 the same as uint16_t 240?
<gog>
yeah but i don't know if the assembler is going to interpret that as a 16 or 8 byte literal because of the leading zero
foudfou has quit [Remote host closed the connection]
foudfou has joined #osdev
mbr57 has joined #osdev
<mbr57>
Hello
janemba has joined #osdev
<GeDaMo>
Hi mbr57 :)
<mbr57>
How are you doing?
<GeDaMo>
OK, you?
<mbr57>
Fine
<gog>
hi
<mbr57>
Hello gog
<mbr57>
I didn't know there was a osdev channel on irc.libera.chat
<mjg>
osdev is dead
<mbr57>
Really ?
<mjg>
the few people busy doing osdev don't even post here
<mjg>
this is a social channel
Turn_Left has joined #osdev
heat has quit [Remote host closed the connection]
heat_ has joined #osdev
<mbr57>
I see
Left_Turn has quit [Ping timeout: 268 seconds]
navi has joined #osdev
op has quit [Remote host closed the connection]
obrien has joined #osdev
<sortie>
geist: I fixed the kline. Uh I wonder if it actually klined pub.sortix.org itself due to the IPv6 proxy lol
<kline>
hmm?
<sortie>
lol
<sortie>
kline: I'm running my own IRC network self-hosted on my own osdev operating system haha, he accidentally triggered an antispam mechanism there, so just letting him know I undid the ban off network after my vacation :)
<kline>
nice
<kline>
like, thats really cool that you're selfhosting osdev irc on your own os
<sortie>
Yeah, irc.sortix.org. I'm running my own #osdev there just in case this place ever gets invaded by the Joseon empire, plus also all the community chatting takes place there now rather than the libera channel (which is still online and is fine)
<mjg>
wow
<mjg>
noice
<sortie>
It's the best kind of osdev, I have a server running in a german data center with a bunch of VMs running my OS, and it's all 100% self-hosted. nginx is powering the official website with TLS & libressl. ssh logins work. They got IPv4s directly on the internet. IPv6 proxy via Linux.
<sortie>
All the nightly and official builds of my OS happens on itself in these VMs every night
<sortie>
It even spawns recursive VMs of my OS to test that the new builds work
<sortie>
Sortix is probably the most advanced hobby OS in here when it comes to being a OS that you can actually install on your servers and actually run a whole bunch of server daemons
<sortie>
Oh hey did y'all see there's a new POSIX 2024 officially out now?
<GeDaMo>
zid was looking for a free copy :P
<sortie>
The html version should be up in a few days ... they said a few days ago .. so still waiting too
<bslsk05>
standards.ieee.org: IEEE SA - IEEE 1003.1-2024
<gog>
the professional sortix network
<sortie>
POSIX 2024 doesn't matter to most people in here since you want to work on all the basics first which are in the older versions, but I do have most of those basics. I actually preemptively have implemented a lot of the POSIX 2024 additions as they're useful extensions I agreed with other implementations on
<zid>
$(foo:%.o=%.c)
<zid>
is now posix :o
<zid>
posix 2024 matters here a lot because we use all these posix ass tools still though
<zid>
nice to know xargs now has -r, for exa
<zid>
mple
<sortie>
POSIX make went from uselessly simple to actually kinda useful
<zid>
looks like they'v ejust taken anything I've ever used in gnu make before now
<zid>
and made it posix
<sortie>
zid, it sure matters, although generally the implementations had all of these extensions already besides a couple silly inventions of POSIX
<zid>
phony, $^, pattern subst, etc
<sortie>
zid, that is actually a bit misleading, they've rather taken the subset that GNU and BSD make agree on and implemented that
<zid>
sortie: Lots of arguments here about shell scripts and makefiles because someone used something that wasn't posix :P
<zid>
what's misleading?
<sortie>
GNU has a ton of extensions that are not in scope for POSIX here
<zid>
yes?
<zid>
I said
<zid>
they added the parts I have actually ever used
<sortie>
Yeah
<zid>
I'm sure there are thousands of bits I haven't used and never will
<zid>
but it's nice that the "reasonable normal bits" are now standard
<sortie>
The big missing part is if statements where GNU and BSD differ
<sortie>
The BSD for statement in make is actually quite wild and useful
<zid>
never used a for in either
<zid>
see
<sortie>
The BSD for statement is top level which is quite useful and powerful whereas GNU likes to use macros at lower levels
<sortie>
Or inference rules
<sortie>
Which have their uses too
<sortie>
I actually to prefer the BSD syntax here
<zid>
I'm sure it's all useful to someone, but I don't see why posix should add any of it, but it desperately needed the basics
<zid>
and now has it
<heat_>
i use GNU tools
<zid>
so I am happy
<sortie>
Absolutely the basics were so very needed
<sortie>
If you read POSIX make in issue 7, you'll realize it has so few features the program is barely useful
<mjg>
:D
<sortie>
I wonder what Apple is gonna do about POSIX 2024
<sortie>
If they're just gonna completely ignore it
<sortie>
Like they did with POSIX 2008
<mjg>
are they still certifying themselves as UNIX
<zid>
I have official permission to write makefiles that don't work on apple if they fail to support posix 2024 though
<sortie>
After making such a big deal out of being certified POSIX 2001
<zid>
that's a job for the porter now, not me
<sortie>
macOS has had bits and pieces of POSIX 2008 added over the years but pretty clearly not something they cared about
<heat_>
geist, yeah, fwiw the reasoning is really... weird... they continue to tlbi (without dsb) on arm64 because it's cheap and they're afraid they don't invalidate the TLB on context switches, but then OTOH x86 also has ASIDs (although used in a different way)
<zid>
as I am no longer using gnu extensions just to turn .c into .o
<heat_>
geist, also apparently there's an nvidia arm uarch that completely ignores your tlbi until you dsb or they run out of tlbi buffer space, which is amusing
Left_Turn has joined #osdev
<nikolar>
zid: what do you mean
Turn_Left has quit [Ping timeout: 256 seconds]
<zid>
what do I mean about what
<nikolar>
What gnu extensions were you referring to
<zid>
any of them, ever
<zid>
gnuc, gnu make, coreutils options, etc
<zid>
If I write a project in C but three lines are gnu c and it stops it working on osx or whatever, imo those people have a valid point that it is a mistake, to be remidied upstream
<zid>
remedied
agent314 has quit [Ping timeout: 268 seconds]
foudfou has quit [Remote host closed the connection]
foudfou has joined #osdev
m3a has quit [Ping timeout: 246 seconds]
Turn_Left has joined #osdev
mbr57 has quit [Quit: Leaving]
Left_Turn has quit [Ping timeout: 255 seconds]
janemba has quit [Read error: Connection reset by peer]
Left_Turn has joined #osdev
janemba has joined #osdev
Turn_Left has quit [Ping timeout: 256 seconds]
m3a has joined #osdev
node1 has joined #osdev
mbr57 has joined #osdev
mbr57 has quit [Quit: Leaving]
MrCryo has joined #osdev
Turn_Left has joined #osdev
Left_Turn has quit [Ping timeout: 255 seconds]
moire has joined #osdev
<moire>
anyone have a recommendation for how to use qemu with gdb such that every time i want to test a change i don't have to the dance of close qemu, close gdb, open qemu, open gdb, without gluing the two together in a shell script that uses tmux/screen?
<GeDaMo>
Can't you use the qemu console to restart / reload without actually ending the program?
<bslsk05>
en.wikibooks.org: QEMU/Monitor - Wikibooks, open books for an open world
<heat_>
no
<moire>
for some reason i did not think it would work with gdb properly
<heat_>
that doesn't work
<GeDaMo>
Bah! :P
<heat_>
gdb can't deal with cpu mode switches well, and qemu takes a lock on disk images for instance (so reloading isn't really possible)
<nikolar>
what if you boot with -kernel
<nikolapdp>
can you reload then
<nikolapdp>
it can just keep the lock
<heat_>
hmmm actually it might be possible, file locks are only advisory
<moire>
this would be slightly less annoying if i could get qemu record/replay reverse debugging to actually function properly, but it always aborts when i try to replay... need to file a bug report for that
netbsduser has joined #osdev
<dostoyevsky2>
is it difficult to write your own cpu emulator? I guess if you can write a disassembler, then you can also write a virtual cpu... but the MMU stuff might be a little more difficult to emulate
randm has quit [Remote host closed the connection]
randm has joined #osdev
<GeDaMo>
Depends on how complex the CPU is and how accurate you want the emulation to be
janemba has quit [Read error: Connection reset by peer]
<dostoyevsky2>
GeDaMo: I guess if you e.g. try to boot linux and it crashes you can usually check your implementation again the Intel documentation on what certain OPs should do exactly... but not sure if memory and io APIs are always documented that well
<GeDaMo>
Just so long as they do what the software expects :P
node1 has quit [Quit: Client closed]
rustyy has quit [Ping timeout: 240 seconds]
zid has quit [Ping timeout: 240 seconds]
<immibis>
dostoyevsky2: it's mostly straightforward, but just a lot of grind work, implementing every instruction
<immibis>
there are several tutorials on the internet for how to write gameboy emulators, because that's a relatively simple system
zid has joined #osdev
<immibis>
note that every system includes not just a CPU, but also several peripherals, and the CPU is useless if you don't implement the peripherals as well. If the point is to learn a CPU emulator, you could make it so you read the output from a certain memory address after the program ends, but you couldn't run Linux that way because that isn't how Linux shows output.
<bslsk05>
shish/rosettaboy - A gameboy emulator in several different languages (22 forks/464 stargazers/MIT)
<zid>
can confirm the emulators are bad
<zid>
accuracy wise
<zid>
(I just checked)
<dostoyevsky2>
immibis: I guess the MMU stuff would also be documented in Intel's manual, so if the kernel is setting up custom memory trappings, those should work also... and for hardware I guess one could steal a bit here and there from qemu
<sortie>
I have popcorn and the POSIX 2024 pdf
<nikolar>
oh how did you get it
<heat_>
TOP SECRET
<nikolar>
ah completely legally i am sure
<zid>
opengroup hgas it on their website
<zid>
I linked it into ##asm earlier
<nikolar>
oh nice
<heat_>
you need an austin group acc to get the draft
<nikolapdp>
> Unapproved Draft, Subject to Change
<heat_>
that's irrelevant
<zid>
I've been using the c99 draft
<zid>
for 15 y ears
<zid>
the only difference is that it says spec not draft spec, ofc
<nikolapdp>
heh
<sortie>
I had a friend use IEEE access to get me a pdf :)
<nikolapdp>
ooh fancy
<sortie>
If you're in university, your institution may already be paying for access to IEEE
<sortie>
And you can get credentials to log in
<heat_>
yeah or if you're in mine it just doesn't work
<heat_>
for some reason
<sortie>
heat_, you don't have a professional Sortix network sorry
<heat_>
(they know i hate POSIX so they didn't bother getting access)
<Ermine>
ieee xplore ieee xplore ieee xplore
<nikolapdp>
eeeeeeeeeeeeee
<Ermine>
nikolapdp: latest draft is usually identical to published version
<nikolapdp>
yeah i am aware
<nikolapdp>
just pointing out
<Ermine>
imo idea of the standard being paid is absurd
<nikolapdp>
i agree
<heat_>
i'm a big fan of cartels
<nikolapdp>
get them to procure you some illicit material, like standards
<heat_>
who do you think is in charge of the standards?
<nikolapdp>
i wasn't sure what cartels you were referring to
<Ermine>
in other news, my bike tires should be inflated to 50 psi, but I inflated them to 30 psi and I'm afraid to go further
<nikolapdp>
the legal or illegal ones
<zid>
if they don't feel like bricks they're too low for road use
<heat_>
nikolapdp, what's the difference?
<nikolapdp>
well i just didn't know which ones you were referring to
<Ermine>
they do feel like bricks
<heat_>
the answer to your question is yes
<nikolapdp>
indeed
<GeDaMo>
Is a cartel like a hotel for cars? :|
<zid>
god, apparently road bikes can go up to 100psi
<zid>
that really must be like bricks
<zid>
160psi at the absolute top end
<gog>
yeah riding on anything but smooooth surface is not comfy
<zid>
My worst nightmare is having to ride a heavy mountain bike on 20psi on a road
<immibis>
dostoyevsky2: yes, the MMU is well documented. Last I saw it - many years ago - the Intel manual was divided into a few volumes. One was the application programmer's manual, which explains all the things you might want to do when writing a program. Another was the system programmer's manual, which explains all the extra things you might want to do when writing an operating system, such as how the MMU works. I think the other one was the full opcode
<immibis>
reference or something like that.
MrCryo has quit [Remote host closed the connection]
agent314 has joined #osdev
<geist>
also as we point out here a lot, there is an AMD manual thats more or less equivalent, but differently worded
<geist>
so helpful to cross reference the two
<geist>
honestly i find the AMD manual generally more plesant, so i usually start with it
<heat_>
i'm intelpilled
<zid>
yea but AMD didn't send me any deadly weapons
<zid>
intel did
<heat_>
not that I enjoy the SDM more, but i know my way around a little better
<nikolapdp>
what weapons did they send you zud
<immibis>
probably one of those 13700 chips that burns themselves out and then you can throw it at intel managers
<immibis>
or whichever chip it was
<zid>
bludgeons, a whole set
<GeDaMo>
Intel used to send out print manuals for free
<zid>
volume 1, light bdsm. volume 2A, heavy petting, volume 2B, instruction set reference m-z, volume 3, corporal punishment
<chiselfuse>
is it the case that any function in an object file compiled from any source language that one may link against under linux must respect these?
<heat_>
no
<heat_>
(*)
<nikolapdp>
heh
* chiselfuse
clicks on (*)
<nikolapdp>
but generally, you can't assume that
<heat_>
(*) languages have their own ABIs, rust has its own ABI AFAIK, C++ has a modification of the sysv C ABI with extra stuff, etc
<GeDaMo>
A function only has to follow the calling convention if it's calling other functions which use the calling convention
<nikolapdp>
rust doesn't have a specified abi
<nikolapdp>
ie, it's going to change between versions
<chiselfuse>
heat_: but if it doesn't, my understanding is that i can't link against it with some other language or else the object code of the function might corrupt the caller's code and so on
<heat_>
yes, but this is commonly known (these days) as the "C ABI"
<chiselfuse>
nikolapdp: so does this mean that i can't link against rust from a C program?
<nikolapdp>
that's why you can usually declare a function to use the c abi
<nikolapdp>
in rust or c++
<nikolapdp>
chiselfuse if you want to link a rust library into a c program for example, the library would need to provide c compatible functions
<nikolapdp>
(generally, when you are doing cross language linking, you'll use c abi, no matter what the languages are)
<chiselfuse>
so if i have an object file with a bunch of symbols of public functions that one may link against, i can't actually do that unless i analyze them and try to figure which abi they use, even if it's an elf file (system V) in the correct ISA
<nikolar>
i am going to say "depends"
<zid>
Good news, there's absolutely no reason to call arbitrary functions from an arbitrary .o file
<zid>
"I just found a cool dll, wonder what it does? deletesystem32()? Sounds rad, I'll call it, if I can figure out the parameters"
<nikolapdp>
that's correct, you generally only link against well defined interfaces
<heat_>
chiselfuse, yes, you can't call random functions and hope they have the sysv abi
<chiselfuse>
what does something like libssl.so.3 on my system use?
<heat_>
the C <arch> sysv abi
<heat_>
Generally(tm)
<chiselfuse>
i thought many programs written in different languages in general linked against it. if it's true, do they all have to specify some attribute when calling those functions to let them know how to pass args?
<heat_>
yes
<nikolapdp>
more like, you specify when your're writing code
<nikolapdp>
the linker doesn't care about abi
<gog>
some of them have wrappers that hide the fact that it's an external library
roper has quit [Quit: leaving]
Arthuria has joined #osdev
GeDaMo has quit [Quit: 0wt 0f v0w3ls.]
<zid>
beeeep
<nikolapdp>
boooop
<zid>
Your laundry must be done
<nikolapdp>
i wasn't doing my laundry today though :/
<zid>
(being eaten by a grue)
<nikolapdp>
):
<zid>
smh need to update factorio from .101 to .104 to use my mod
<zid>
tempted to just edit the table of contents
<nikolapdp>
maybe there were breaking changes
<zid>
nah
<nikolapdp>
oh well
<zid>
I upgraded to .109, my executive function knows no bounds
<nikolapdp>
wow
obrien has quit [Remote host closed the connection]
Matt|home has quit [Ping timeout: 268 seconds]
netbsduser has quit [Ping timeout: 240 seconds]
gbowne1 has joined #osdev
gbowne1 has quit [Remote host closed the connection]
gbowne1 has joined #osdev
Arthuria has quit [Killed (NickServ (GHOST command used by Guest684531))]
Arthuria has joined #osdev
<heat_>
geist, have you found use for the D bit at all?
<heat_>
i legitimately don't see the point of the D bit, everyone just usually emulates dirty tracking with page faults
Arthuria has quit [Read error: Connection reset by peer]
Arthuria has joined #osdev
<geist>
we currently dont use it on fuchsia, if nothing ese beause it's only reliably present on x86
<geist>
so no matter what you gotta emulate it
Arthuria has quit [Read error: Connection reset by peer]
<geist>
i would think of it as just an optimization to get a little more fidelity of dirty page tracking, and a bit less 'minor' page faults
<geist>
but it doesn't provide anything you can't otherwise get
<heat_>
i suspect scanning for these is just super unwieldy at best
<heat_>
you'd have to continuously scan shared-mapped files for D bits on all mappings
<heat_>
the minimal subset is around the first x86_64 cpus, like the opteron there
<heat_>
though there's some screweyness when it comes iirc NX support (some of the really early ones didn't have it, but it's pretty much mandatory and "minimal", depends if you want to support those)
<zid>
that's why opterons don't conform to the spec