netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jim Keniston <jkenisto@us.ibm.com>
To: Andrew Morton <akpm@osdl.org>
Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com,
	jgarzik@pobox.com, scott.feldman@intel.com, kessler@us.ibm.com
Subject: Re: [PATCH 2.6.1] Net device error logging
Date: Tue, 20 Jan 2004 15:19:29 -0800	[thread overview]
Message-ID: <400DB781.4229A084@us.ibm.com> (raw)
In-Reply-To: 20040119184630.5d066735.akpm@osdl.org

Andrew Morton wrote:
>
> Jim Keniston <jkenisto@us.ibm.com> wrote:
> >
> > The enclosed patch implements the netdev_* error-logging macros for
> >  network drivers.
>
> Looks OK to me.
>
> But it does make one wonder whether we'll soon see standalone patches for
> scsi_printk(), pci_bridge_printk(), random_other_subsystem_printk(), ...?

Well, there is indeed sdev_printk for the SCSI mid-layer and low-level
drivers.  Dan Stekloff posted an updated patch for this on linux-scsi
yesterday.

When Alan Cox suggested dev_printk, it was with the idea that other
subsystems might have similar macros.  Although I don't know of other
such macros in the works, I wouldn't rule them out.

>
> Or is it intended that the backend logging code will be implemented mainly
> in terms of the `struct device'?  So netdev_printk() will be a bit of
> netdev-specific boilerplate which then calls into a more generic
> device_printk()?

I think dev_printk will work just fine for drivers where [driver name +
bus ID] is the appropriate message tag.  Where that's not the case, other
macros emerge.  (For example, for net devices you want the interface
name, and for SCSI devices the SCSI bus ID is more interesting than the
PCI bus ID.)

Another thing to consider is whether, for the subsystem in question,
some other struct pointer (e.g., struct net_device* or struct
scsi_device*) might prove more useful in the future than the struct
device pointer.  I.e., such pointers could be used to get at the struct
device AND other subsystem-specific info.

Also, there are also situations where there is no underlying struct
device (e.g., some upper-level network drivers) or the driver is not yet
defined (e.g., during a SCSI scan).

Jim Keniston

  reply	other threads:[~2004-01-20 23:19 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-01-19 20:25 [PATCH 2.6.1] Net device error logging Jim Keniston
2004-01-20  2:46 ` Andrew Morton
2004-01-20 23:19   ` Jim Keniston [this message]
2004-01-20 18:51 ` Rask Ingemann Lambertsen
2004-01-20 23:06   ` Jim Keniston

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=400DB781.4229A084@us.ibm.com \
    --to=jkenisto@us.ibm.com \
    --cc=akpm@osdl.org \
    --cc=jgarzik@pobox.com \
    --cc=kessler@us.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@oss.sgi.com \
    --cc=scott.feldman@intel.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).