--------
In message
<cabovn9dayqyd7oiah-mjg-a425h7ogccz39ack0xe_nbqhb...@mail.gmail.com>, Dridi
Boukelmoune writes:
>Interesting, for textual logs the effect of vsl_reclen is
>straightforward but how should we deal with binary records truncation?
Maybe redefine the limit to apply to individual strings (ie: header
values) rather than the full record ?
>> Some other lessons learned:
>>
>> The binary records are not necessarily shorter than the ASCII-formatted
>> records.
It is incredible how often people overlook this. I've been ranting
about it for almost two decades now, in particular in context of the
userland/kernel API.
Imagine if in addition to errno there also were a const char *errstr
which the kernel could fill out, that would do *wonders*, in particular
for EINVAL.
My favourite example was a Nx64 card where the driver spent more
than 35kloc of source code on defining a ton of structs for ioctl(2)
usage but no matter what the kernel found deficient, the only thing
it told you was return(EINVAL).
I threw out the entire thing and added a single ioctl which passed a
struct with an input string, containing a command like
"set chan 4 ts 4-12"
and another string out with an error message like:
"channel 11 already allocated to chan 5"
didn't even spend 1kloc on it...
>> comes to 48 bytes on my machine, about twice as long as a string like
>> "110 0 110 210 224 434". I don't think we can do much about that.
It depends what we know about the numbers.
For the 68K they had done a lot of statistics, and therefore their
relative jump instructions worked like this:
[opcode] 0x00 [16 bit signed displacement]
[opcode] 0xff [32 bit signed displacement]
[opcode] [8 bit signed displacement]
This gives good compression, without sinking in the
"variable length integers" like the crap in OSI/X509/H2/H3
Of course Motorola had the benefit that neither zero nor minus 1
gives any meaning as relative jump displacement.
We would probably want to sacrifice 0xfe rather than 0x00 (Benfords
Law and all that)
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@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.
_______________________________________________
varnish-dev mailing list
varnish-dev@varnish-cache.org
https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev
