FYI: This is already a thing in the embedded world and Linux already has corresponding software infrastructure: The "mtd" subsystem which stands for "memory te

FYI: This is already a thing in the embedded world and Linux already has corresponding software infrastructure: The "mtd" subsystem which stands for "memory technology devices" is a thin hardware abstraction layer for primarily raw flash devices with an internal framework for NAND flash with driver backends for all sorts of controlers and devices and support for e.g. software error correction if the device/controller doesn't support it, etc... The "ubi" subsystem which provides wear-leveling, bad block management and LVM style logical volume partitioning on top of mtd. It does not emulate a normal block device, it acts more like a flash device with idealized properties. The "ubifs" file system which was specifically designed for working on top of ubi. If you try to use this stack on a large-ish scale to build a DIY Linux powered SSD, you might run into scaling problems with ubi tough (don't think some companies haven't tried that yet). While it basically works, as always, pretty much every flash vendor guards the inner workings of their devices as secrets and those things have undocumented quirks and undocumented, secret instructions to work around various quirks used by the companies own SSDs and eMMCs. > Could you make money by producing a cheap "dumb" flash memory where you have raw access and leave all the wear leveling to software by using one of the many available log structured file systems? Technically, the market exists, but whether you could get into it and make money is another question. I'm willing to bet that if you design a NAND flash from scratch and try to sell it, the existing vendors will clobber you with patent infringement law suits. AFAIK the reasons why Linux has ubi instead of a full, in-kernel flash translation layer are also legal ones.