All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stephen Hemminger <shemminger@vyatta.com>
To: "Jeff Kirsher" <jeffrey.t.kirsher@intel.com>
Cc: "Dan Williams" <dcbw@redhat.com>,
	davem@davemloft.net, netdev@vger.kernel.org, jeff@garzik.org,
	"Bruce Allan" <bruce.w.allan@intel.com>
Subject: Re: [NET-NEXT PATCH 08/14] e1000e: link up/down messages must follow a specific format
Date: Fri, 21 Nov 2008 12:16:25 -0800	[thread overview]
Message-ID: <20081121121625.6cdf22b6@extreme> (raw)
In-Reply-To: <9929d2390811211123i284a3939lf96e53208ee8357e@mail.gmail.com>

On Fri, 21 Nov 2008 11:23:42 -0800
"Jeff Kirsher" <jeffrey.t.kirsher@intel.com> wrote:

> On Fri, Nov 21, 2008 at 11:04 AM, Dan Williams <dcbw@redhat.com> wrote:
> > On Fri, 2008-11-21 at 11:01 -0800, Jeff Kirsher wrote:
> >> From: Bruce Allan <bruce.w.allan@intel.com>
> >>
> >> The system log messages created on a link status change need to follow a
> >> specific format to work with tools some customers use.
> >
> > Um, shouldn't those tools be listening to netlink for carrier events, or
> > are these tools run on a separate machine using on some later date using
> > the logs from the machine with the e1000e?
> >
> > Dan
> >
> 
> From my understanding these tools are looking at the logs and that is
> why we need to have a consistent log message.
> 

These tools are tied to a specific driver (yours), because not all drivers
generate a message or the same format message. This may be okay for Intel
but is really stupid design...

It would be good if link state transitions generated uevents (online/offline).
Then udev, hal and others could use that without netlink.

  reply	other threads:[~2008-11-21 20:16 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-11-21 18:59 [NET-NEXT PATCH 01/14] e1000e: disable correctable errors for quad ports while going to D3 Jeff Kirsher
2008-11-21 18:59 ` [NET-NEXT PATCH 02/14] e1000e: commit speed/duplex changes for m88 PHY Jeff Kirsher
2008-11-22  0:50   ` David Miller
2008-11-21 18:59 ` [NET-NEXT PATCH 03/14] e1000e: 82571 check for link fix on 82571 serdes Jeff Kirsher
2008-11-22  0:50   ` David Miller
2008-11-21 18:59 ` [NET-NEXT PATCH 04/14] e1000e: update comments listing supported parts for each MAC family Jeff Kirsher
2008-11-22  0:51   ` David Miller
2008-11-21 19:00 ` [NET-NEXT PATCH 05/14] e1000e: check return of pci_save_state Jeff Kirsher
2008-11-22  0:51   ` David Miller
2008-11-21 19:00 ` [NET-NEXT PATCH 06/14] e1000e: remove unnecessary header file inclusions Jeff Kirsher
2008-11-22  0:53   ` David Miller
2008-11-21 19:00 ` [NET-NEXT PATCH 07/14] e1000e: ESB2 config after link up Jeff Kirsher
2008-11-22  0:53   ` David Miller
2008-11-21 19:01 ` [NET-NEXT PATCH 08/14] e1000e: link up/down messages must follow a specific format Jeff Kirsher
2008-11-21 19:04   ` Dan Williams
2008-11-21 19:23     ` Jeff Kirsher
2008-11-21 20:16       ` Stephen Hemminger [this message]
2008-11-21 21:19         ` Jeff Kirsher
2008-11-22  0:55   ` David Miller
2008-11-21 19:01 ` [NET-NEXT PATCH 09/14] e1000e: fix possible buffer overflow Jeff Kirsher
2008-11-22  0:57   ` David Miller
2008-11-21 19:01 ` [NET-NEXT PATCH 10/14] e1000e: sync change flow control variables with ixgbe Jeff Kirsher
2008-11-22  0:57   ` David Miller
2008-11-21 19:02 ` [NET-NEXT PATCH 11/14] e1000e: cosmetic newline in debug message Jeff Kirsher
2008-11-22  1:00   ` David Miller
2008-11-21 19:02 ` [NET-NEXT PATCH 12/14] e1000e: store EEPROM version number to prevent unnecessary NVM reads Jeff Kirsher
2008-11-22  1:00   ` David Miller
2008-11-21 19:02 ` [NET-NEXT PATCH 13/14] e1000e: fix incorrect link status when switch module pulled Jeff Kirsher
2008-11-22  1:01   ` David Miller
2008-11-21 19:02 ` [NET-NEXT PATCH 14/14] e1000e: check return code from NVM accesses and fix bank detection Jeff Kirsher
2008-11-22  1:02   ` David Miller
2008-11-22  0:49 ` [NET-NEXT PATCH 01/14] e1000e: disable correctable errors for quad ports while going to D3 David Miller

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20081121121625.6cdf22b6@extreme \
    --to=shemminger@vyatta.com \
    --cc=bruce.w.allan@intel.com \
    --cc=davem@davemloft.net \
    --cc=dcbw@redhat.com \
    --cc=jeff@garzik.org \
    --cc=jeffrey.t.kirsher@intel.com \
    --cc=netdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.