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

Net: Add net_log_scope setting #304

Open
solardiz opened this issue Feb 25, 2024 · 0 comments
Open

Net: Add net_log_scope setting #304

solardiz opened this issue Feb 25, 2024 · 0 comments
Labels
enhancement New feature or request

Comments

@solardiz
Copy link
Contributor

Nov 9, 2022

The initial implementation is sending all new kernel messages appearing since LKRG is loaded. We probably want to add a knob to choose between several modes:

  1. Send new LKRG messages only (no non-LKRG, no old).
  2. Send new LKRG and non-LKRG messages only (no old). This is the current behavior.
  3. Send all kernel messages (including old - that is, those buffered by the kernel prior to LKRG loading).

We could also have:

  1. Like 3 on first LKRG load, like 2 on subsequent reloads.

However, the implementation for 4 is tricky/hackish - how do we determine that LKRG had already been loaded in this kernel's uptime? We're going to go through the buffered messages anyway, and could infer from there, but this means going through them twice (first to see no mentions of LKRG, then to send the buffered messages). Alternatively, we could leave some in-kernel flag even upon LKRG unloading, so we could check it on a subsequent LKRG reload easily.

We could also easily have:

  1. Send all LKRG messages, including old (but no non-LKRG).

However, why would we? In case LKRG was loaded without networking, then is reloaded with networking? Sounds like too much of a special case to bother.

@solardiz solardiz added the enhancement New feature or request label Feb 25, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant