Date: Mon, 16 Jan 2017 11:26:07 +0100 From: Jan Bramkamp <crest@rlwinm.de> To: freebsd-scsi@freebsd.org Subject: Re: Understanding the rationale behind dropping of "block devices" Message-ID: <3a76c14b-d3a1-755b-e894-2869cd42aeb6@rlwinm.de> In-Reply-To: <29469.1484559072@critter.freebsd.dk> References: <CAHB2L%2BdRbX=E9NxGLd_eHsEeD0ZVYDYAx2k9h17BR0Lc=xu5HA@mail.gmail.com> <20170116071105.GB4560@eureka.lemis.com> <CAHB2L%2Bd9=rBBo48qR%2BPXgy%2BJDa=VRk5cM%2B9hAKDCPW%2BrqFgZAQ@mail.gmail.com> <a86ad6f5-954d-62f0-fdb3-9480a13dc1c3@freebsd.org> <29469.1484559072@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3a76c14b-d3a1-755b-e894-2869cd42aeb6>