patch for common networking error messages

patch for common networking error messages

Post by Janice M Girouar » Tue, 17 Jun 2003 22:40:13



Below is a patch that demonstrates standard messages for ethernet device
drivers.  I would like your feedback on the concept of standard network
messages, and any suggestions for messages to include.  

The intent of the standard message change is to:
1) Ensure key events are communicated to user space in a predictable
way, enabling automated diagnostic systems or error log analysis,
2) Reduce the number of puzzling messages that are logged -- in this
case, by replacing them with standard messages, and/or
3) Identify the device (or driver name) that is responsible for the error.

The patch includes changes for two drivers, the e1000 and tg3, to
provide a concrete example of the concept.  Below is a snapshot of an
error log, with the new messages:

Jun  4 14:54:06 dyn95394175 kernel: e1000: Intel(R) PRO/1000 Network
Driver - version 5.0.43-k3
Jun  4 14:54:06 dyn95394175 kernel:        Copyright (c) 1999-2003 Intel
Corporation.
Jun  4 14:54:06 dyn95394175 kernel: eth2: Intel(R) PRO/1000 Network
Connection
Jun  4 14:54:06 dyn95394175 kernel: eth2: scatter/gather I/O enabled
Jun  4 14:54:06 dyn95394175 kernel: eth2: all IP checksums on transmit
enabled
Jun  4 14:54:06 dyn95394175 kernel: eth3: Intel(R) PRO/1000 Network
Connection
Jun  4 14:54:06 dyn95394175 kernel: eth3: scatter/gather I/O enabled
Jun  4 14:54:06 dyn95394175 kernel: eth3: all IP checksums on transmit
enabled
...
Jun  4 14:54:06 dyn95394175 kernel: tg3: Broadcom Tigon3 ethernet driver
- version 1.5
...

Below is the text for the most basic standard messages:

EMSG_NET_LINK_FAIL   "%s: transient problem: link error detected - MII
status %x\n"
EMSG_NET_LINK_UP     "%s: state change: link up, %d Mbps, %s-duplex\n"
EMSG_NET_HUNG        "%s: software failure: ethernet controller hung\n"
EMSG_NET_RX_ERR      "%s: transient problem: packet receive error,
rx_errors = %ld\n"
EMSG_NET_TX_ERR      "%s: transient problem: packet transmit error,
tx_errors = %ld\n"
EMSG_NET_START_QUEUE "%s: performance event: (re)starting netdev queue\n"
EMSG_NET_STOP_QUEUE  "%s: performance event: stopping netdev queue\n"
EMSG_NET_SGATHER     "%s: scatter/gather I/O enabled\n"
EMSG_NET_NO_SGATHER  "%s: performance event: scatter/gather I/O
disabled\n"  
EMSG_NET_HW_CSUMS    "%s: all IP checksums on transmit enabled\n"  
EMSG_NET_CSUMS       "%s: TCP/UDP over IPv6 checksums on transmit
enabled\n"  
EMSG_NET_NO_CSUMS    "%s: performance event: IP checksums on transmit
disabled\n"

Janice Girouard
jani...@us.ibm.com
===================================================

diff -Naur linux-2.5.69.orig/drivers/net/e1000/e1000_hw.c
linux-2.5.69.newMsgs/drivers/net/e1000/e1000_hw.c
--- linux-2.5.69.orig/drivers/net/e1000/e1000_hw.c    2003-06-04
13:24:46.000000000 -0500
+++ linux-2.5.69.newMsgs/drivers/net/e1000/e1000_hw.c    2003-06-04
13:14:58.000000000 -0500
@@ -31,6 +31,7 @@
  */

 #include "e1000_hw.h"
+#include <linux/stdmsgs.h>

 static int32_t e1000_set_phy_type(struct e1000_hw *hw);
 static void e1000_phy_init_script(struct e1000_hw *hw);
@@ -468,7 +469,7 @@
      * be initialized based on a value in the EEPROM.
      */
     if(e1000_read_eeprom(hw, EEPROM_INIT_CONTROL2_REG, 1, &eeprom_data)
< 0) {
-        DEBUGOUT("EEPROM Read Error\n");
+        DEBUGOUT1(EMSG_DEV_EEPROM_READ, hw->back->adapter->netdev->name);
         return -E1000_ERR_EEPROM;
     }

