From owner-freebsd-scsi@freebsd.org  Mon Jan 16 10:26:18 2017
Return-Path: <owner-freebsd-scsi@freebsd.org>
Delivered-To: freebsd-scsi@mailman.ysv.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
 [IPv6:2001:1900:2254:206a::19:1])
 by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2BE75CAFECE
 for <freebsd-scsi@mailman.ysv.freebsd.org>;
 Mon, 16 Jan 2017 10:26:18 +0000 (UTC) (envelope-from crest@rlwinm.de)
Received: from smtp.rlwinm.de (smtp.rlwinm.de [IPv6:2a01:4f8:201:31ef::e])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
 (Client did not present a certificate)
 by mx1.freebsd.org (Postfix) with ESMTPS id ECD051CE7
 for <freebsd-scsi@freebsd.org>; Mon, 16 Jan 2017 10:26:17 +0000 (UTC)
 (envelope-from crest@rlwinm.de)
Received: from crest.local (unknown [87.253.189.132])
 (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
 (No client certificate requested)
 by smtp.rlwinm.de (Postfix) with ESMTPSA id 67CD6111D9
 for <freebsd-scsi@freebsd.org>; Mon, 16 Jan 2017 11:26:08 +0100 (CET)
Subject: Re: Understanding the rationale behind dropping of "block devices"
To: freebsd-scsi@freebsd.org
References: <CAHB2L+dRbX=E9NxGLd_eHsEeD0ZVYDYAx2k9h17BR0Lc=xu5HA@mail.gmail.com>
 <20170116071105.GB4560@eureka.lemis.com>
 <CAHB2L+d9=rBBo48qR+PXgy+JDa=VRk5cM+9hAKDCPW+rqFgZAQ@mail.gmail.com>
 <a86ad6f5-954d-62f0-fdb3-9480a13dc1c3@freebsd.org>
 <29469.1484559072@critter.freebsd.dk>
From: Jan Bramkamp <crest@rlwinm.de>
Message-ID: <3a76c14b-d3a1-755b-e894-2869cd42aeb6@rlwinm.de>
Date: Mon, 16 Jan 2017 11:26:07 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0)
 Gecko/20100101 Thunderbird/45.6.0
MIME-Version: 1.0
In-Reply-To: <29469.1484559072@critter.freebsd.dk>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
X-BeenThere: freebsd-scsi@freebsd.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: SCSI subsystem <freebsd-scsi.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-scsi>,
 <mailto:freebsd-scsi-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-scsi/>
List-Post: <mailto:freebsd-scsi@freebsd.org>
List-Help: <mailto:freebsd-scsi-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-scsi>,
 <mailto:freebsd-scsi-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Mon, 16 Jan 2017 10:26:18 -0000

On 16/01/2017 10:31, Poul-Henning Kamp wrote:
> --------
> In message <a86ad6f5-954d-62f0-fdb3-9480a13dc1c3@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.