From owner-freebsd-arch@FreeBSD.ORG Sun Aug 31 23:33:27 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 8DFFE154 for ; Sun, 31 Aug 2014 23:33:27 +0000 (UTC) Received: from elvis.mu.org (elvis.mu.org [IPv6:2001:470:1f05:b76::196]) by mx1.freebsd.org (Postfix) with ESMTP id 6E9B51952 for ; Sun, 31 Aug 2014 23:33:27 +0000 (UTC) Received: from u10-2-16-021.office.norse-data.com (unknown [50.204.88.51]) by elvis.mu.org (Postfix) with ESMTPSA id 5D5C2346DE13; Sun, 31 Aug 2014 16:33:26 -0700 (PDT) Message-ID: <5403B13C.60008@freebsd.org> Date: Sun, 31 Aug 2014 16:35:24 -0700 From: Alfred Perlstein Organization: FreeBSD User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: freebsd-arch@freebsd.org, Poul-Henning Kamp Subject: Re: script(2) [was: [CFT/review] new sendfile(2)] References: <20140529102054.GX50679@FreeBSD.org> <20140729232404.GF43962@funkthat.com> <20140831165022.GE7693@FreeBSD.org> <540382E2.3040004@freebsd.org> <2770.1409522711@critter.freebsd.dk> In-Reply-To: <2770.1409522711@critter.freebsd.dk> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit 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 23:33:27 -0000 Lua at the syscall level makes sense. :) -Alfred On 8/31/14 3:05 PM, Poul-Henning Kamp wrote: > -------- > 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 >