@@ -666,7 +667,11 @@
             hw->autoneg_failed = 1;
             ret_val = e1000_check_for_link(hw);
             if(ret_val < 0) {
+        uint16_t mii_status_reg;
                 DEBUGOUT("Error while checking for link\n");
+                e1000_read_phy_reg( hw, PHY_STATUS, &mii_status_reg);
+            DEBUGOUT1(EMSG_NET_LINK_FAIL, hw->back->adapter->netdev->name,
+                mii_status_reg);
                 return ret_val;
             }
             hw->autoneg_failed = 0;
@@ -730,7 +735,7 @@
         msec_delay(15);

         if(e1000_write_phy_reg(hw, IGP01E1000_PHY_PAGE_SELECT, 0x0000)
< 0) {
-            DEBUGOUT("PHY Write Error\n");
+               DEBUGOUT1(EMSG_DEV_PHY_WRITE,
hw->back->adapter->netdev->name);
             return -E1000_ERR_PHY;
         }

@@ -746,29 +751,29 @@
             /* Disable SmartSpeed */
             if(e1000_read_phy_reg(hw, IGP01E1000_PHY_PORT_CONFIG,
                                   &phy_data) < 0) {
-                DEBUGOUT("PHY Read Error\n");
+            DEBUGOUT1(EMSG_DEV_PHY_READ, hw->back->adapter->netdev->name);
                 return -E1000_ERR_PHY;
             }
             phy_data &= ~IGP01E1000_PSCFR_SMART_SPEED;
             if(e1000_write_phy_reg(hw, IGP01E1000_PHY_PORT_CONFIG,
                                    phy_data) < 0) {
-                DEBUGOUT("PHY Write Error\n");
+                   DEBUGOUT1(EMSG_DEV_PHY_WRITE,
hw->back->adapter->netdev->name);
                 return -E1000_ERR_PHY;
             }
             /* Set auto Master/Slave resolution process */
             if(e1000_read_phy_reg(hw, PHY_1000T_CTRL, &phy_data) < 0) {
-                DEBUGOUT("PHY Read Error\n");
+            DEBUGOUT1(EMSG_DEV_PHY_READ, hw->back->adapter->netdev->name);
                 return -E1000_ERR_PHY;
             }
             phy_data &= ~CR_1000T_MS_ENABLE;
             if(e1000_write_phy_reg(hw, PHY_1000T_CTRL, phy_data) < 0) {
-                DEBUGOUT("PHY Write Error\n");
+                   DEBUGOUT1(EMSG_DEV_PHY_WRITE,
hw->back->adapter->netdev->name);
                 return -E1000_ERR_PHY;
             }
         }

         if(e1000_read_phy_reg(hw, IGP01E1000_PHY_PORT_CTRL, &phy_data)
< 0) {
-            DEBUGOUT("PHY Read Error\n");
+               DEBUGOUT1(EMSG_DEV_PHY_READ,
hw->back->adapter->netdev->name);
             return -E1000_ERR_PHY;
         }

