Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1721358 > unrolled thread

printk: what is going on with additional newlines?

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  printk: what is going on with additional newlines? Pavel Machek <pavel@ucw.cz> - 2017-08-28 11:10 +0200
    Re: printk: what is going on with additional newlines? Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> - 2017-08-28 12:30 +0200
      Re: printk: what is going on with additional newlines? Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> - 2017-08-28 14:30 +0200
        Re: printk: what is going on with additional newlines? Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> - 2017-08-28 14:40 +0200
        Re: printk: what is going on with additional newlines? Pavel Machek <pavel@ucw.cz> - 2017-08-28 14:50 +0200
          Re: printk: what is going on with additional newlines? Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> - 2017-08-29 15:50 +0200
            Re: printk: what is going on with additional newlines? Joe Perches <joe@perches.com> - 2017-08-29 18:40 +0200
            Re: printk: what is going on with additional newlines? Linus Torvalds <torvalds@linux-foundation.org> - 2017-08-29 19:10 +0200
              Re: printk: what is going on with additional newlines? Linus Torvalds <torvalds@linux-foundation.org> - 2017-08-29 19:20 +0200
                Re: printk: what is going on with additional newlines? Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> - 2017-08-29 22:50 +0200
                  Re: printk: what is going on with additional newlines? Linus Torvalds <torvalds@linux-foundation.org> - 2017-08-29 23:00 +0200
                    Re: printk: what is going on with additional newlines? Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> - 2017-09-02 08:20 +0200
                      Re: printk: what is going on with additional newlines? Linus Torvalds <torvalds@linux-foundation.org> - 2017-09-02 19:10 +0200
                Re: printk: what is going on with additional newlines? Steven Rostedt <rostedt@goodmis.org> - 2017-08-30 02:00 +0200
                  Re: printk: what is going on with additional newlines? Linus Torvalds <torvalds@linux-foundation.org> - 2017-08-30 02:00 +0200
                  Re: printk: what is going on with additional newlines? Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> - 2017-08-30 03:10 +0200
                    Re: printk: what is going on with additional newlines? Steven Rostedt <rostedt@goodmis.org> - 2017-08-30 03:20 +0200
                      Re: printk: what is going on with additional newlines? Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> - 2017-08-30 03:50 +0200
                      Re: printk: what is going on with additional newlines? Joe Perches <joe@perches.com> - 2017-08-30 04:00 +0200
                        Re: printk: what is going on with additional newlines? Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> - 2017-08-30 04:30 +0200
                          Re: printk: what is going on with additional newlines? Joe Perches <joe@perches.com> - 2017-08-30 04:40 +0200
                            Re: printk: what is going on with additional newlines? Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> - 2017-08-30 04:50 +0200
                              Re: printk: what is going on with additional newlines? Joe Perches <joe@perches.com> - 2017-08-30 05:00 +0200
                                Re: printk: what is going on with additional newlines? Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> - 2017-08-30 07:40 +0200
                                  Re: printk: what is going on with additional newlines? Pavel Machek <pavel@ucw.cz> - 2017-09-08 12:20 +0200
                              Re: printk: what is going on with additional newlines? Petr Mladek <pmladek@suse.com> - 2017-09-05 11:50 +0200
                                Re: printk: what is going on with additional newlines? Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> - 2017-09-05 12:10 +0200
                                  Re: printk: what is going on with additional newlines? Petr Mladek <pmladek@suse.com> - 2017-09-05 14:30 +0200
                                    Re: printk: what is going on with additional newlines? Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> - 2017-09-05 14:40 +0200
                                      Re: printk: what is going on with additional newlines? Sergey Senozhatsky <sergey.senozhatsky@gmail.com> - 2017-09-05 16:30 +0200
                                    Re: printk: what is going on with additional newlines? Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> - 2017-09-05 15:50 +0200
                                      Re: printk: what is going on with additional newlines? Petr Mladek <pmladek@suse.com> - 2017-09-06 10:00 +0200
                      Re: printk: what is going on with additional newlines? Sergey Senozhatsky <sergey.senozhatsky@gmail.com> - 2017-09-01 15:30 +0200
                        Re: printk: what is going on with additional newlines? Joe Perches <joe@perches.com> - 2017-09-01 19:40 +0200
                          Re: printk: what is going on with additional newlines? Linus Torvalds <torvalds@linux-foundation.org> - 2017-09-01 22:30 +0200
                            Re: printk: what is going on with additional newlines? Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> - 2017-09-04 07:30 +0200
                              Re: printk: what is going on with additional newlines? Joe Perches <joe@perches.com> - 2017-09-04 07:50 +0200
                              Re: printk: what is going on with additional newlines? Steven Rostedt <rostedt@goodmis.org> - 2017-09-05 17:00 +0200
                                Re: printk: what is going on with additional newlines? Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> - 2017-09-06 04:20 +0200
                                Re: printk: what is going on with additional newlines? Linus Torvalds <torvalds@linux-foundation.org> - 2017-09-06 04:40 +0200
                          Re: printk: what is going on with additional newlines? Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> - 2017-09-04 06:40 +0200
                            Re: printk: what is going on with additional newlines? Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> - 2017-09-04 07:30 +0200
              Re: printk: what is going on with additional newlines? Sergey Senozhatsky <sergey.senozhatsky@gmail.com> - 2017-08-29 19:40 +0200
                Re: printk: what is going on with additional newlines? Linus Torvalds <torvalds@linux-foundation.org> - 2017-08-29 20:00 +0200
                  Re: printk: what is going on with additional newlines? Joe Perches <joe@perches.com> - 2017-08-29 20:10 +0200
                    Re: printk: what is going on with additional newlines? Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> - 2017-08-30 03:10 +0200
                  Re: printk: what is going on with additional newlines? Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> - 2017-08-30 03:00 +0200
    Re: printk: what is going on with additional newlines? Linus Torvalds <torvalds@linux-foundation.org> - 2017-08-29 18:50 +0200
      Re: printk: what is going on with additional newlines? Joe Perches <joe@perches.com> - 2017-08-29 19:20 +0200
        Re: printk: what is going on with additional newlines? Linus Torvalds <torvalds@linux-foundation.org> - 2017-08-29 19:30 +0200
          Re: printk: what is going on with additional newlines? Joe Perches <joe@perches.com> - 2017-08-29 19:40 +0200
            Re: printk: what is going on with additional newlines? Linus Torvalds <torvalds@linux-foundation.org> - 2017-08-29 19:40 +0200
              Re: printk: what is going on with additional newlines? Joe Perches <joe@perches.com> - 2017-08-29 19:50 +0200
      Re: printk: what is going on with additional newlines? Pavel Machek <pavel@ucw.cz> - 2017-08-29 22:30 +0200
        Re: printk: what is going on with additional newlines? Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> - 2017-09-01 03:50 +0200
          Re: printk: what is going on with additional newlines? Joe Perches <joe@perches.com> - 2017-09-01 04:10 +0200
            Re: printk: what is going on with additional newlines? Pavel Machek <pavel@ucw.cz> - 2017-09-01 09:00 +0200
              Re: printk: what is going on with additional newlines? Joe Perches <joe@perches.com> - 2017-09-01 09:30 +0200
          Re: printk: what is going on with additional newlines? Pavel Machek <pavel@ucw.cz> - 2017-09-01 09:30 +0200
            Re: printk: what is going on with additional newlines? Steven Rostedt <rostedt@goodmis.org> - 2017-09-01 13:20 +0200

