Lines Matching full:changes
47 Q: How do I run BPF CI on my changes before sending them out for review?
80 In case your patch has changes in various different subsystems (e.g.
83 the changes and provide their Acked-by's to the patches.
105 their status in patchwork will be set to 'Changes Requested', and purged
110 Q: How do the changes make their way into Linux?
183 When changes have been requested to the patch series, always send the
219 complexity of changes and current patch load.
248 Q: Verifier changes and test cases
253 A: If the patch has changes to the behavior of the verifier, then yes,
256 needed, then we might ask for them before accepting any changes.
261 absolutely crucial to make sure future changes do not accidentally
292 and maps that are active in the kernel. If UAPI changes related to BPF
298 A: For UAPI changes related to the XDP or tc layer (e.g. ``cls_bpf``),
299 the convention is that those control-path related changes are added to
301 useful to have UAPI changes properly designed to be usable, but also
302 to make those changes available to a wider user base of major
322 applied to. Meaning, if kernel changes went into the net-next kernel
323 tree, then the related iproute2 changes need to go into the iproute2
354 describing the use-case for the changes is a must.
371 If you are unable to implement or test the required JIT changes for
381 In case of new BPF instructions, once the changes have been accepted
516 existing ones are adapted to verifier changes e.g. due to verifier