@@ -779,14 +784,14 @@
         hw->mdix = 1;

         if(e1000_write_phy_reg(hw, IGP01E1000_PHY_PORT_CTRL, phy_data)
< 0) {
-            DEBUGOUT("PHY Write Error\n");
+               DEBUGOUT1(EMSG_DEV_PHY_WRITE,
hw->back->adapter->netdev->name);
             return -E1000_ERR_PHY;
         }

     } else {
         /* Enable CRS on TX. This must be set for half-duplex operation. */
         if(e1000_read_phy_reg(hw, M88E1000_PHY_SPEC_CTRL, &phy_data) < 0) {
-            DEBUGOUT("PHY Read Error\n");
+            DEBUGOUT1(EMSG_DEV_PHY_READ, hw->back->adapter->netdev->name);
             return -E1000_ERR_PHY;
         }
         phy_data |= M88E1000_PSCR_ASSERT_CRS_ON_TX;
@@ -826,7 +831,7 @@
         if(hw->disable_polarity_correction == 1)
             phy_data |= M88E1000_PSCR_POLARITY_REVERSAL;
         if(e1000_write_phy_reg(hw, M88E1000_PHY_SPEC_CTRL, phy_data) < 0) {
-            DEBUGOUT("PHY Write Error\n");
+               DEBUGOUT1(EMSG_DEV_PHY_WRITE,
hw->back->adapter->netdev->name);
             return -E1000_ERR_PHY;
         }

@@ -834,7 +839,7 @@
          * to 25MHz clock.
          */
         if(e1000_read_phy_reg(hw, M88E1000_EXT_PHY_SPEC_CTRL,
&phy_data) < 0) {
-            DEBUGOUT("PHY Read Error\n");
+            DEBUGOUT1(EMSG_DEV_PHY_READ, hw->back->adapter->netdev->name);
             return -E1000_ERR_PHY;
         }
         phy_data |= M88E1000_EPSCR_TX_CLK_25;
@@ -847,7 +852,7 @@
                          M88E1000_EPSCR_SLAVE_DOWNSHIFT_1X);
             if(e1000_write_phy_reg(hw, M88E1000_EXT_PHY_SPEC_CTRL,
                                    phy_data) < 0) {
-                DEBUGOUT("PHY Write Error\n");
+                   DEBUGOUT1(EMSG_DEV_PHY_WRITE,
hw->back->adapter->netdev->name);
                 return -E1000_ERR_PHY;
             }
         }
@@ -855,7 +860,7 @@
         /* SW Reset the PHY so all changes take effect */
         ret_val = e1000_phy_reset(hw);
         if(ret_val < 0) {
-            DEBUGOUT("Error Resetting the PHY\n");
+            DEBUGOUT1(EMSG_DEV_SW_RESET, hw->back->adapter->netdev->name);
             return ret_val;
         }
     }
@@ -899,12 +904,12 @@
          * the Auto Neg Restart bit in the PHY control register.
          */
         if(e1000_read_phy_reg(hw, PHY_CTRL, &phy_data) < 0) {
-            DEBUGOUT("PHY Read Error\n");
+            DEBUGOUT1(EMSG_DEV_PHY_READ, hw->back->adapter->netdev->name);
             return -E1000_ERR_PHY;
         }
         phy_data |= (MII_CR_AUTO_NEG_EN | MII_CR_RESTART_AUTO_NEG);
         if(e1000_write_phy_reg(hw, PHY_CTRL, phy_data) < 0) {
-            DEBUGOUT("PHY Write Error\n");
+               DEBUGOUT1(EMSG_DEV_PHY_WRITE,
hw->back->adapter->netdev->name);
             return -E1000_ERR_PHY;
         }

