kernel test robot writes:
All errors (new ones prefixed by >>):
/usr/bin/ld: arch/um/drivers/xterm.o: in function `xterm_open':
xterm.c:(.text+0x16b): undefined reference to `printk'
/usr/bin/ld: xterm.c:(.text+0x1a8): undefined reference to `printk'
/usr/bin/ld: xterm.c:(.text+0x1f4): und
Hi Chris,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on jeyu/modules-next]
[also build test ERROR on linux/master soc/for-next openrisc/for-next
powerpc/next asm-generic/master linus/master v5.11-rc6 next-20210125]
[cannot apply to tip/x86/core]
[If your patch is a
Chris Down writes:
3. `KERN_SOH + level' can appear in other places than just printk strings
KERN_SOH is just ASCII '\001' -- it's not distinctive or unique, even when
paired with a check for something that looks like a level after it. For this
reason, your proposed patch results in a non-trivia
Joe Perches writes:
There are several issues with your proposed approach that make it unsuitable
for use as part of a reliable production environment:
1. It misses printk() formats without KERN_SOH
printk() formats without KERN_SOH are legal and use MESSAGE_LOGLEVEL_DEFAULT.
On my test kernel,
On Sun, 2021-02-07 at 14:13 +, Chris Down wrote:
> Joe Perches writes:
> > > There are certainly printks which can't be trivially monitored using the
> > > printk
> > > format alone, but the vast majority of the ones that are monitored _do_
> > > have
> > > meaningful formats and can be monit
Joe Perches writes:
There are certainly printks which can't be trivially monitored using the printk
format alone, but the vast majority of the ones that are monitored _do_ have
meaningful formats and can be monitored over time. No solution to this is going
to catch every single case, especially w
On Sat, 2021-02-06 at 21:21 +, Chris Down wrote:
> Joe Perches writes:
> > On Fri, 2021-02-05 at 22:25 +, Chris Down wrote:
> > > Petr Mladek writes:
> > > > + is already optinaly added by pr_fmt() to the printed
> > > > strings
> > > > as: pr_fmt(): ...
> > >
> > > pr_fmts are no
Joe Perches writes:
On Fri, 2021-02-05 at 22:25 +, Chris Down wrote:
Petr Mladek writes:
> + is already optinaly added by pr_fmt() to the printed strings
> as: pr_fmt(): ...
pr_fmts are not consistently used across the kernel, and sometimes differ from
the module itself. Many module
On Fri, 2021-02-05 at 22:25 +, Chris Down wrote:
> Petr Mladek writes:
> > + is already optinaly added by pr_fmt() to the printed strings
> > as: pr_fmt(): ...
>
> pr_fmts are not consistently used across the kernel, and sometimes differ
> from
> the module itself. Many modules don't
Greg Kroah-Hartman writes:
> I'm not against the idea. I don't think it belongs in /proc. Perhaps
> debugfs is a better place to put it.
Any location is fine with me, as long as it gets to userspace. How does
/printk/formats or /printk/formats/ sound to you?
That's fine with me, but I'd like t
On Fri, Feb 05, 2021 at 10:45:19PM +, Chris Down wrote:
> Hi Steven,
>
> Steven Rostedt writes:
> > Interesting, because when I was looking at the original patch (looked at
> > the lore link before reading your reply), I thought to myself "this looks
> > exactly like what I did for trace_print
On Fri, 5 Feb 2021 22:45:19 +
Chris Down wrote:
> >I'm not against the idea. I don't think it belongs in /proc. Perhaps
> >debugfs is a better place to put it.
>
> Any location is fine with me, as long as it gets to userspace. How does
> /printk/formats or /printk/formats/ sound to you?
Hi Petr,
Thanks for looking over the patch. :-)
Petr Mladek writes:
Most production issues come from unexpected phenomena, and as such
usually the code in question doesn't have easily usable tracepoints or
other counters available for the specific problem being mitigated. We
have a number of li
Hi Steven,
Steven Rostedt writes:
Interesting, because when I was looking at the original patch (looked at
the lore link before reading your reply), I thought to myself "this looks
exactly like what I did for trace_printk formats", which the above file is
where it is shown. I'm curious if this w
Oh, and one more I just spotted and will fix in v2 after other feedback is in:
Chris Down writes:
+static void store_printk_fmt_sec(const struct module *mod, const char **start,
+const char **end)
+{
+ struct printk_fmt_sec *ps = NULL;
+ const char **f
On Fri, 5 Feb 2021 17:42:55 +0100
Petr Mladek wrote:
> Hi,
>
> I would like to hear opinion from a bigger audience. It is an
> userspace interface that we might need to maintain forewer.
> Adding few more people in to CC:
>
> Steven Rostedt : printk co-maintainer
Thanks for Cc'ing me.
> Alexe
Hi,
I would like to hear opinion from a bigger audience. It is an
userspace interface that we might need to maintain forewer.
Adding few more people in to CC:
Steven Rostedt : printk co-maintainer
Alexey Dobriyan : fs/proc maintainer
Greg Kroah-Hartman : sysfs maintainer
Jason Baron : dynamic_deb
Some improvements I noticed that I'll include when sending v2.
Chris Down writes:
+static void remove_printk_fmt_sec(const struct module *mod)
+{
+ struct printk_fmt_sec *tmp = NULL, *ps = NULL;
+ const char **fptr = NULL;
fptr can be scoped to list_for_each_entry_safe, I'll move i
We have a number of systems industry-wide that have a subset of their
functionality that works as follows:
1. Receive a message from local kmsg, serial console, or netconsole;
2. Apply a set of rules to classify the message;
3. Do something based on this classification (like scheduling a
remedi
19 matches
Mail list logo
