From owner-freebsd-arch@FreeBSD.ORG Mon Sep 1 21:30:37 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 401EC5ED for ; Mon, 1 Sep 2014 21:30:37 +0000 (UTC) Received: from hergotha.csail.mit.edu (wollman-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:ccb::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D482713BF for ; Mon, 1 Sep 2014 21:30:36 +0000 (UTC) Received: from hergotha.csail.mit.edu (localhost [127.0.0.1]) by hergotha.csail.mit.edu (8.14.7/8.14.7) with ESMTP id s81LUX14009136; Mon, 1 Sep 2014 17:30:34 -0400 (EDT) (envelope-from wollman@hergotha.csail.mit.edu) Received: (from wollman@localhost) by hergotha.csail.mit.edu (8.14.7/8.14.4/Submit) id s81LUWCs009135; Mon, 1 Sep 2014 17:30:32 -0400 (EDT) (envelope-from wollman) Date: Mon, 1 Sep 2014 17:30:32 -0400 (EDT) From: Garrett Wollman Message-Id: <201409012130.s81LUWCs009135@hergotha.csail.mit.edu> To: jkh@mail.turbofuzz.com Subject: Re: script(2) [was: [CFT/review] new sendfile(2)] X-Newsgroups: mit.lcs.mail.freebsd-arch References: <20140529102054.GX50679@FreeBSD.org> <20140729232404.GF43962@funkthat.com> <20140831165022.GE7693@FreeBSD.org> <540382E2.3040004@freebsd.org> <2770.1409522711@critter.freebsd.dk> Organization: none X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (hergotha.csail.mit.edu [127.0.0.1]); Mon, 01 Sep 2014 17:30:34 -0400 (EDT) X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED autolearn=disabled version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on hergotha.csail.mit.edu Cc: freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Sep 2014 21:30:37 -0000 In article , Jordan writes: >Having seen this pattern used for several kernel-related things in a few >of my former lives, I think this idea has a lot of merit, though I’d be >careful not to conceptualize it purely (or only) as an “engine for >off-loading work to in order to avoid the kernel/userland boundary cost” >since I think the concept has a much broader application than that. [and more good stuff] This is all heading down the road of Exokernel. Except that Exokernel did it with proof-carrying native code.[1] Once they had that (and a few other related pieces), they could use kernel code to define only the bare minimum security properties and push everything else into libraries -- network, filesystems, and so on -- without taking the huge performance hit of the pure Mach-style implementation with privilege-management servers and message-passing and stuff.[2] Other similar systems (of which I think BPF was the first, and certainly one of the first to be widely deployed) avoid the need for a rigorous proof of safety by deliberately limiting the computational power of their virtual machines. -GAWollman [1] If I remember correctly. It's been a long time. I should ask Frans, but it's a holiday so neither of us are in the office. [2] Once every decade or so, the concept of a "library operating system" comes back into vogue before being steamrolled by the market. This time around it might have more staying power, because manycore is here and monolithic operating systems do not scale nicely on 512-core processors.