@@ -933,11 +938,11 @@
      */
     for(i = 0; i < 10; i++) {
         if(e1000_read_phy_reg(hw, PHY_STATUS, &phy_data) < 0) {
-            DEBUGOUT("PHY Read Error\n");
+            DEBUGOUT1(EMSG_DEV_PHY_READ, hw->back->adapter->netdev->name);
             return -E1000_ERR_PHY;
         }
         if(e1000_read_phy_reg(hw, PHY_STATUS, &phy_data) < 0) {
-            DEBUGOUT("PHY Read Error\n");
+            DEBUGOUT1(EMSG_DEV_PHY_READ, hw->back->adapter->netdev->name);
             return -E1000_ERR_PHY;
         }
         if(phy_data & MII_SR_LINK_STATUS) {
@@ -988,13 +993,13 @@

     /* Read the MII Auto-Neg Advertisement Register (Address 4). */
     if(e1000_read_phy_reg(hw, PHY_AUTONEG_ADV, &mii_autoneg_adv_reg) < 0) {
-        DEBUGOUT("PHY Read Error\n");
+        DEBUGOUT1(EMSG_DEV_PHY_READ, hw->back->adapter->netdev->name);
         return -E1000_ERR_PHY;
     }

     /* Read the MII 1000Base-T Control Register (Address 9). */
     if(e1000_read_phy_reg(hw, PHY_1000T_CTRL, &mii_1000t_ctrl_reg) < 0) {
-        DEBUGOUT("PHY Read Error\n");
+        DEBUGOUT1(EMSG_DEV_PHY_READ, hw->back->adapter->netdev->name);
         return -E1000_ERR_PHY;
     }

@@ -1103,14 +1108,14 @@
     }

     if(e1000_write_phy_reg(hw, PHY_AUTONEG_ADV, mii_autoneg_adv_reg) < 0) {
-        DEBUGOUT("PHY Write Error\n");
+           DEBUGOUT1(EMSG_DEV_PHY_WRITE, hw->back->adapter->netdev->name);
         return
...

read more »

 
 
 

patch for common networking error messages

Post by David S. Mille » Tue, 17 Jun 2003 22:50:13



   Date: Mon, 16 Jun 2003 15:30:22 -0500

   EMSG_NET_LINK_UP     "%s: state change: link up, %d Mbps, %s-duplex\n"

Should indicate flow control state too.

   EMSG_NET_START_QUEUE "%s: performance event: (re)starting netdev queue\n"
   EMSG_NET_STOP_QUEUE  "%s: performance event: stopping netdev queue\n"

Oh _ABSOLUTELY NOT_, you're not printing a message
for normal events like this.  Especially those that are
going to occur on highly loaded systems.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

patch for common networking error messages

Post by Andi Klee » Tue, 17 Jun 2003 23:00:17




>    Date: Mon, 16 Jun 2003 15:30:22 -0500

>    EMSG_NET_LINK_UP     "%s: state change: link up, %d Mbps, %s-duplex\n"

> Should indicate flow control state too.

It would be actually useful  to wrap these in real functions.

Why? It will make supporting netconsole easier which has to be careful
to never recurse in the network driver.

-Andi

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

patch for common networking error messages

Post by David S. Mille » Tue, 17 Jun 2003 23:00:24



   Date: Mon, 16 Jun 2003 22:53:42 +0200

   Why? It will make supporting netconsole easier which has to be careful
   to never recurse in the network driver.

printk can check this
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

patch for common networking error messages

Post by Janice M Girouar » Tue, 17 Jun 2003 23:10:12


I agree that it's not desirable to introduce a bunch of messages that we
aren't already logging.  I didn't show the netif_msg prefix because I
was trying to focus the patch on the common messages, but you would
normally proceed a message with:

if netif_msg_link()
   printk("some text to indicate the link is up/down")

The netif_msg_link test would normally filter out what messages should
be logged.

Or, just leave out the message call.  I added one or two messages to the
tg3 and e1000 drivers  to demonstrate where you might use these common
messages... just to show that various drivers could use the text.
 Actually using the specific message would be completely up to the
developer.

Jaince



>   Date: Mon, 16 Jun 2003 15:30:22 -0500

>   EMSG_NET_LINK_UP     "%s: state change: link up, %d Mbps, %s-duplex\n"

>Should indicate flow control state too.

>   EMSG_NET_START_QUEUE "%s: performance event: (re)starting netdev queue\n"
>   EMSG_NET_STOP_QUEUE  "%s: performance event: stopping netdev queue\n"

>Oh _ABSOLUTELY NOT_, you're not printing a message
>for normal events like this.  Especially those that are
>going to occur on highly loaded systems.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
 
 
 

patch for common networking error messages

Post by Nivedita Singhv » Wed, 18 Jun 2003 00:20:12



> Below is a patch that demonstrates standard messages for ethernet device
> drivers.  I would like your feedback on the concept of standard network
> messages, and any suggestions for messages to include.

Very useful!  I'd like to see a short note on this in Documentation/
networking..Or perhaps if there is already a RAS best practices
kind of doc or something, add to that? (sorry, havent checked)
But it would be handy for people who wanted to contribute
patches for other drivers.

Essentially, things like some guidelines on classifying some
of those messages, when creating new messages. eg when is
something a state change and when is it a performance event?
I notice some slight ambiguity in your defs..(sorry, very
minor nitpick :)).

I'd certainly like to see messages from the driver when the
card enters/leaves promiscuous mode, as an example of things
we'd like to add...

thanks,
Nivedita

Quote:> The intent of the standard message change is to:
> 1) Ensure key events are communicated to user space in a predictable
> way, enabling automated diagnostic systems or error log analysis,
> 2) Reduce the number of puzzling messages that are logged -- in this
> case, by replacing them with standard messages, and/or
> 3) Identify the device (or driver name) that is responsible for the error.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
 
 
 

