On Mon, 2021-04-19 at 11:53 +0200, Greg Kroah-Hartman wrote:
> Hm, 12734 of the pr_err() calls do live in drivers/, so most of those
> should be dev_err(). Might be something good to throw at interns...
That depends on how much churn you want to have in old drivers that
generally don't have any u
On Mon, Apr 19, 2021 at 11:16:43AM +0200, Petr Mladek wrote:
> On Mon 2021-04-19 09:27:43, Rasmus Villemoes wrote:
> > On 16/04/2021 15.56, Chris Down wrote:
> > > Hey Petr, Rasmus,
> >
> > >> This is great point! There are many other subsystem specific wrappers,
> > >> e,g, ata_dev_printk(), netd
On Mon 2021-04-19 09:27:43, Rasmus Villemoes wrote:
> On 16/04/2021 15.56, Chris Down wrote:
> > Hey Petr, Rasmus,
>
> >> This is great point! There are many other subsystem specific wrappers,
> >> e,g, ata_dev_printk(), netdev_printk(), snd_printk(), dprintk().
> >> We should make it easy to inde
On 16/04/2021 15.56, Chris Down wrote:
> Hey Petr, Rasmus,
>> This is great point! There are many other subsystem specific wrappers,
>> e,g, ata_dev_printk(), netdev_printk(), snd_printk(), dprintk().
>> We should make it easy to index them as well.
>
> These would be nice to have, but we should
Joe Perches writes:
On Fri, 2021-04-16 at 14:56 +0100, Chris Down wrote:
Any better suggestions? :-)
A gcc plugin that looks for functions marked __printf(fmt, pos)
so any const fmt is stored.
I fail to see any way in which that can solve the problem described, which is
mobility of the leve
On Fri, 2021-04-16 at 14:56 +0100, Chris Down wrote:
> Any better suggestions? :-)
A gcc plugin that looks for functions marked __printf(fmt, pos)
so any const fmt is stored.
Hey Petr, Rasmus,
Apologies for the delay, I've been out ill for a while so I'm just coming back
to look at this.
Petr Mladek writes:
Anyway, on to the other thing I mentioned on dev_err and friends: I
think it would improve readability and make it a lot easier to (probably
in a later patch)
On Thu 2021-03-18 12:31:44, Rasmus Villemoes wrote:
> On 18/03/2021 11.46, Petr Mladek wrote:
>
> > BTW: Is the trick with int (printk)(const char *s, ...) documented
> > somewhere? Is it portable?
>
> It is completely standard and portable C, explicitly spelled out in the
> C standard itself. C9
On 18/03/2021 11.46, Petr Mladek wrote:
> BTW: Is the trick with int (printk)(const char *s, ...) documented
> somewhere? Is it portable?
It is completely standard and portable C, explicitly spelled out in the
C standard itself. C99:
===
6.10.3 Macro replacement
10 [...] Each subsequent instanc
On Wed 2021-03-17 11:03:20, Rasmus Villemoes wrote:
> On 17/03/2021 09.40, Petr Mladek wrote:
> > On Tue 2021-03-16 14:28:12, Chris Down wrote:
> >> Rasmus Villemoes writes:
> >>> I think it's pointless renaming the symbol to _printk, with all the
> >>> churn and reduced readability that involves (
On 17/03/2021 09.40, Petr Mladek wrote:
> On Tue 2021-03-16 14:28:12, Chris Down wrote:
>> Rasmus Villemoes writes:
>>> I think it's pointless renaming the symbol to _printk, with all the
>>> churn and reduced readability that involves (especially when reading
>>> assembly "why are we calling _prin
On Tue 2021-03-16 14:28:12, Chris Down wrote:
> Rasmus Villemoes writes:
> > I think it's pointless renaming the symbol to _printk, with all the
> > churn and reduced readability that involves (especially when reading
> > assembly "why are we calling _printk and not printk here?"). There's
> > noth
Rasmus Villemoes writes:
I think it's pointless renaming the symbol to _printk, with all the
churn and reduced readability that involves (especially when reading
assembly "why are we calling _printk and not printk here?"). There's
nothing wrong with providing a macro wrapper by the same name
#de
On 10/03/2021 03.30, Chris Down wrote:
> ---
> MAINTAINERS | 5 +
> arch/arm/kernel/entry-v7m.S | 2 +-
> arch/arm/lib/backtrace-clang.S | 2 +-
> arch/arm/lib/backtrace.S | 2 +-
> arch/arm/mach-rpc/io-acorn.S | 2 +-
> arch/a
Petr Mladek writes:
In my mind, pi_start is really just a special case of pi_next, so the code
flow makes sense to me. I'm happy to change it to whatever you like, but
it's not immediately obvious to me what that is :-)
Good question! I have missed that pi_start() can be called also with non-ze
On Mon 2021-03-15 12:20:59, Chris Down wrote:
> Petr Mladek writes:
> > > I don't feel strongly that this is more clear though, so maybe you
> > > mean something else?
> >
> > I was pretty tired when reviewing the patch. It was not easy for me
> > to create the mental model of the code. I felt tha
Petr Mladek writes:
I don't feel strongly that this is more clear though, so maybe you
mean something else?
I was pretty tired when reviewing the patch. It was not easy for me
to create the mental model of the code. I felt that some other names
would have made it easier.
Also the tricky pi_nex
On Fri 2021-03-12 13:53:20, Chris Down wrote:
> Ack to all unmentioned suggestions. :-)
>
> Petr Mladek writes:
> > > + changed or no longer present.
> > > +
> > > + There is no additional runtime cost to printk with this enabled.
> > > +
> > > #
> > > # Architectures with an unreliable sche
Ack to all unmentioned suggestions. :-)
Petr Mladek writes:
+ changed or no longer present.
+
+ There is no additional runtime cost to printk with this enabled.
+
#
# Architectures with an unreliable sched_clock() should select this:
#
diff --git a/kernel/module.c b/kernel/mod
On Wed 2021-03-10 02:30:31, Chris Down wrote:
> 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
On Thu, Mar 11, 2021 at 10:34:46AM +0100, Petr Mladek wrote:
> On Wed 2021-03-10 13:16:43, Greg Kroah-Hartman wrote:
> > On Wed, Mar 10, 2021 at 12:12:57PM +, Chris Down wrote:
> > > Greg Kroah-Hartman writes:
> > > > On Wed, Mar 10, 2021 at 02:30:31AM +, Chris Down wrote:
> > > > > + p
On Wed 2021-03-10 13:16:43, Greg Kroah-Hartman wrote:
> On Wed, Mar 10, 2021 at 12:12:57PM +, Chris Down wrote:
> > Greg Kroah-Hartman writes:
> > > On Wed, Mar 10, 2021 at 02:30:31AM +, Chris Down wrote:
> > > > + ps->file = debugfs_create_file(pi_get_module_name(mod), 0444,
> > > >
On Wed 2021-03-10 12:17:51, Chris Down wrote:
> Hey Petr,
>
> Chris Down writes:
> >$ head -1 vmlinux; shuf -n 5 vmlinux
> ># filename:line function "format"
> ><5> block/blk-settings.c:661 disk_stack_limits "%s: Warning: Device %s
> > is misaligned\n"
> ><4> kernel/trace/trace.c
Hi Chris,
I love your 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 uml/linux-next tip/x86/core asm-generic/master linus/master
v5.12-rc2]
[cannot apply to pmladek/for-next next-20
Hey Petr,
Chris Down writes:
$ head -1 vmlinux; shuf -n 5 vmlinux
# filename:line function "format"
<5> block/blk-settings.c:661 disk_stack_limits "%s: Warning: Device %s is
misaligned\n"
<4> kernel/trace/trace.c:8296 trace_create_file "Could not create tracefs '%s'
entry\n"
<6
On Wed, Mar 10, 2021 at 12:12:57PM +, Chris Down wrote:
> Greg Kroah-Hartman writes:
> > On Wed, Mar 10, 2021 at 02:30:31AM +, Chris Down wrote:
> > > + ps->file = debugfs_create_file(pi_get_module_name(mod), 0444, dfs_index,
> > > +ps, &dfs_index_fops);
> >
Greg Kroah-Hartman writes:
On Wed, Mar 10, 2021 at 02:30:31AM +, Chris Down wrote:
+ ps->file = debugfs_create_file(pi_get_module_name(mod), 0444, dfs_index,
+ ps, &dfs_index_fops);
+
+ if (IS_ERR(ps->file)) {
+ pi_sec_remove(mod
On Wed, Mar 10, 2021 at 02:30:31AM +, Chris Down wrote:
> + ps->file = debugfs_create_file(pi_get_module_name(mod), 0444, dfs_index,
> +ps, &dfs_index_fops);
> +
> + if (IS_ERR(ps->file)) {
> + pi_sec_remove(mod);
> + return;
>
Hi Chris,
I love your 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 uml/linux-next tip/x86/core asm-generic/master linus/master
v5.12-rc2]
[cannot apply to pmladek/for-next next-20
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
30 matches
Mail list logo
