From owner-freebsd-arch@FreeBSD.ORG Sun Aug 31 22:05:20 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7CBDC63A; Sun, 31 Aug 2014 22:05:20 +0000 (UTC) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id B83AF1F4B; Sun, 31 Aug 2014 22:05:19 +0000 (UTC) Received: from critter.freebsd.dk (unknown [192.168.60.3]) by phk.freebsd.dk (Postfix) with ESMTP id 3D11116D0; Sun, 31 Aug 2014 22:05:13 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.9/8.14.9) with ESMTP id s7VM5B5v002771; Sun, 31 Aug 2014 22:05:12 GMT (envelope-from phk@phk.freebsd.dk) To: Alfred Perlstein Subject: Re: script(2) [was: [CFT/review] new sendfile(2)] In-reply-to: <540382E2.3040004@freebsd.org> From: "Poul-Henning Kamp" References: <20140529102054.GX50679@FreeBSD.org> <20140729232404.GF43962@funkthat.com> <20140831165022.GE7693@FreeBSD.org> <540382E2.3040004@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <2769.1409522711.1@critter.freebsd.dk> Date: Sun, 31 Aug 2014 22:05:11 +0000 Message-ID: <2770.1409522711@critter.freebsd.dk> Cc: Gleb Smirnoff , 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: Sun, 31 Aug 2014 22:05:20 -0000 -------- In message <540382E2.3040004@freebsd.org>, Alfred Perlstein writes: Can I inject an old idea whose time may finally have arrived ? The basic thing we are trying to do here is to avoid userland/kernel context-switches, because they are so expensive. This is a very old problem, the TTY line-disciplines, PCAP, accept filters and sendfile are all hacks that try to "optimize" specific use-cases. Imagine we instead define a byte-code-engine which interprets a string of commands, sort of like the pcap filtering engine already does. The corresponding syscall would be "follow_the_script(2)" The first set of commands in the language would be a sensible subset of syscalls and library functions open file close file accept() read() write() memcpy() ... All of these functions works *exactly* the same as they would have in userland, arguments mean exactly the same etc. The value of this facility explodes as we add smarter commands which can do stuff we would normally have to return to userland for: if {...} else {...} for(;;) {...} do {...} while() move bytes (directly) from fd to fd (optional: in the background) read at least N bytes write with timeout interpret [bl]e{8,16,32,64} at address search for pattern X By suitably defining commands in the bytecode, pretty much all of sendfile and accept-filters can be implemented using this facility instead. PCAP and ldisc are probably to entrenched to be worth the bother, and neither are not relevant in typical network server usage. One reason I think this ideas time as come is that the current proposal for HTTP/2.0 is a mess, and will be very hard to implement to anything approaching wire-speed without such a facility. And yes, if we go far enough, you can basically push an entire static-content HTTP/1.1 server into the kernel that way... Of course the language has to be safe to execute in the kernel: Hard boundary checks, copyin/copyout and all that, but that is not rocket science: PCAP solved it ages ago. And it's really not that hard to implement... Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.