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
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(),
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
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
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.
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
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
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
> >
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
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 +-
>
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
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
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
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
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
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
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:
> > > > > +
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>
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
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"
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, _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, _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, _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
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
30 matches
Mail list logo