Hey maximus, long time fan, first time poster.
Ever think about getting an unpaid intern to maintain the source and implement features so you don't suffer periodic development burnout?
If so, consider this my application, I'm new to data recovery but well versed in linux, C, passable in GTK and ncurses (possible text mode only implementation?) I can send you some small C projects I've written so you can judge my skill with the SG_IO ioctl, gtk, NTFS parsing, etc. I've even build up a nice-to-have feature list that further obsoletes ddrescue and goes where no hardware imager has gone before:
Floppy disk, cdrom, scsi_generic, and raw support: you can quickly change the "ls /dev | grep sd" in your source to "find /dev -name 'sd[a-z]' -or -name 'fd[0-9]' -or -name 'sg[0-9]' -or -name 'sr[0-9]' -or -name 'raw[0-9]' " to get the drives to list in drive selection. Then take it a step further, floppy drives operate on IO ports 3F2, 3F4, 3F5 - floppy disk direct mode is an option and no utility that I know of besides the DOS-based NFORMAT! actually writes to the stepping speed register of the floppy drive, so lots of unique things to explore there and floppy disk rescue is still an important area of data preservation. Secondly, most CDROM drives with CD-ROMs loaded can be put into red book mode where the drive reads the full 2,352 byte sector as audio instead of data mode "12 byte sync, 3 byte address, mode byte, 2,048 byte data, 4 byte checksum, 8 byte zero, 276 byte ECC" which allows you to perform the ECC after averaging several passes of red book reads (like you did in ddrutility with read long). Lastly, since hddsuperclone reads the capacity off the drive directly (unlike ddrescue) you can utilize a dev/raw/raw* device without trying to image MAX_UINT64 bytes like ddrescue.
Also as a nice-to-have, for standard cloning through a block device (/dev/sd*) a way to configure /sys/block/<target>/device/{io_timeout, eh_timeout, timeout, queue_depth} and maybe the 'unbind' option to remove the sd driver from the equation (access over /dev/sg*)
While new ideas are coming to mind, hddsuperclone sometimes has issues allocating memory physically in the correct < 4GB address, but since your already doing so much over "/dev/mem" and already requiring editing kernel boot parameters for direct, you *could* reserve physical memory directly as well with the kernel option memmap=SIZE$ADDRESS and have ram at that address that the kernel wont touch, but you can over /dev/mem.
Anyway I'm rambling so I'll stop here
![Very Happy :D](./images/smilies/icon_biggrin.gif)