Firstly the driver would not expose a filesystem interface, it might expose something like a block-level interface. The filesystem would be provided by yet another process that operates over that block interface.
Secondly, mmap implies shared address space mappings, but note that the driver process doesn't have to be the owner of those mappings. If the driver restarts then the mmap process reissues any DMA commands to the faulted driver(s) to re-establish those mappings.
So now block devices can be restarted in case of faulty hardware. This might seem like kicking the can down the road a bit, but the point is to partition the statefulness into smaller, more manageable pieces that can be reused.
The filesystem process can preserve its caches and open file descriptors, and it should log mmap commands it issued in case of mmap faults as well. This is pretty robust and not so trivial to do at the kernel level where data structures are all intertwined.
Firstly the driver would not expose a filesystem interface, it might expose something like a block-level interface. The filesystem would be provided by yet another process that operates over that block interface.
Secondly, mmap implies shared address space mappings, but note that the driver process doesn't have to be the owner of those mappings. If the driver restarts then the mmap process reissues any DMA commands to the faulted driver(s) to re-establish those mappings.
So now block devices can be restarted in case of faulty hardware. This might seem like kicking the can down the road a bit, but the point is to partition the statefulness into smaller, more manageable pieces that can be reused.
The filesystem process can preserve its caches and open file descriptors, and it should log mmap commands it issued in case of mmap faults as well. This is pretty robust and not so trivial to do at the kernel level where data structures are all intertwined.