Binary portability for BPF programs

Posted Dec 2, 2018 17:33 UTC (Sun) by marcH (subscriber, #57642)
In reply to: Binary portability for BPF programs by sorokin
Parent article: Binary portability for BPF programs

> People attribute the distinction to the difference between text and binary, instead of between key/value-based and sequence-based.

That confusion is because they're often the same in practice. Key/value means a parser is required, a parser is where the compatibility comes from. Protocols are often binary *because* designers want to just copy from/to memory with as little parsing as possible (just some sanity checks), for instance for performance reasons.

> Other changes (deleting key, renaming key) break backward-compatibility of key/value-based formats.

That's why newer versions rarely ever delete any key and only after a long period of deprecation and warnings and why would anyone rename a key?

> One can formulate another statement like "key/value-based formats have inherently better backward compatibility than sequence-based". Well this is only partially true.

Partially true... in theory.

Binary portability for BPF programs

Posted Dec 3, 2018 18:55 UTC (Mon) by mathstuf (subscriber, #69389) [Link] (1 responses)

> why would anyone rename a key?

I know that IETF handled it well (basically by just saying "oops, sorry"), but some people would not have been able to restrain themselves from fixing "Referer".

Binary portability for BPF programs

Posted Dec 3, 2018 19:20 UTC (Mon) by excors (subscriber, #95769) [Link]

Early versions of HTML5 even attempted to spread the misspelling to the new feature <a rel=noreferer>, for consistency with the HTTP header it refer(r)ed to. But then someone pointed out the DOM API for Referer was already called document.referrer, so HTML5 could switch to <a rel=noreferrer> without feeling guilty about being the first to break consistency.