[kernel] Add @Mellvik's direct floppy driver

[ghaerr]

@Mellvik took Linus's original direct floppy driver from ELKS and got it working using async I/O on his TLVC fork.

I was able to import @Mellvik's code back into ELKS and got it integrated and running in about half an hour. Nice work @Mellvik!!

The driver is currently experimental-only for ELKS and requires CONFIG_ASYNCIO=y to also be set. For testing, QEMU is being used (no real hardware yet), and the system is booted via the BIOS driver hard drive on /dev/hda. Then, mount /dev/df0 /mnt is used to open the direct FD driver and mount a 1200k floppy. (QEMU is reporting a 1200k floppy in CMOS even when a 360k floppy image is attached, so using 1200k only for now). ls -l /mnt, etc works for a while, then the floppy system becomes heavily corrupted in RAM, for reasons unknown.

This will likely be committed so that some other modifications can be made to ELKS, for instance to disable track caching for hard drives, which will then allow DMASEG to be used for (all) floppy I/O, without worries for DMA 64k boundary overruns and eventual sharing of the BIOS track caching code. I will then continue to investigate the issues seen to determine whether they are ELKS kernel issues with async I/O or with the FD driver.

[ghaerr]

Hello @Mellvik,

works for a while, then the floppy system becomes heavily corrupted in RAM, for reasons unknown.

After disabling the BIOS hard disk track cache in PR #1717, the direct floppy driver is working flawlessly!! :) Presently, I am unable to get it to fail, really nice!!!!

Under QEMU, there is still a slight delay with the driver. I'm not sure what this might be, as QEMU doesn't emulate floppy delays when using its BIOS calls.

Thank you!

[Mellvik]

Happy to hear that, @ghaerr.
I'm not experiencing the QEMU lag you're mentioning, so it may have to do with the mix with BIOS HD?

Anyway I'm pushing an update in TLVC today - mostly cleanups but a couple of important fixes.