Page 3 of 3 — ← Prev page 1 2 [3]

#1725830

On (09/01/17 10:32), Joe Perches wrote:
[..]
> > +static inlin __printf(2, 3) __cold
> 
> uncompiled
> 
> > +static int __prbuf_write(struct seq_buf *s, const char *fmt, ...)
> 
> inline
> 

thanks.

there is always a missing

	if (console_trylock())
		console_unlock();

in flush() function.

	-ss

[toc] | [prev] | [next] | [standalone]

#1725838

On (09/04/17 13:30), Sergey Senozhatsky wrote:
> On (09/01/17 10:32), Joe Perches wrote:
> [..]
> > > +static inlin __printf(2, 3) __cold
> > 
> > uncompiled
> > 
> > > +static int __prbuf_write(struct seq_buf *s, const char *fmt, ...)
> > 
> > inline
> > 
> 
> thanks.
> 
> there is always a missing

d'oh...  s/always/also/

	-ss

[toc] | [prev] | [next] | [standalone]

#1722642

Hello,

On (08/29/17 10:00), Linus Torvalds wrote:
> On Tue, Aug 29, 2017 at 6:40 AM, Sergey Senozhatsky
> <sergey.senozhatsky.work@gmail.com> wrote:
> > Pavel reported that
> >         printk("foo"); printk("bar");
> >
> > now does not produce a single continuation "foobar" line, but
> > instead produces two lines
> >                 foo
> >                 bar
> 
> And that's the *correct* behavior.