patch for common networking error messages

Post by David S. Mille » Wed, 18 Jun 2003 00:30:08



   Date: Mon, 16 Jun 2003 15:13:05 -0700

   I'd certainly like to see messages from the driver when the
   card enters/leaves promiscuous mode,

egrep "promiscuous mode" net/core/dev.c | grep printk
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

patch for common networking error messages

Post by Andrew Morto » Wed, 18 Jun 2003 00:30:19




>    Date: Mon, 16 Jun 2003 22:53:42 +0200

>    Why? It will make supporting netconsole easier which has to be careful
>    to never recurse in the network driver.

> printk can check this

Actually it already does, to cover the case where an interrupt handler calls
printk while process-context code is performing a printk.

The nested printk will squirt the message into the log buffer and the
"outer" code will display it.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

patch for common networking error messages

Post by Janice Girouar » Wed, 18 Jun 2003 00:40:06



   Date : 06/16/2003 05:13 PM

   egrep "promiscuous mode" net/core/dev.c | grep printk

I noticed when I performed the grep, the printk shows:
      printk(KERN_INFO "device %s %s promiscuous mode\n"

For the sake of consistency and automatic error log analysis, it might be
nice to standardize on a message closer to:
      printk(KERN_INFO "%s: %s promiscuous mode\n"

It's somewhat common, but not universal to start the error message with the
device name followed by a colon.

Janice

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

patch for common networking error messages

Post by David S. Mille » Wed, 18 Jun 2003 00:40:07



   Date: Mon, 16 Jun 2003 17:29:15 -0500

   For the sake of consistency and automatic error log analysis, it might be

And all the scripts checking for the existing messages
in log files?  Screw them, right?

This whole idea is starting to leave a very bad taste in
my mouth...
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

patch for common networking error messages

Post by Nivedita Singhv » Wed, 18 Jun 2003 00:50:09




>    Date: Mon, 16 Jun 2003 17:29:15 -0500

>    For the sake of consistency and automatic error log analysis, it might be

> And all the scripts checking for the existing messages
> in log files?  Screw them, right?

Are you saying we never get to change any current
log messages ever again on accnt of the scripts that are
monitoring for those precise words? Hope not :)

I'd agree a lot of thought (and agreement :))has to go
into this before changing minor nits and stuff, and not
causing too much disruption..Evolution, as opposed to
revolution ;).  I would hope that most wouldnt need changing..

thanks,
Nivedita

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

patch for common networking error messages

Post by Jeff Garzi » Wed, 18 Jun 2003 01:00:06



> I agree that it's not desirable to introduce a bunch of messages that we
> aren't already logging.  I didn't show the netif_msg prefix because I
> was trying to focus the patch on the common messages, but you would
> normally proceed a message with:

> if netif_msg_link()
>   printk("some text to indicate the link is up/down")

> The netif_msg_link test would normally filter out what messages should
> be logged.

There are several issues at play here.

1) In general, I think you're approaching the logging from the wrong
angle.  Start with netif_msg_xxx/NETIF_MSG_xxx first, and figure out the
logging API for those cases.  These cover the majority of common cases,
and most are not specific to hardware at all.  Starting at the driver
level and trying to move driver-specific messages into the upper layers
is the wrong direction, I feel.

2) If we are going to do major surgery on messages, make them more
computer-parseable at the same time.  Human readable, since it must
above-all-else be kernel hacker readable, ... but computer parseable.

Here is an example.  DISCLAIMER:  No doubt there is a better format, it
is merely for illustration.
        "%s: performance event: scatter/gather I/O disabled\n"
                becomes
        "dev=%s evt=perf sgio=disabled\n"

Basically a key-value format.  Resist the urge to use numeric response
codes.  For stuff like this, I think both Linus and the typical human
brain prefer English words to numeric response codes.  This suggested
output is not unlike some arch's show-processor-state sysrq output.

3) _Somebody_ needs to do some "ground pounding", and figure out what
info sysadmins and users want to see.  Event logging in general, so far,
seems to me more like a management checklist item than a real user
need... but I am quite willing to be proved wrong.  Until we get
feedback along these lines, I tend to resist changes like this in
general.  My initial read of your attached patch was that it was a long
of source churn, and I couldn't fathom what any user would gain from it all.

        Jeff

