> -----Original Message----- > From: David Vernet <void@xxxxxxxxxxxxx> > Sent: Monday, May 20, 2024 4:18 PM > To: Dave Thaler <dthaler1968@xxxxxxxxxxxxxx> > Cc: bpf@xxxxxxxxxxxxxxx; bpf@xxxxxxxx; Dave Thaler <dthaler1968@xxxxxxxxx> > Subject: Re: [PATCH bpf-next] bpf, docs: Use RFC 2119 language for ISA > requirements > > On Fri, May 17, 2024 at 09:58:55AM -0700, Dave Thaler wrote: > > Per IETF convention and discussion at LSF/MM/BPF, use MUST etc. > > keywords as requested by IETF Area Director review. Also as > > requested, indicate that documenting BTF is out of scope of this > > document and will be covered by a separate IETF specification. > > > > Added paragraph about the terminology that is required IETF > > boilerplate and must be worded exactly as such. > > > > Signed-off-by: Dave Thaler <dthaler1968@xxxxxxxxxxxxxx> > > Acked-by: David Vernet <void@xxxxxxxxxxxxx> > > We still have "may" in a couple of places, as in e.g.: > > Note that there are two flavors of ``JA`` instructions. The ``JMP`` class permits a > 16-bit jump offset specified by the 'offset' field, whereas the ``JMP32`` class > permits a 32-bit jump offset specified by the 'imm' field. A > 16-bit conditional jump > may be converted to a < 16-bit conditional jump plus a 32-bit unconditional jump. > > Also in the "Helper functions" and "Maps" sections. > > Do we need to fix those as well? Or are they considered semantically different > than how RFC 2119 would define the terms? Those are semantically different (i.e., I left them intentionally) as they are not normative statements about what an ISA implementer would choose to do or not do, but rather informative statements to the reader that would be synonymous with "can" or "might" in my reading. Dave > > Thanks, > David
