On Fri, 17 Apr 2015 13:17:12 -0400 (EDT)
David Miller wrote:
> From: Tejun Heo
> 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
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 th
From: Of Rob Landley
> Sent: 19 April 2015 08:25
> On Thu, Apr 16, 2015 at 6:03 PM, Tejun Heo 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 th
On Thu, Apr 16, 2015 at 6:03 PM, Tejun Heo 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 were lost an
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
From: Tejun Heo
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 refacto
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
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 exten
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
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("netconsol
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 whethe
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 a
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 log
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?
>
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
> drive
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
From: Tejun Heo
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 excessively
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 whe
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
>
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 were lost and/or reordered in flight.
printk already keeps log metadat
20 matches
Mail list logo