There are a whole bunch of netif_msg_xxx and corresponding NETIF_MSG_xxx
bits.  I don't see much need to change that I think getting the logging
API right for those would be an important first step.

        Jeff

P.S. It is important to note the bits are laid out in increasing verbosity.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

patch for common networking error messages

Post by Janice Girouar » Wed, 18 Jun 2003 01:00:13



   Date:06/16/2003 05:27 PM

   And all the scripts checking for the existing messages in log files?
   Screw them, right?

That's a good point.  One possible suggestion would be to submit more than
one stdmsgs.h files.  One a legacy file, and one that is more consistent
from message to message.. shooting for a gradual migration.

Ultimately, I think standard messages would greatly support/simplify
scripts, especially between the myriad of ethernet drivers.  Each one
reports the data slightly differently, so you're error log analysis needs
to recognize 100 or so ways of being told that the link just went down.

Janice

                      "David S. Miller"                                                                                  






                                               Subject:  Re: patch for common networking error messages                  


   Date: Mon, 16 Jun 2003 17:29:15 -0500

   For the sake of consistency and automatic error log analysis, it might
be

And all the scripts checking for the existing messages
in log files?  Screw them, right?

This whole idea is starting to leave a very bad taste in
my mouth...

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

patch for common networking error messages

Post by Nivedita Singhv » Wed, 18 Jun 2003 01:00:20




>    Date: Mon, 16 Jun 2003 15:13:05 -0700

>    I'd certainly like to see messages from the driver when the
>    card enters/leaves promiscuous mode,

> egrep "promiscuous mode" net/core/dev.c | grep printk

Yeah, but dev_mc_upload() doesnt return any status ;).
(For those of us who distrust hw (Sorry Scott! :))).

But it was just my example, I assure you. I'm not
holding up a flag in the wind on this particular nit.
I do see positives in the feature as a whole though.
It would be a shame to get grounded for minor things..

thanks,
Nivedita

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

patch for common networking error messages

Post by David S. Mille » Wed, 18 Jun 2003 01:00:22



   Date: Mon, 16 Jun 2003 15:45:20 -0700


   I'd agree a lot of thought (and agreement :))has to go
   into this before changing minor nits and stuff, and not
   causing too much disruption..Evolution, as opposed to
   revolution ;).  I would hope that most wouldnt need changing..

There would be absolutely ZERO disruption if you guys would use you
brains and implement what you're actually trying to achieve, a system
event logging mechanism.

We have a message queueing mechanism using sockets, called netlink,
and you can make whatever actions in the kernel you think should be
monitored go and stuff messages into this system event netlink socket.

Then, you don't have to standardize a bunch of absolutely silly
strings (I mean, the concept is so incredibly stupid), you get events
that are in a precisely defined format going over this netlink socket.

Then whoever in userspace reads out the messages can interpret them
however the * it wants to.  It is then trivial to parse the
messages and filter them.  Furthermore, you could even transmit such
messages over a network connection to a remote logging server as-is.

And hey, look, for network links going up and down we have the hooks
already.  Funny that...
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://www.veryComputer.com/
Please read the FAQ at  http://www.veryComputer.com/

 
 
 

1. seek help w common ultrix error messages

Hi,

I'm trying to install zoo.

In the installation process I get the following error messages :

 warning: passing arg 2 of `signal' from incompatible pointer type
 warning: data definition has no type or storage class

Aside from going into the code and altering each appearance of signal
and figuring out the nature of the second warning I'm curious if there
are some well known work arounds for this.

Please e-mail, but feel free to post.

Emmett

2. "Reusing" Linux Partition

3. Error message continuous error messages

4. HELP!!!! installer won't recognize USB keyboard/mouse!

5. KMOD error messages - proposal and patch

6. Radley method works for New OSR 5 Release Supplement

7. SOFTWARE: CERN httpd v3.0 patch for User Defined Error Messages

8. Chmod on directories only?

9. Patch error message

10. PATCH: PC9800 system common area definition

11. [phantom@FreeBSD.org: cvs commit: ports/java/jdk14/files patch-common::Defs.gmk]

12. Error message with network card

13. Help with network error messages.