script(2) [was: [CFT/review] new sendfile(2)]

[Alfred Perlstein]

Lua at the syscall level makes sense. :)

-Alfred

On 8/31/14 3:05 PM, Poul-Henning Kamp wrote:
> --------
> In message <540382E2.3040004 at 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
>