Re: [PATCH 8/8] printk: Add config option for disabling printk offloading

[Jan Kara]

On Wed 23-04-14 11:17:50, Andrew Morton wrote:
> On Wed, 23 Apr 2014 13:08:47 +0200 Jan Kara <jack@xxxxxxx> wrote:
> 
> > > If you want reliable crash logging then we need to be able to set a
> > > printk level mask per console and just set the serial console for
> > > "crit/err" and the queue console for the rest, with a 'cat
> > > >/dev/ttywhatever' running if this feature was in use ?
> >   Ok, now I understand. Thanks for an interesting idea. IMO people
> > definitely need messages logged directly into serial console when e.g. oops
> > is happening because very likely they won't get logged to disk and even
> > userspace won't have a chance to run and copy messages to the serial
> > console. Plus for useful softlockup reports or oops messages you need also
> > the KERN_NOTICE and KERN_INFO messages - stack traces, cpu numbers, process
> > information - all this is printed with these levels.
> > 
> > These obvious places could be changed to print with lower log level I
> > assume but still I'm somewhat worried that some KERN_INFO messages that
> > would be useful for debugging a crash won't make it to console before the
> > crash happens.
> > 
> > But if both you and Andrew think that the above problems are smaller than
> > the complexity connected with printk offloading, I can give it a try.
> > Andrew?
> 
> I'm curious about the idea of writing a new(?) console driver which the
> problematic machines can use.
> 
> The problem of course will be in sizing the driver's queue.  Perhaps we
> can have a driver which uses a huge queue, temporarily use that driver
> during boot then switch over to a conventional console driver?
  I was for some time thinking about this and I have some questions:
1) How is this better than just stopping printing from kernel log buffer
   early (before we write everything)? It makes no difference whether the
   message sits in kernel log buffer or driver's buffer, does it?
2) Serial drivers usually write like:
   for each char
     poll until port ready
     write char

   Hooking up something like this to a buffering layer seems as a
non-trivial task. After all some CPU still has to do the polling and
printing all those driver buffers so we have just moved the problem from
console_unlock() to some drivers / another buffering layer.

  So does this approach really bring any advantage?

								Honza

-- 
Jan Kara <jack@xxxxxxx>
SUSE Labs, CR
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/