Lines Matching full:changes
53 In case your patch has changes in various different subsystems (e.g.
56 the changes and provide their Acked-by's to the patches.
78 their status in patchwork will be set to 'Changes Requested', and purged
83 Q: How do the changes make their way into Linux?
154 When changes have been requested to the patch series, always send the
189 complexity of changes and current patch load.
217 Q: Verifier changes and test cases
222 A: If the patch has changes to the behavior of the verifier, then yes,
225 needed, then we might ask for them before accepting any changes.
230 absolutely crucial to make sure future changes do not accidentally
261 and maps that are active in the kernel. If UAPI changes related to BPF
267 A: For UAPI changes related to the XDP or tc layer (e.g. ``cls_bpf``),
268 the convention is that those control-path related changes are added to
270 useful to have UAPI changes properly designed to be usable, but also
271 to make those changes available to a wider user base of major
291 applied to. Meaning, if kernel changes went into the net-next kernel
292 tree, then the related iproute2 changes need to go into the iproute2
323 describing the use-case for the changes is a must.
340 If you are unable to implement or test the required JIT changes for
350 In case of new BPF instructions, once the changes have been accepted
463 existing ones are adapted to verifier changes e.g. due to verifier