Understanding the rationale behind dropping of "block devices"

[Jan Bramkamp]

On 16/01/2017 10:31, Poul-Henning Kamp wrote:
> --------
> In message <a86ad6f5-954d-62f0-fdb3-9480a13dc1c3 at freebsd.org>, Julian Elischer
> writes:
>
>> Having said that, it would be trivial to add a 'caching' geom layer to
>> the system but that has never been needed.
>
> A tinker-toy-cache like that would be architecturally disgusting.
>
> The right solution would be to enable mmap(2)'ing of disk(-like)
> devices, leveraging the VM systems exsting code for caching and
> optimistic prefetch/clustering, including the very primitive
> cache-control/visibility offered by madvise(2), mincore(2), mprotect(2),
> msync(2) etc.
>
Enabling mmap(2) on devices would be nice, but it would also create 
problems with revoke(2). The revoke(2) syscall allows revoking access to 
open devices (e.g. a serial console). This is required to securely 
logout users. The existing file descriptors are marked as revoked an 
will return EIO on every access. How would you implement gracefully 
revoking mapped device memory? Killing all those processes with 
SIGBUS/SIGSEGV would keep the system secure, but it would be far from 
elegant.