New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[FEATURE] Refactor bpftime for Enhanced Extensibility and Maintainability #202
Comments
Replacing of frida is already able through the attach manager (by subclassing) |
Split attach manager into a seperate target
Attach manager is relatively independent with runtime, it doesn't invoke any API of runtime. It only provide uprobe/uretprobe implementation to runtime (bpf_attach_ctx, by now). Besides, attach manager is the only part in bpftime that has strong dependency on Frida. So if we split attach manager into a seperate target, we might gain:
|
What about attach_ctx class? Is it possible to implement all uprobe/syscall related code outside of runtime target and runtime dir? If we can do that, is it a better solution? And also, there are some attach related code in syscall transformer and syscall-server.so |
The implementation of syscall trace is not compatible with attach manager(or let's call it uprobe attach manager)
So I think we might split syscall trace attach implementation into another target, just call it syscall trace attach manager. Syscall trace callbacks should be registered to this target, and this target should provide a dispatch entry(The function that text transformer would call, when syscall was captured). And rename the current attach manager to uprobe attach manager, since it's only responsible for uprobes |
So Maybe we can create two targets?
The attach is a new dir under the project root. And the user can specify which one to compile with the runtime. |
Shall we come up with some better name for Uprobe attach manager? Maybe attach_ctx back or attach_target, attach_events? Some background:
So maybe we can have a design like this:
These codes are all in the attach dir in project root. Another problem is, how can we make the attach_targets config what kinds of perf events or attached targets can be mocked in userspace, while others can be passed into the kernel? If we don't want to hardcode it in the -server.so like what we did now. |
Sounds good. More attach implementation could be added in the future |
This also soulds good. But the |
And the attach manager you mentioned seems to be something that is responsible for "resolving perf event (or other equivalent), and allowing a certain event to call a certain ebpf program". Did I mis-understand what you said? If not, I think this thing is more suitable for the name But from another perspective, I still think |
Yes, Can you describe the full dependency and classes inheritance of all the modules/cmake targets you think may be correct? I think it could be something like
|
And also, can we add the new attach event at load time? So it's not statically compiled. For example, we have three kinds agent.so:
We can let the agents or user config what functionality of syscalls it wants to mock in the syscall server.so. For example, allow some perf events syscall and bpf link types to be mock or response in the The config can be stored in the shared memory. So the new attached targets can register it. |
What does |
This sounds good |
have a unique ptr in the code, and responsible for managing the open and close of the maps, compile and load the progs. |
Maps and programs are held in the shared memory, and may live longer than agent or syscall server. So maybe their ownership should not be limited by bpftime runtime? |
"ownership" here means "stuff in the heap memory of a certain process that is required to operate shared memory". For example, the class bpftime_shm itself |
Targets
|
Is it better that you can first come up with a small example of how to use the new api to implement a new eBPF attach type (e.g. nginx module eBPF)? |
OK, I'll take it |
Refer to https://github.com/eunomia-bpf/bpftime-new-api-poc for detailed POC Other notes:
|
Instantiation of handler
|
Issue Summary:
The current
bpftime
architecture intermingles code for different eBPF program types and backends, such as uprobe and syscall tracing, within the syscall-server.so. For example:bpftime/runtime/include/bpf_attach_ctx.hpp
Lines 67 to 77 in 204f115
bpftime load
time with thesyscall-server.so
. For instance:bpftime/runtime/syscall-server/syscall_context.cpp
Lines 459 to 470 in d850554
This design limits the addition of new attach backends and eBPF program types, and also complicates the codebase. A refactor is proposed to address these issues and set the stage for future enhancements.
Proposed Changes:
Decouple Syscall Server Responsibilities:
syscall-server.so
and the daemon to only handle recording syscall traces and states, such as the creation of progs, maps, and links within the kernel.Split Attach Context:
attach context
class into two distinct targets,runtime
andattach_events
runtime
should offer two types of APIs:attach_events
class to implement their own event sources.Temporary Feature Development Freeze:
Future-Proofing and Extensibility:
runtime
statically in other applications, and expanding to new domains such as GPU tracing, XDP and [FEATURE] Add new attach types #158Rationale:
This refactor addresses fundamental design flaws that were not evident in the initial conception of
bpftime
. It aims to simplify the current codebase and prepare for more stable and scalable expansion. Although this entails a significant overhaul, it is manageable given the current code volume.Next Steps:
Call for Input:
We welcome input from the community on this proposed refactor. Any insights or suggestions, especially regarding the decoupling of components and API design, would be highly appreciated.
The text was updated successfully, but these errors were encountered: