AHCI Port COMRESET ( & How to handle PortConnectChange INT)

[devc1]

Thanks, However I don't really see why people are still creating 32 bit kernels and all modern pc's support 64 bit. You can include alot of optimizations in 64 Bit mode.

[Octocontrabass]

I can't speak for anyone else, but my target is not modern PCs.

[devc1]

Yeah maybe old hardware is easier, I started working on my kernel (and O.S) a year ago and I do not have a GUI until now, I need to finish the essential drivers first and I have alot remaining (General Graphics Driver (for composition, and 3D), Window Manager, OHCI, UHCI, XHCI, IDE, CDROM, NVMe (Maybe)), I will also try to complete VMSVGA Driver to get an idea on GPU's and what they facilitate.

[nexos]

I agree with Octo here. There's nothing like seeing your OS boot up on a very old computer, than watching it boot up on a high end server.

Yeah maybe old hardware is easier

That actually depends. Some hardware is difficult these days (such as USB and ACPI), but most old hardware is heavily burden by backwards compatibility (look at the ISA Floppy). For another example, working with video hardware was a pain back in the days of 16 bpp, planed framebuffers.
New hardware has a lot of features and is very extensible. That honestly helps avoid the complexity of old hardware, while adding in its own kind of complexity .

[devc1]

Thank you all for your support! The AHCI Command Queuing worked perfectly, and my new scheduler was highly optimized that it recorded (4-5 us on my laptop, 12-15 us on QEMU) Latency per Task Schedule (Measured with HPET). Reading 100MB of the disk in QEMU is almost instant and in my second laptop with an old HDD, it took over 500MB/S (Edit : without printing each command (in Slow FrameBuffer) 500 MB took 1 Second) . However, creating that scheduler was very boring that I almost used every (XMM, FPR (MM0-MM7), General Purpose) Register lol !