You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is a general issue to discussion ideas/comments regarding the user experience of backlight - primarily focused on the CLI for now. See #4 for discussion of a backlight library / API.
The general philosophy of the current implementation is to trace everything by default, and when the user starts filtering remove everything that isn't explicitly asked for. I think this provides a reasonable balance of discoverability and control.
I'll start things off with some questions/thoughts I've had so far:
Are the current CLI short flags a good choice (this can easily get bikeshed-y but meh)?
Should we try to mimic the ltrace API, or move away from it?
How to best help the user when they add library or syscall filters?
What if they filter by a library function that never gets linked? We have to be careful here because the tracee could always dlopen/dlsym and call something at runtime based on some condition which we don't always see
I often don't care about tracing anything before main
There should at least be an option for this, but perhaps it should be the default?
Filters currently require an exact match, should they be assumed *SEARCH_TERM*?
Or should we support regex or some other format? (I think ltrace does something fancy here)
Currently backlight has a subcommand trace, which is for now the only subcommand and thus redundant - should this be removed? Or else what other subcommands might there be?
I'm open to feedback on any of the above, as well as any new thoughts/opinions!
The text was updated successfully, but these errors were encountered:
I think the current behavior makes sense. However, I also think a way to suppress certain events would be good while still tracing all other events (unless a filter is set).
In addition I think that an aggregation mode would be nice to have to get an overview without having to suppress a long list of events that come too often. The aggregation mode could count the events that happen per second (or a configurable duration) and then print them delayed with annotations of how often they have been seen.
This is a general issue to discussion ideas/comments regarding the user experience of backlight - primarily focused on the CLI for now. See #4 for discussion of a backlight library / API.
The general philosophy of the current implementation is to trace everything by default, and when the user starts filtering remove everything that isn't explicitly asked for. I think this provides a reasonable balance of discoverability and control.
I'll start things off with some questions/thoughts I've had so far:
main
*SEARCH_TERM*
?I'm open to feedback on any of the above, as well as any new thoughts/opinions!
The text was updated successfully, but these errors were encountered: