Date: Sun, 31 Aug 2014 16:35:24 -0700 From: Alfred Perlstein <alfred@freebsd.org> To: freebsd-arch@freebsd.org, Poul-Henning Kamp <phk@phk.freebsd.dk> Subject: Re: script(2) [was: [CFT/review] new sendfile(2)] Message-ID: <5403B13C.60008@freebsd.org> In-Reply-To: <2770.1409522711@critter.freebsd.dk> References: <20140529102054.GX50679@FreeBSD.org> <20140729232404.GF43962@funkthat.com> <20140831165022.GE7693@FreeBSD.org> <540382E2.3040004@freebsd.org> <2770.1409522711@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
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
>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5403B13C.60008>