Watson, thank you! On Fri, Aug 11, 2023 at 5:36 PM Watson Ladd <watsonbladd@xxxxxxxxx> wrote: > > 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 just wanted to quickly follow up on this ... I, too, believe that we should say this in the ISA and put forward a patch with some language. You can see the discussion about that here: https://lore.kernel.org/bpf/20230710215818.gCPVzgaK-YEXRFNixwcVrMLKlkiM0FqkQbUytFlDTQQ@z/ Thank you, again, for the conversation! Will > * 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 > > -- > Bpf mailing list > Bpf@xxxxxxxx > https://www.ietf.org/mailman/listinfo/bpf