ok. thanks for taking a look.

> Stop trying to fix that. Fix the printk's instead.
> 
> In particular, the
> 
>     printk("bar");
> 
> could have come from an interrupt, and have nothing what-so-ever to do
> with "foo".
> 
> If you want continuations, you
> 
>  (a) make sure the first one doesn't end in a newline
> 
>  (b) make sure the second printk has a KERN_CONT
> 
>  (c) even after that, ask yourself how much you _really_ want
> continuations, because there are going to be situations where it still
> doesn't work.

yes, continuations are not really welcomed. I thought that this
particular case could be considered a regression. but your position
is pretty clear.

> I refuse to help those things. We mis-designed things, and the
> continuations were a mistake to begin with, but they were a mistake
> that was understandable in the timeframe they happened. But it's not
> something we should support, and it's most definitely is not something
> we should then say "oh, you were broken shit that didn't even bother
> to add the KERN_CONT, let me help your crap".
> 
> No.
> 
> Only acceptable use of continuations is basically boot-time testing,
> when you do things like
> 
>      printk("Testing feature XYZ..");
>      this_may_blow_up_because_of_hw_bugs();
>      printk(KERN_CONT " ... ok\n");
>
> and anything else you should seriously try to marshal the data
> *before* doing a printk(), and not expect printk() to marshal it for
> you.

ok. that's something several people asked for -- some sort of buffered
printk mode; but people don't want to use a buffer allocated on the stack
(or kmalloc-ed, etc.) to do sprintf() on it and then feed it to printk("%s"),
because this adds some extra cost:

	void foo(void)
	{
		char cont_string[256];
		size_t sz;

		sz = sprintf(cont_string + sz, "%xxxx", data1...);
		do_abc()
		sz += sprintf(cont_string + sz, "%xxxx", data1...);

		....

		printk("%s\n", cont_string)   // does "sprintf" again
					      // and then memcpy
	}


I thought about re-using printk-safe per-CPU buffers for that purpose.
this saves us memory, because printk-safe buffers are always there, but
it has some disadvantages. namely, to use printk-safe buffer we need to
disable local interrupts. so something like this

	printk_buffered_mode_begin();   // disables local irq

	printk()	// appends data to the per-CPU buffer
	printk()
	printk()

	printk_buffered_mode_end();  // append messages to consequent logbuf
				     // entries
				     // enable local irqs.

... not sure, how usable this will end up to be.
probably not usable at all.

> But for legacy reasons, we do end up trying to support KERN_CONT.
> Just barely.
> 
> I'd really like to get rid of it entirely, because the whole log-based
> structure really really doesn't work well for it (what if somebody has
> already read the partial line from the logs?)
> 
> Our printk stuff didn't used to be log-based. It was just a plain
> character-based circular buffer. Back then that KERN_CONT made a whole
> lot more sense.

	-ss

