Skip to content
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

UI/UX design - suggestions welcome! #3

Open
JoshMcguigan opened this issue Jan 21, 2022 · 1 comment
Open

UI/UX design - suggestions welcome! #3

JoshMcguigan opened this issue Jan 21, 2022 · 1 comment
Labels
help wanted Extra attention is needed

Comments

@JoshMcguigan
Copy link
Owner

JoshMcguigan commented Jan 21, 2022

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!

@JoshMcguigan JoshMcguigan added the help wanted Extra attention is needed label Jan 21, 2022
@pothos
Copy link

pothos commented Feb 20, 2023

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
help wanted Extra attention is needed
Projects
None yet
Development

No branches or pull requests

2 participants