u/givemeagooduns_un

So i recently bought and played HL3 and lemme tell ya I have a lot to say about it.

it was ok 👍

beware: below are the incoherent ramblings i wrote at like 3am when i accidentally took too much adderall and decided to post for no real reason other than to put my thoughts into words and share what im thinking. im mostly writing this for smth like rubber-ducky debugging except rubber-ducky designing.

and if i say something really stupid thats expected cuz i have no clue wtf im doing and havent taken an OS class yet or anything. this is just something stupid ive been working on for forever

i need to design the filesystem layer of my kernel. targeting a 6502 while also trying to have a more modern API design makes things quite difficult.

ignoring the actual filesystem driver and instead focusing on how the application handles file IO.

theres a couple possibilities on how i can implement it and im not sure what to go with.

• i can have the file API implement reads and writes by caching the current sector in kernel memory, and copies the bytes needed to userspace when reading. for example, reading 16 bytes will load the full sector in kernel memory and copy it to the 16 byte buffer in userspace. this will be quite slow as copying memory on a 6502 is very slow, especially if you need to copy more than 256 bytes and need to use a 16 bit index.
• the file API can be strictly sector-by-sector -- userspace can only read/write to a full sector at a time. this means that the kernel can write the sector data directly from the drive to wherever userspace needs it, eliminating the need to copy memory. if more free-form reading/writing is needed, userspace can implement its own.
• the file API can read the full sector(s) into userspace for every read call, and discard the data that isnt needed. for example, userspace can request 16 bytes that happens to be in the middle of a sector. the kernel will read the sector, discarding everything but the 16 bytes and put them in the buffer directly. this means that consecutive small reads would need to re-read the sector from disk, tho.

any sort of caching on the kernel side would require copying memory for every read.

currently, the entire drive IO layer is asynchronous. as of now, the events would occur as follows:

• fs driver requests a read of sector X to location Y
• disk driver sends a command to drive to read sector X. registers an NMI handler to put the bytes over
• userspace resumes execution
• every time theres a byte ready, NMI is triggered.
• NMI layer jumps to the disk driver handler
• disk driver nmi handler copies the byte(s)
• userspace resumes execution
• repeat until read all bytes of the sector
• perform a callback to userspace

callbacks to userspace are going to be really fucky, mainly due to hardware issues.

the callbacks are called within the NMI execution state, as to not interfere with the main thread's execution state. however, i always need to keep in mind that another interrupt can always happen during the NMI, so i keep a counter in a special location in memory. it is incremented every time an NMI is entered and decremented every time its exited.

if the NMI starts and the value is not zero, the NMI is deemed to be running within another NMI and immediately returns without decrementing.

the first NMI running repeats itself, decrementing the value each time, until it reaches zero, where it then restores the main thread's execution state and finally, RTI is called and it returns from interrupt.

however, there is an issue... userspace can then effectively delay NMIs by making a callback take forever, preventing important functions from running. i still need to figure this one out.

it probably would be best to keep each one in their own execution state, so that when an NMI occurs within it, it actually can handle the NMI immediately, call any other callbacks that need to be done, before returning to the other callback. my head hurts

Hi,

I am running Gentoo with kernel version 6.18.35, X11 with CWM, and overall a pretty basic setup.

Newer versions of Wine or Proton, versions 11 and up, have *terrible* performance, even with ntsync. Interestingly, whenever I defocus the window, the performance goes up drastically, but when I focus the window again it becomes terrible again.

I have another computer with a similar setup except with kernel 7.1.2 and it still has terrible performance when the window is focused, so it can't be a kernel bug with ntsync.

Hey all,

I'm trying to get Rust working on x32 and I need to add a single line to `rust-toolchain.eclass`. Adding that eclass file to my local repository only makes it affect ebuilds within there, and modifying the eclass file in the gentoo repository gets wiped after every sync (and I have a cron job set up to sync every night).

I was considering modifying the script to apply the patch after every sync, but I was wondering if there was a better, "proper" way of doing this?

Thanks