[FEATURE] Rename agent_config to runtime_config

[yunwei37]

Is your feature request related to a problem? Please describe.

As time envolve, The agent config in https://github.com/eunomia-bpf/bpftime/blob/master/runtime/include/bpftime_config.hpp is no longer only for the agent. It should contain all the runtime config.

And also, the two config in

bpftime/runtime/syscall-server/syscall_context.cpp

Line 35 in 87a8901

const char *run_with_kernel_env = getenv("BPFTIME_RUN_WITH_KERNEL");

should be merged into the runtime config data struct and init in

bpftime/runtime/src/bpftime_config.cpp

Line 41 in 87a8901

const agent_config bpftime::get_agent_config_from_env()

Describe the solution you'd like

• Rename all agent_config to runtime_config.
• Move the config in syscall-server to bpftime_config

[Officeyutong]

Should we consider using configuration library like https://www.boost.org/doc/libs/1_85_0/libs/config/doc/html/index.html ?

Since it will be more convenient to manage and parse configuration from multiple sources

[yunwei37]

It seems what you mentioned is not a config library, but how to config the boost library for different compiler/usecases

[yunwei37]

Any recommendations for libraries?

[yunwei37]

https://github.com/hyperrealm/libconfig maybe?

It seems our configurations are simple and don't need such libraries for management

[Officeyutong]

Any recommendations for libraries?

Sorry, my fault, too sleepy now. Try libconfig

[Officeyutong]

https://github.com/hyperrealm/libconfig maybe?

It seems our configurations are simple and don't need such libraries for management

Yes, this is what I would like to reocmmend. Though the configuration structure of bpftime is simple now, but it has a big chance to get more complicated in the future.

[yunwei37]

it has a big chance to get more complicated in the future

well...what kinds of new configuration would bpftime have in the future? I'm not quite sure about that.

I would suggest that we focus on the small number of configurations we have now, and don't need a library to handle that

[Officeyutong]

it has a big chance to get more complicated in the future

well...what kinds of new configuration would bpftime have in the future? I'm not quite sure about that.

I would suggest that we focus on the small number of configurations we have now, and don't need a library to handle that

Ok, let's focus on configurations now and don't adopt a config library