Add the following features for configuring the maximum log level
available:
* `max_level_off`
* `max_level_error`
* `max_level_warn`
* `max_level_info`
* `max_level_debug`
* `max_level_trace`
* `release_max_level_off`
* `release_max_level_error`
* `release_max_level_warn`
* `release_max_level_info`
* `release_max_level_debug`
* `release_max_level_trace`
Log invocations at disabled level will be skipped, which is especially
beneficial for eBPF programs which are not going to send unneceessary
logs through perf buffers.
Features with `release_` prefix are used only in release builds.
Those features have to applied on the userspace and eBPF crate
separately. The correct thing to do is to set them on the same level. In
case when userspace has higher maximum log level, it's not going to
recieve the logs beyond the filter in eBPF crate. In the opposite
situation, when eBPF crate has higher maximum level, it's going to waste
cycles on sending logs through perf buffer, while they are not going to
be displayed in the userspace.
Signed-off-by: Michal Rostecki <vadorovsky@gmail.com>
This change adds optional display hints:
* `{:x}`, `{:X}` - for hex representation of numbers
* `{:ipv4}`, `{:IPv4}` - for IPv4 addresses
* `{:ipv6}`, `{:IPv6}` - for IPv6 addresses
It also gets rid of dyn-fmt and instead comes with our own parser
implementation.
Tested on: https://github.com/vadorovsky/aya-examples/tree/main/tc
Signed-off-by: Michal Rostecki <vadorovsky@gmail.com>
This commit moves the aya-log projects from the subtree and adds them to
the main cargo workspace. It also brings the BPF crates into the
workspace and moves the macro crates up a level since they aren't BPF
code.
Miri was disabled for aya-bpf as the previous config wasn't actually
checking anything.
CI, clippy, fmt and release configurations have all been adjusted
appropriately.
CI was not properly running for other supported arches which was also
ixed here.
Signed-off-by: Dave Tucker <dave@dtucker.co.uk>
Michal Rostecki
Dave Tucker