On Fri, 17 Apr 2015 13:17:12 -0400 (EDT)
David Miller da...@davemloft.net wrote:
From: Tejun Heo t...@kernel.org
Date: Fri, 17 Apr 2015 12:28:26 -0400
On Sat, Apr 18, 2015 at 12:35:06AM +0900, Tetsuo Handa wrote:
If the sender side can wait for retransmission, why can't we use
userspace
From: Of Rob Landley
Sent: 19 April 2015 08:25
On Thu, Apr 16, 2015 at 6:03 PM, Tejun Heo t...@kernel.org wrote:
In a lot of configurations, netconsole is a useful way to collect
system logs; however, all netconsole does is simply emitting UDP
packets for the raw messages and there's no
Hello, Rob.
On Sun, Apr 19, 2015 at 02:25:09AM -0500, Rob Landley wrote:
If you have two machines plugged into a hub, and that's _all_ that's
plugged in, packets should never get dropped. This was the original
use case of netconsole was that the sender and the receiver were
plugged into the
On Thu, Apr 16, 2015 at 6:03 PM, Tejun Heo t...@kernel.org wrote:
In a lot of configurations, netconsole is a useful way to collect
system logs; however, all netconsole does is simply emitting UDP
packets for the raw messages and there's no way for the receiver to
find out whether the packets
Tejun Heo wrote:
If we can assume that scheduler is working, adding a kernel thread that
does
while (1) {
read messages with metadata from /dev/kmsg
send them using UDP network
}
might be easier than modifying netconsole module.
But, I mean, if we are gonna
Tejun Heo wrote:
On Sat, Apr 18, 2015 at 03:03:46AM +0900, Tetsuo Handa wrote:
packet will be sufficient for finding out whether the packets were lost
and/or
reordered in flight.
printk(Hello);
= netconsole sends Hello using UDP
printk(netconsole);
=
Hello,
On Sat, Apr 18, 2015 at 03:20:41AM +0900, Tetsuo Handa wrote:
I didn't mean to introduce netconsole's own version of metadata.
I meant we don't need to implement in-kernel retry logic.
Hmmm? I'm not really following where this discussion is headed. No,
we don't have to put it in the
Just a bit of addition.
On Fri, Apr 17, 2015 at 01:37:54PM -0400, Tejun Heo wrote:
Upto patch 12, it's just the same mechanism transferring extended
messages. It doesn't add any smartness to netconsole per-se except
that it can now emit messages with metadata headers. What do you
think
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
Tejun Heo wrote:
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
On Sat, Apr 18, 2015 at 03:03:46AM +0900, Tetsuo Handa wrote:
If you tolerate loss of kernel messages, adding sequence number to each UDP
Well, there's a difference between accepting loss when log buffer
overflows and when any packets get lost.
packet will be sufficient for finding out whether
From: Tejun Heo t...@kernel.org
Date: Fri, 17 Apr 2015 12:28:26 -0400
On Sat, Apr 18, 2015 at 12:35:06AM +0900, Tetsuo Handa wrote:
If the sender side can wait for retransmission, why can't we use
userspace programs (e.g. rsyslogd)?
Because the system may be oopsing, ooming or threshing
On Sat, Apr 18, 2015 at 02:43:30AM +0900, Tetsuo Handa wrote:
Upto patch 12, it's just the same mechanism transferring extended
messages. It doesn't add any smartness to netconsole per-se except
that it can now emit messages with metadata headers. What do you
think about them?
So,
Tejun Heo wrote:
printk() cannot wait for ack. Trying to wait for ack would break something.
How can you transmit subsequent kernel messages which failed to enqueue
due to waiting for ack for previous kernel messages?
Well, if log buffer overflows and the messages aren't at the logging
Tejun Heo wrote:
* Implement netconsole retransmission support. Matching rx socket on
the source port is automatically created for extended targets and
the log receiver can request retransmission by sending reponse
packets. This is completely decoupled from the main write path and
Hello,
On Sat, Apr 18, 2015 at 12:35:06AM +0900, Tetsuo Handa wrote:
If the sender side can wait for retransmission, why can't we use
userspace programs (e.g. rsyslogd)?
Because the system may be oopsing, ooming or threshing excessively
rendering the userland inoperable and that's exactly when
From: Tejun Heo t...@kernel.org
Date: Fri, 17 Apr 2015 15:52:38 -0400
Hello,
On Fri, Apr 17, 2015 at 02:55:37PM -0400, David Miller wrote:
* 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
From: Tejun Heo t...@kernel.org
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
Hello,
On Fri, Apr 17, 2015 at 02:55:37PM -0400, David Miller wrote:
* 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,
19 matches
Mail list logo
