On Fri, 7 Jul 2023 06:29:11 -0700 Breno Leitao wrote: > Create a new netconsole runtime option that prepends the kernel version in > the netconsole message. This is useful to map kernel messages to kernel > version in a simple way, i.e., without checking somewhere which kernel > version the host that sent the message is using. > > If this option is selected, then the "<release>," is prepended before the > netconsole message. This is an example of a netconsole output, with > release feature enabled: > > 6.4.0-01762-ga1ba2ffe946e;12,426,112883998,-;this is a test > > Calvin Owens send a RFC about this problem in 2016[1], but his > approach was a bit more intrusive, changing the printk subsystem. This > approach is lighter, and just append the information in the last mile, > just before netconsole push the message to netpoll. > > [1] Link: https://lore.kernel.org/all/51047c0f6e86abcb9ee13f60653b6946f8fcfc99.1463172791.git.calvinowens@xxxxxx/ > > Cc: Dave Jones <davej@xxxxxxxxxxxxxxxxx> > Signed-off-by: Breno Leitao <leitao@xxxxxxxxxx> Looks good! net-next is closed for the duration of the merge window so you'll need to repost next week, and please put [PATCH net-next v3] as the subject prefix while at it. > @@ -332,6 +350,11 @@ static ssize_t enabled_store(struct config_item *item, > } > > if (enabled) { /* true */ > + if (nt->release && !nt->extended) { > + pr_err("release feature requires extended log message\n"); > + goto out_unlock; > + } This is the only bit that gave me pause - when parsing the command line you ignore release if extended is not set (with an error/warning). Does it make sense to be consistent and do the same thing here? Or enabling at runtime is fundamentally different?