-
-
Notifications
You must be signed in to change notification settings - Fork 0
/
commit_survey.yml
97 lines (91 loc) · 10.6 KB
/
commit_survey.yml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
title: "Commit Classification Survey"
description: "A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option."
hint: "For example, when seems not related to eBPF, confirm it's a rare cases really has nothing to do with eBPF in all it's contents, such as btrfs or misspelled commit message. Do not tag subsystem changes related to eBPF as not."
questions:
- id: summary
type: fill_in
question: "Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence."
required: true
- id: keywords
type: fill_in
question: "Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters."
required: true
- id: commit_classification
type: single_choice
question: "What may be the main type of the commit?"
choices:
- value: A bug fix. It primarily resolves a bug or issue in the code.
- value: A new feature. It adds a new capability or feature that was not previously present.
- value: A performance optimization. It improves the performance of existing code such as reducing latency or improving throughput.
- value: A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.
- value: A documentation change or typo fix. It only involves changes to documentation files or fixes a typographical error.
- value: A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.
- value: A build system or CI/CD change. It affects the build process continuous integration or deployment pipelines.
- value: A security fix. It resolves a security vulnerability or strengthens security measures.
- value: It's like a merge commit. It merges changes from another branch or repository.
- value: It's other type of commit. It does not fit into any of the categories listed above.
- value: I'm not sure about the type of the commit. The nature of It is unclear or uncertain.
- id: commit_complexity
type: single_choice
question: "What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference."
choices:
- value: Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.
- value: Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.
- value: Complex. Affects more than 100 lines or across 5 or more files. Involves significant changes such as adding new subsystems or refactoring core components requiring deep system knowledge.
- value: Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.
- value: Non-code or generated. The changes involve auto-generated code or dependency updates or large formatting commits. which may affect many lines but do not reflect typical code complexity.
- value: I'm not sure about the complexity of the commit. It is difficult to estimate the complexity based on the provided commit details.
- id: major_related_implementation_component
type: single_choice
question: "What major implementation component is modified by the commit? It's typically where the code changes happened."
choices:
- value: The eBPF verifier. This component ensures that eBPF programs are safe to run within the kernel.
- value: The eBPF JIT compiler for different architectures. It changes how eBPF bytecode is translated into machine code for different hardware architectures.
- value: The helper and kfuncs. It modifies or adds helpers and kernel functions that eBPF programs can call.
- value: The syscall interface. It changes the system calls through which user-space programs interact with eBPF.
- value: The eBPF maps. It changes how data structures shared between user-space and kernel-space (maps) are created or managed.
- value: The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.
- value: The bpftool utility. It modifies the bpftool utility used for introspecting and interacting with eBPF programs and maps.
- value: The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.
- value: The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.
- value: It's like a merge commit. It includes significant changes across multiple components of the system.
- value: It's not related to any above. It affects an implementation component not listed but does related to the BPF subsystem.
- value: It's not related to any above. It affects an implementation component is totally unrelated to the BPF subsystem. It's not related to any above because it totally not related to the BPF subsystem. It's a rare case wrong data and need removed.
- value: I'm not sure about the implementation component of the commit. The component affected by It is unclear.
- id: major_related_logic_component
type: single_choice
question: "What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier."
choices:
- value: A eBPF Instruction Logic. E.g. It changes how eBPF instructions are interpreted validated or executed by the eBPF virtual machine in the kernel.
- value: Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.
- value: eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.
- value: Control Plane interface Logic. E.g. It modifies the interface through which user-space programs control or interact with eBPF in the kernel.
- value: Maps Logic. E.g. It changes how eBPF maps are created accessed or managed by both user-space and kernel-space.
- value: BPF Type Format (BTF) Logic. E.g. It affects BTF which is used for CO-RE (Compile Once Run Everywhere) capabilities or changes how BPF programs interact with the verifier using BTF.
- value: It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.
- value: The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.
- value: It's not related to any above. E.g. It affects a logic component in eBPF that is not listed here and not related to other events.
- value: It's not related to any above because it totally not related to the BPF subsystem. The affected componenet and message has no interaction with BPF subsystem at all. It's a rare case wrong data and need removed.
- value: I'm not sure about the logic component of the commit. The affected logic component is unclear.
- id: usecases_or_submodule_events
type: multiple_choice
question: "What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted"
choices:
- value: XDP related type programs. It relates to programs handling high-performance packet processing through the XDP framework.
- value: Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic.
- value: tc related type programs. It affects programs managing traffic control (tc) for queuing or prioritizing network traffic.
- value: Netfilter related type programs. It impacts programs interacting with the Netfilter framework used in packet filtering and NAT.
- value: Tracepoints related type programs. It modifies programs that attach to tracepoints for low-level kernel event tracing.
- value: kprobe/ftrace like type kernel dynamic probe programs. It affects kernel-level probes used for tracing kernel functions. It can be other kernel probes in perf-events.
- value: uprobe/usdt like type user-space dynamic probe programs. It impacts user-space probes for tracing user-space applications. It can be other user-space probes in perf-events.
- value: Profile related type programs. It affects programs used for profiling system or application performance.
- value: LSM type related programs. It relates to eBPF programs used with Linux Security Modules (LSMs) for security enhancements.
- value: Struct_ops type related programs. It affects programs tha t allows user-defined methods to be called by subsystems.
- value: cgroup type related programs. It affects programs managing resource limits or network behavior via control groups (cgroups).
- value: HID driver related type programs. It relates to programs interacting with HID (Human Interface Devices) for input/output events.
- value: Scheduler related type programs. It modifies programs that interact with kernel-level scheduling mechanisms.
- value: It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.
- value: It's likely a merge commit. It involves changes across multiple use cases or events.
- value: It's not related to any above because it's other type of use cases or BPF programs related to the BPF subsystem but not listed here.
- value: It's not related to any above because it totally not related to the BPF subsystem. The affected componenet and message has no interaction with BPF subsystem at all. It's a rare case wrong data and need removed.
- value: I'm not sure about the use cases or events of the commit. The relationship between It and specific use cases or events is unclear.