Dear David, Thank you very much for your lengthy and kind email. I agree that we should punt on contentious points and aim to standardize what has already been implemented across a wide range of implementations. Most of my issues are with the format and presentation of the text, and I think the content changes it would take are pretty noncontenous. I don't really have any insight into what the content should be, and I'm sure that for those who live and breath BPF every day, much of what I am confused about is indeed obvious. Concretely I think the following would help improve the understandability of the document: * After the register paragraph, describe the memory. As I understand it it is a 64 bit, byte addressed, flat space, and maps are just special regions in it. Maybe I'm wrong. There's some stuff about types in the big space of instructions that maybe makes me think I am wrong. * Say this is a 2's complement architecture * I finally understand why the code fields have their low nybble zero. We should maybe say this. * Explicitly call out after 5.2 that there is no memory model yet * Pull up section 5.3.1 to the top, or figure out some way to punt it to an extension. Maybe introduce maps up top then explain how they are indexed here. For extensions if I think I understand the conversation at IETF 117, it's easy to add more calls to the host system as functions. It's a lot more of a difficulty to add more instructions, but in the wide encoding space there is room. We could definitely say that. The memory model should only modify the behavior of environments with races, so if things aren't racy, nothing changes. That should work, but maybe I don't understand what other extensions that people would want to add. Verification might be an extension, but probably not in the sense we need to worry about it here? I hope the above is helpful: as always my ignorance can completely negate the value of the concrete suggestion, but I do hope it highlights areas that could use some TLC. Sincerely, Watson Ladd -- Astra mortemque praestare gradatim
