Does the FreeDOS kernel offer internal inbuilt TRIM support, and if not, would it be feasible and does that make sense?
Or would TRIM support as an external device driver loaded via CONFIG.SYS be a better option, and how exactly would that work?
DosFreak wrote on 2025-05-01, 14:04:
This isn't a forum, it's a mailing list. And I won't make my email address public.
There's a DOS trim utility from the late R. Loew
His stuff is pretty solid usually, don't see any reason why FreeDOS would redo it
jakethompson1 wrote on 2025-05-01, 18:55:There's a DOS trim utility from the late R. Loew
His stuff is pretty solid usually, don't see any reason why FreeDOS would redo it
It's a 3rd party tool and not in the kernel. It is also not open source and it also seems to be buggy and no longer being developed (website says 2017).
The source code was released when the author died and it's not particularly large; someone could pick it up: https://rloewelectronics.com/source/TRIM.C (note certificate warning).
This is super hardware specific and does not belong in the DOS kernel, any more than code to handle a specific Adaptec SCSI card does.
It would be reasonable as a config.sys driver or TSR. It's kind of the reverse of the DOS 6 Undelete support for delete sentry and delete tracker. Rather than hooking the file delete call and recording metadata about the file to make it easier to undelete, you would TRIM those sectors instead.
jakethompson1 wrote on 2025-05-02, 17:04:The source code was released when the author died and it's not particularly large; someone could pick it up: https://rloewelectronics.com/source/TRIM.C (note certificate warning).
If it's now under an open source license that allows further development, then someone should upload it to a site like GitHub. If the certificate for the website has already expired, then the website will certainly go offline at some point.
This is super hardware specific and does not belong in the DOS kernel, any more than code to handle a specific Adaptec SCSI card does.
It would be reasonable as a config.sys driver or TSR. It's kind of the reverse of the DOS 6 Undelete support for delete sentry and delete tracker. Rather than hooking the file delete call and recording metadata about the file to make it easier to undelete, you would TRIM those sectors instead.
If it is very controller-specific, then perhaps modularization and a higher-level interface would make the most sense, so that you can combine different controller adaptations with the higher-level TRIM TSR. But if you create a higher-level TSR with a standard interface for controller-specific features, then that could at least be included in the kernel. The controller-specific things then remain external, outside the kernel.
Exploit wrote on 2025-05-02, 07:39:jakethompson1 wrote on 2025-05-01, 18:55:There's a DOS trim utility from the late R. Loew
His stuff is pretty solid usually, don't see any reason why FreeDOS would redo itIt's a 3rd party tool and not in the kernel. It is also not open source and it also seems to be buggy and no longer being developed (website says 2017).
My opinion at the time was that it was more likely to be the version of Fdisk that is included with FreeDOS yhat is somehow buggy. I have never been to reproduce that specific issue with any other partitioning application.
Exploit wrote on 2025-05-02, 17:43:If it's now under an open source license that allows further development, then someone should upload it to a site like GitHub. I […]
jakethompson1 wrote on 2025-05-02, 17:04:The source code was released when the author died and it's not particularly large; someone could pick it up: https://rloewelectronics.com/source/TRIM.C (note certificate warning).
If it's now under an open source license that allows further development, then someone should upload it to a site like GitHub. If the certificate for the website has already expired, then the website will certainly go offline at some point.
This is super hardware specific and does not belong in the DOS kernel, any more than code to handle a specific Adaptec SCSI card does.
It would be reasonable as a config.sys driver or TSR. It's kind of the reverse of the DOS 6 Undelete support for delete sentry and delete tracker. Rather than hooking the file delete call and recording metadata about the file to make it easier to undelete, you would TRIM those sectors instead.
If it is very controller-specific, then perhaps modularization and a higher-level interface would make the most sense, so that you can combine different controller adaptations with the higher-level TRIM TSR. But if you create a higher-level TSR with a standard interface for controller-specific features, then that could at least be included in the kernel. The controller-specific things then remain external, outside the kernel.
The ability to pass TRIM commands also relies on the ability of any IDE to SATA converter used. JMicron and Marvell converter chips are the only ones I have been able to successfully run TRIM with.
