[lkml]   [2015]   [Apr]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCHSET] printk, netconsole: implement reliable netconsole
From: Tejun Heo <>
Date: Fri, 17 Apr 2015 13:37:54 -0400

> Hello, David.
> On Fri, Apr 17, 2015 at 01:17:12PM -0400, David Miller wrote:
>> If userland cannot run properly, it is almost certain that neither will
>> your complex reliability layer logic.
> * The bulk of patches are to pipe extended log messages to console
> drivers and let netconsole relay them to the receiver (and quite a
> bit of refactoring in the process), which, regardless of the
> reliability logic, is beneficial as we're currently losing
> structured logging (dictionary) and other metadata over consoles and
> regardless of where the reliability logic is implemented, it's a lot
> easier to have messages IDs.

I do not argue against cleanups and good restructuring of the existing
code. But you have decided to mix that up with something that is not
exactly non-controversial.

You'd do well to seperate the cleanups from the fundamental changes,
so they can be handled separately.

> * The only thing necessary for reliable transmission are timer and
> netpoll. There sure are cases where they go down too but there's a
> pretty big gap between those two going down and userland getting
> hosed, but where to put the retransmission and reliability logic
> definitely is debatable.

I fundamentally disagree, exactly on this point.

If you take an OOPS in a software interrupt handler (basically, all of
the networking receive paths and part of the transmit paths, for
example) you're not going to be taking timer interrupts.

And that's the value of netconsole, the chance (albeit not %100) of
getting messages in those scenerios.

 \ /
  Last update: 2015-04-17 21:21    [W:0.084 / U:5.248 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site