[toc] | [prev] | [next] | [standalone]

#1722655

On Tue, Aug 29, 2017 at 10:33 AM, Sergey Senozhatsky
<sergey.senozhatsky@gmail.com> wrote:
>
> ok. that's something several people asked for -- some sort of buffered
> printk mode; but people don't want to use a buffer allocated on the stack
> (or kmalloc-ed, etc.) to do sprintf() on it and then feed it to printk("%s"),
> because this adds some extra cost:

I don't like the notion of per-cpu buffers either, because then you
suddenly get atomicity issues, and you really don't want that.

My preference as a user is actually to just have a dynamically
re-sizable buffer (that's pretty much what I've done in *every* single
user space project I've had in the last decade), but because some
users might have atomicity issues I do suspect that we should just use
a stack buffer.

And then perhaps say that the buffer size has to be capped at 80 characters.

Because if you're printing more than 80 characters and expecting it
all to fit on a line, you're doing something else wrong anyway.

And hide it not as a explicit "char buffer[80]]" allocation, but as a
"struct line_buffer" or similar, so that

 (a) people don't get the line size wrong

 (b) the buffering code can add a few fields for length etc in there too

Introduce a few helper functions for it:

 init_line_buffer(&buf);
 print_line(&buf, fmt, args);
 vprint_line(&buf, fmt, vararg);
 finish_line(&buf);

or whatever, and it sounds like it should be pretty easy to use.

                Linus

[toc] | [prev] | [next] | [standalone]

#1722666

On Tue, 2017-08-29 at 10:52 -0700, Linus Torvalds wrote:
> On Tue, Aug 29, 2017 at 10:33 AM, Sergey Senozhatsky
> <sergey.senozhatsky@gmail.com> wrote:
> > 
> > ok. that's something several people asked for -- some sort of buffered
> > printk mode; but people don't want to use a buffer allocated on the stack
> > (or kmalloc-ed, etc.) to do sprintf() on it and then feed it to printk("%s"),
> > because this adds some extra cost:
> 
> I don't like the notion of per-cpu buffers either, because then you
> suddenly get atomicity issues, and you really don't want that.
> 
> My preference as a user is actually to just have a dynamically
> re-sizable buffer (that's pretty much what I've done in *every* single
> user space project I've had in the last decade), but because some
> users might have atomicity issues I do suspect that we should just use
> a stack buffer.
> 
> And then perhaps say that the buffer size has to be capped at 80 characters.
> 
> Because if you're printing more than 80 characters and expecting it
> all to fit on a line, you're doing something else wrong anyway.
> 
> And hide it not as a explicit "char buffer[80]]" allocation, but as a
> "struct line_buffer" or similar, so that
> 
>  (a) people don't get the line size wrong
> 
>  (b) the buffering code can add a few fields for length etc in there too
> 
> Introduce a few helper functions for it:
> 
>  init_line_buffer(&buf);
>  print_line(&buf, fmt, args);
>  vprint_line(&buf, fmt, vararg);
>  finish_line(&buf);
> 
> or whatever, and it sounds like it should be pretty easy to use.

Mostly true and not a new solution.

You'll now need to add &buf to called functions that
continue individual line output.

Tejun Heo suggested the very similar mprintk back in 2008.

http://thread.gmane.org/gmane.linux.ide/27199

[toc] | [prev] | [next] | [standalone]

#1722949

On (08/29/17 11:09), Joe Perches wrote:
[..]
> > Introduce a few helper functions for it:
> > 
> >  init_line_buffer(&buf);
> >  print_line(&buf, fmt, args);
> >  vprint_line(&buf, fmt, vararg);
> >  finish_line(&buf);
> > 
> > or whatever, and it sounds like it should be pretty easy to use.
> 
> Mostly true and not a new solution.
> 
> You'll now need to add &buf to called functions that
> continue individual line output.
> 
> Tejun Heo suggested the very similar mprintk back in 2008.
> 
> http://thread.gmane.org/gmane.linux.ide/27199

interesting. thanks for the link.

	-ss

[toc] | [prev] | [next] | [standalone]

#1722944

Hello,

On (08/29/17 10:52), Linus Torvalds wrote:
> On Tue, Aug 29, 2017 at 10:33 AM, Sergey Senozhatsky
> <sergey.senozhatsky@gmail.com> wrote:
> >
> > ok. that's something several people asked for -- some sort of buffered
> > printk mode; but people don't want to use a buffer allocated on the stack
> > (or kmalloc-ed, etc.) to do sprintf() on it and then feed it to printk("%s"),
> > because this adds some extra cost:
> 
[..]
> Introduce a few helper functions for it:
> 
>  init_line_buffer(&buf);
>  print_line(&buf, fmt, args);
>  vprint_line(&buf, fmt, vararg);
>  finish_line(&buf);
> 
> or whatever, and it sounds like it should be pretty easy to use.

ok, I was short on details (sorry, it was almost 3am).

what I was talking/thinking about is not just a single complete continuation
line, but a whole bunch of printk calls (including continuation lines). like
OOM report with backtraces, and so on. the problem people are having (well,
according to emails I have got in my inbox) is the fact that
	printk("a"); printk("b");
	
can appear in the logbuf (and serial console) pretty far; no one knows what
can happen between those calls. so the buffered-printk buffer is supposed to
be big enough for N lines and, more importantly, it stores those lines in
logbuf in consequent entries.

so the difference here is

	while (buffer->whatever)
		printk("%s\n", buffer->msg[i]);

vs

	spin_lock(&logbuf_lock);
	while (buffer->whatever)
		log_store(buffer->msg[i]);
	spin_unlock(&logbuf_lock);


a dynamic buffer with resizing probably may not work good enough in some
OOM cases.

	-ss

[toc] | [prev] | [next] | [standalone]

#1722608

On Mon, Aug 28, 2017 at 2:05 AM, Pavel Machek <pavel@ucw.cz> wrote:
> Hi!
>
> In 4.13-rc, printk("foo"); printk("bar"); seems to produce
> foo\nbar. That's... quite surprising/unwelcome. What is going on
> there? Are timestamps responsible?

No.

It's actively trying to treach you not to do shit.

If you want to continue a line, you NEED to use KERN_CONT.

That has always been true. It hasn't always been enforced, though.

If you do two printk's and the second one doesn't say "I'm a
continuation", the printk logic assumes you're just confused and
wanted two lines.

And no, we are *NOT* adding code to printk to help people avoid this.
Quite the reverse.

Stop doing continuations at all please. But if you do, you'd better
use KERN_CONT. And if you don't, and you get multiple lines, it's your
own damn fault.

                 Linus

[toc] | [prev] | [next] | [standalone]

#1722623

On Tue, 2017-08-29 at 09:48 -0700, Linus Torvalds wrote:
> On Mon, Aug 28, 2017 at 2:05 AM, Pavel Machek <pavel@ucw.cz> wrote:
> > Hi!
> > 
> > In 4.13-rc, printk("foo"); printk("bar"); seems to produce
> > foo\nbar. That's... quite surprising/unwelcome. What is going on
> > there? Are timestamps responsible?
> 
> No.
> 
> It's actively trying to treach you not to do shit.
> 
> If you want to continue a line, you NEED to use KERN_CONT.
> 
> That has always been true. It hasn't always been enforced, though.

That's simply false.

It was never true until you made it a requirement.
(it's not a bad requirement, but it did change behavior)

It was just unfortunate there were( and still are)
many cases that needed updating.

[toc] | [prev] | [next] | [standalone]

#1722635

On Tue, Aug 29, 2017 at 10:10 AM, Joe Perches <joe@perches.com> wrote:
> That's simply false.
>
> It was never true until you made it a requirement.
> (it's not a bad requirement, but it did change behavior)

Oh, it changed behavior, yes (and for kernel code we do that, and
require people to change).

But even before it was technically required, it was very much supposed
to be there as a marker. KERN_CONT has existed for about a decade.

It was added in commit 474925277671 ("printk: add KERN_CONT
annotation") back in 2007, with a comment that said - at that time:

  /*
   * Annotation for a "continued" line of log printout (only done after a
   * line that had no enclosing \n). Only to be used by core/arch code
   * during early bootup (a continued line is not SMP-safe otherwise).
   */

so basically for the last ten years, it's very much been policy that

 (a) you shouldn't do this except for during early bootiup

 (b) you should have that KERN_CONT marker to show that you're doing it

So this is *not* new.

What is new is the enforcement, because people didn't follow the rules
without it.

So yes, we're enforcing it now, and we're not going back to the
unenforced times, because a decade of shit has shown that people
didn't do it without being forced to.

                  Linus

[toc] | [prev] | [next] | [standalone]

#1722641

On Tue, 2017-08-29 at 10:20 -0700, Linus Torvalds wrote:
> On Tue, Aug 29, 2017 at 10:10 AM, Joe Perches <joe@perches.com> wrote:
> > That's simply false.
> > 
> > It was never true until you made it a requirement.
> > (it's not a bad requirement, but it did change behavior)
> 
> Oh, it changed behavior, yes (and for kernel code we do that, and
> require people to change).
> 
> But even before it was technically required, it was very much supposed
> to be there as a marker. KERN_CONT has existed for about a decade.

Which is very much not "forever" in kernel terms.

> It was added in commit 474925277671 ("printk: add KERN_CONT
> annotation") back in 2007, with a comment that said - at that time:

Yeah, I remember things too.

>   /*
>    * Annotation for a "continued" line of log printout (only done after a
>    * line that had no enclosing \n). Only to be used by core/arch code
>    * during early bootup (a continued line is not SMP-safe otherwise).
>    */

And note the "core/arch code during bootup" bit.

Look, it's not fundamentally a "bad" requirement.
It was just not "always required".

And silently slipping in the change because you
were unhappy with adding newlines to some printks
was, at best, poor form.

Your change broke a bunch of output.

[toc] | [prev] | [next] | [standalone]

#1722643

On Tue, Aug 29, 2017 at 10:33 AM, Joe Perches <joe@perches.com> wrote:
>
> Your change broke a bunch of output.

Tough. We've done that before to force people to fix their code.

I'm actually upset that EVEN NOW (and it's been, what, 18 months),
people ask for the old broken shit behavior back.

It's ten years since we introduced the marker, and it's been over a
year since I made that pretty much a requirement, and people still
want to do the broken crap.

I'm not AT ALL feeling sorry for people. Fix your shit, or see ugly
output. Those are the two choices.

          Linus

[toc] | [prev] | [next] | [standalone]

#1722648

On Tue, 2017-08-29 at 10:36 -0700, Linus Torvalds wrote:
> On Tue, Aug 29, 2017 at 10:33 AM, Joe Perches <joe@perches.com> wrote:
> > 
> > Your change broke a bunch of output.
> 
> Tough. We've done that before to force people to fix their code.

No worries.
I don't mind the change at all really.

You do seem to like enhancing your reputation against
"plays well with others" kindergarten grading.

> I'm actually upset that EVEN NOW (and it's been, what, 18 months),

Odd maths.
October 2016 to August 2017 is barely half that.

> people ask for the old broken shit behavior back.

You seem to overestimate how often people test their
code against current kernels.

And look for documentation that shows this as a
requirement.

Other than your commit log entry and some LKML chatter
I believe that you'll have a hard time finding any.

$ git grep -i KERN_CONT Documentation/
$ git grep -i pr_cont Documentation/
$

[toc] | [prev] | [next] | [standalone]

#1722826

[Multipart message — attachments visible in raw view] — view raw

Hi!

> > In 4.13-rc, printk("foo"); printk("bar"); seems to produce
> > foo\nbar. That's... quite surprising/unwelcome. What is going on
> > there? Are timestamps responsible?
> 
> No.
> 
> It's actively trying to treach you not to do shit.
> 
> If you want to continue a line, you NEED to use KERN_CONT.
> 
> That has always been true. It hasn't always been enforced, though.

Dumping hex buffer for debugging should not be a rocket science. You
are welcome not add checkpatch rules to prevent such code from being
merged...

> Stop doing continuations at all please. But if you do, you'd better
> use KERN_CONT. And if you don't, and you get multiple lines, it's your
> own damn fault.

..but please don't make debugging harder than it already is. Just
because you spend too much time doing kernel does not mean that
everyone is; having to remember "this is kernel, so it has to be
special, you have to do printk, not printf" is bad enough, having
different semantics is even more ugly.

Thanks,

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[toc] | [prev] | [next] | [standalone]

#1724733

Hi,

On (08/29/17 22:24), Pavel Machek wrote:
> > > In 4.13-rc, printk("foo"); printk("bar"); seems to produce
> > > foo\nbar. That's... quite surprising/unwelcome. What is going on
> > > there? Are timestamps responsible?
> > 
> > No.
> > 
> > It's actively trying to treach you not to do shit.
> > 
> > If you want to continue a line, you NEED to use KERN_CONT.
> > 
> > That has always been true. It hasn't always been enforced, though.
> 
> Dumping hex buffer for debugging should not be a rocket science. You
> are welcome not add checkpatch rules to prevent such code from being
> merged...

well... just a note, I personally developed a new habit - use
pr_err/pr_cont/etc macros instead of explicit printk(KERN_FOO "...").
may be this can work for you. and we _probably_ need to advertise
pr_foo() more.

	-ss

[toc] | [prev] | [next] | [standalone]

#1724737

On Fri, 2017-09-01 at 10:40 +0900, Sergey Senozhatsky wrote:
> On (08/29/17 22:24), Pavel Machek wrote:
> > > > In 4.13-rc, printk("foo"); printk("bar"); seems to produce
> > > > foo\nbar. That's... quite surprising/unwelcome. What is going on
> > > > there? Are timestamps responsible?
[]
> > You are welcome not add checkpatch rules to prevent such code from being
> > merged...

Pavel, what does this mean?

> well... just a note, I personally developed a new habit - use
> pr_err/pr_cont/etc macros instead of explicit printk(KERN_FOO "...").
> may be this can work for you. and we _probably_ need to advertise
> pr_foo() more.

As well as convert the macros to functions
to save some .text too.

[toc] | [prev] | [next] | [standalone]

#1724818

[Multipart message — attachments visible in raw view] — view raw

On Thu 2017-08-31 19:04:24, Joe Perches wrote:
> On Fri, 2017-09-01 at 10:40 +0900, Sergey Senozhatsky wrote:
> > On (08/29/17 22:24), Pavel Machek wrote:
> > > > > In 4.13-rc, printk("foo"); printk("bar"); seems to produce
> > > > > foo\nbar. That's... quite surprising/unwelcome. What is going on
> > > > > there? Are timestamps responsible?
> []
> > > You are welcome not add checkpatch rules to prevent such code from being
> > > merged...
> 
> Pavel, what does this mean?

That should have been "welcome to".

> > well... just a note, I personally developed a new habit - use
> > pr_err/pr_cont/etc macros instead of explicit printk(KERN_FOO "...").
> > may be this can work for you. and we _probably_ need to advertise
> > pr_foo() more.
> 
> As well as convert the macros to functions
> to save some .text too.

IMO pr_foo() is bad interface for debugging. I don't care about
loglevels at that point, I just want to see the data... and difference
from userspace debugging actually hurts there.

Yes, I could train my fingers to just do pr_cont(), always, but
training fingers is hard.

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[toc] | [prev] | [next] | [standalone]

#1724830

On Fri, 2017-09-01 at 08:59 +0200, Pavel Machek wrote:
> On Thu 2017-08-31 19:04:24, Joe Perches wrote:
> > On Fri, 2017-09-01 at 10:40 +0900, Sergey Senozhatsky wrote:
> > > On (08/29/17 22:24), Pavel Machek wrote:
> > > > > > In 4.13-rc, printk("foo"); printk("bar"); seems to produce
> > > > > > foo\nbar. That's... quite surprising/unwelcome. What is going on
> > > > > > there? Are timestamps responsible?
> > []
> > > > You are welcome not add checkpatch rules to prevent such code from being
> > > > merged...
> > 
> > Pavel, what does this mean?
> That should have been "welcome to".

Right.

Good luck with a checkpatch implementation.

> IMO pr_foo() is bad interface for debugging.

Why?

> I just want to see the data... and difference
> from userspace debugging actually hurts there.

How so?  What data is not available?

Making functions of the various pr_<level> uses
makes it easier to insert things like singletons
for any pr_fmt prefix which could save a few KB
and as well allow for centralized mechanisms to
emit logging messages with
	%ps, __builtin_return_address(0)
instead of using
	"%s <fmt>", __func__, args...
to save even more space.

[toc] | [prev] | [next] | [standalone]

#1724831

[Multipart message — attachments visible in raw view] — view raw

On Fri 2017-09-01 10:40:12, Sergey Senozhatsky wrote:
> Hi,
> 
> On (08/29/17 22:24), Pavel Machek wrote:
> > > > In 4.13-rc, printk("foo"); printk("bar"); seems to produce
> > > > foo\nbar. That's... quite surprising/unwelcome. What is going on
> > > > there? Are timestamps responsible?
> > > 
> > > No.
> > > 
> > > It's actively trying to treach you not to do shit.
> > > 
> > > If you want to continue a line, you NEED to use KERN_CONT.
> > > 
> > > That has always been true. It hasn't always been enforced, though.
> > 
> > Dumping hex buffer for debugging should not be a rocket science. You
> > are welcome not add checkpatch rules to prevent such code from being
> > merged...
> 
> well... just a note, I personally developed a new habit - use
> pr_err/pr_cont/etc macros instead of explicit printk(KERN_FOO "...").
> may be this can work for you. and we _probably_ need to advertise
> pr_foo() more.

Well, usually dev_info (and friends) is right thing to use for
production. But very little debugging remains after the
.. well.. debugging phase, so something that behaves similar to
printf() is nice.

Actually, I believe we should just create printf() in kernel. Its the
mistake I do all the time.

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[toc] | [prev] | [next] | [standalone]

#1724983

On Fri, 1 Sep 2017 09:29:06 +0200
Pavel Machek <pavel@ucw.cz> wrote:


> Well, usually dev_info (and friends) is right thing to use for
> production. But very little debugging remains after the
> .. well.. debugging phase, so something that behaves similar to
> printf() is nice.

Try using trace_printk(). Who uses printk() to debug anymore ;-)

> 
> Actually, I believe we should just create printf() in kernel. Its the
> mistake I do all the time.

It's a way to tell you how much user vs kernel programming you do. When
you type printk() in user space, you know you've been doing more kernel
programming. When you type printf() in kernel space, you've been doing
more user space programming.

-- Steve

[toc] | [prev] | [standalone]

Page 3 of 3 — ← Prev page 1 2 [3]

Back to top | Article view | linux.kernel

csiph-web