Thanks again!
Octocontrabass wrote:
xeyes wrote:
I don't have the PIO driver yet but the plan is to poll as it is like a shorthand to get things going before normal operation (DMA mode) comes online, is it valuable to support interrupt for PIO instead? As I understand the CPU needs to loop over port I/O anyways?
The CPU needs to wait for the disk to be ready before it can loop over port I/O. If you use interrupts, the CPU can do something useful while waiting for the disk.
Whether or not that's valuable depends on how many PIO commands you'll be using once you have DMA working. (Some ancient hardware doesn't support DMA.)
Haha my actual worry is that my code is too ancient compared to the hardware as all of them have nvme disks which as I understand is some sort of PCIe protocol (A.K.A. too advanced for me now). So all ATA code would be for virtual machines only. But gotta start from somewhere right?
I'll perhaps give interrupt driven PIO a shot, seems like the control flow is same as DMA (PIO does the copy in a loop after seeing interrupt and DMA gets notified that the copy is done or failed after seeing interrupt) so unless it causes lots of debugging trouble it shouldn't take that long to implement.
Octocontrabass wrote:
xeyes wrote:
A bad idea to allow unaligned access?
I think so. It's a lot of extra work for the device layer, and you're not going to use it at all once the cache layer works.
Didn't quite get where the extra complexity comes from. Even if all accesses are aligned the Device layer would still have to be able to read/write across blocks/sectors right? As the caller can issue a request such as "read 8MB for me". So unaligned access is just inefficient as it might have to read extra stuff out and throwaway but not much more complex than supporting a big access?
Also I'm trying to keep them (with or without cache) at parity from the interface's point of view so that issues can be quickly isolated with a #if or runtime setting change, so I'm hesitant to let the upper layers know that there's a cache so it can issue any access or there's no cache so it needs to do aligned access only.
Octocontrabass wrote:
xeyes wrote:
I guess it is still logical enough that should be a layer right below file system and I should probably start with the good old MBR?
Yes, but don't forget about GPT.
I thought GPT means UEFI which means x64? But I'm planning to stick with x86 until I have meaningful load that can force me to run out of either virtual or physical space.