> -----Original Message----- > From: Michael Richardson <mcr+ietf@xxxxxxxxxxxx> > Sent: Friday, July 7, 2023 10:57 AM > To: Dave Thaler <dthaler@xxxxxxxxxxxxx>; bpf@xxxxxxxx; bpf > <bpf@xxxxxxxxxxxxxxx> > Subject: Re: [Bpf] Instruction set extension policy > > Dave Thaler <dthaler=40microsoft.com@xxxxxxxxxxxxxx> wrote: > > Once the BPF ISA is published in an RFC, we expect more instructions > > may be added over time. It seems undesirable to delay use such > > additions until another RFC can be published, although having them > > appear in an RFC would be a good thing in my view. > > agreed. > > > Personally, I envision such additions to appear in an RFC per extension > > (i.e., set of additions) rather than obsoleting the original ISA RFC. > > So I would propose the ability to reference another document (e.g., one > > in the Linux kernel tree) in the meantime. > > That seems like a really good plan. > They won't have to be long documents either. > It would be nice if there could be sufficient template so that they don't need > a lot of cross-area review to publish. > > There is also a thought that there is simply a "yearly" wrap up of all > allocations. > > > Similarly, I would propose as a strawman using an IANA registry (as > > most IETF standards do) that requires say an IETF Standards Track RFC > > for "Permanent" status, and "Specification required" (a public > > specification reviewed by a designated expert) for "Provisional" > > registrations. So updating a document in say the Linux kernel tree > > would be sufficient for Provisional registration, and the status of an > > instruction would change to Permanent once it appears in an RFC. > > > Thoughts? > > I think it important to distinguish for the group between > experimental/private-use space and provisional. Yes. Right now I don't see a need to have experimental/private-use space. If anyone else does, please speak up. > I don't think you want to renumber an instruction when it goes to Permanent > status. Agree. As with the URI scheme registry, the assigned values need not change when something goes from Provisional to Permanent, only the status label changes. There is no numbering space division for Provisional. > I also think that you want to run this as Early Allocations, so that they > have a sunset clause, and the process for sunsetting such an allocation should > be clear. That's a fine discussion to have. Provisional URI schemes have no such sunset clause. I might argue that subset clauses are only useful when space is scarce. Right now, that's not the case when you consider opcode+src+imm as the space available. > You may also need to written policy (in the Linux kernel Documentation) > about back-patching of Provisional numbers into vendor branches and/or LTS > branches. > > Can there be subtle semantic changes to Provisional allocations? > (Such as what happens when invalid data occurs? The divide-by-zero > equivalent) I'd expect the answer to be the same as for Permanent allocations. Offhand, I would say "yes", though of course one needs a plan for backwards compatibility if so. Dave
