3. A new macro, netdev_fatal, is included. Given the call
netdev_fatal(dev, HW, "NIC fried!\n");
the indicated message is always logged: the msglevel arg (HW, in this
case) is NOT consulted. In fact, the msglevel arg to netdev_fatal
is ignored in this implementation. (As previously discussed, in some
future implementation, the msglevel could be logged to help indicate
the circumstances under which the event was logged.)
I couldn't find the previous discussion on netdev_fatal, so sorry if
this has already been worked out. It uses KERN_ERR; did you mean
something stronger? If not, why not just use netdev_err(dev, ALL,
"...")? What is the situation in the driver where we'd want to use
_fatal? How do I know when to use _fatal and when to use _err?
-scott
"Feldman, Scott" wrote:
quoted
3. A new macro, netdev_fatal, is included. Given the call
netdev_fatal(dev, HW, "NIC fried!\n");
the indicated message is always logged: the msglevel arg (HW, in this
case) is NOT consulted. In fact, the msglevel arg to netdev_fatal
is ignored in this implementation. (As previously discussed, in some
future implementation, the msglevel could be logged to help indicate
the circumstances under which the event was logged.)
I couldn't find the previous discussion on netdev_fatal, so sorry if
this has already been worked out. It uses KERN_ERR; did you mean
something stronger? If not, why not just use netdev_err(dev, ALL,
"...")? What is the situation in the driver where we'd want to use
_fatal? How do I know when to use _fatal and when to use _err?
-scott
Good question. There was a discussion thread where somebody pared down
the cc list (no LKML, no netdev, an apparently no Scott). I saved most
of the messages, and can send them along to you if you want.
Anyway, in support of passing the NETIF_MSG_* msglevel as an arg to the
netdev_* macros, I said that it...
also opens the door for logging more clearly what part of the driver (PROBE,
TX, RX, etc.) the message comes from.
David Brownell replied:
This is a different issue. Why wouldn't it be enough
to have unique messages?
I replied:
First, I don't want acceptance of the netdev_* idea to hinge on this
minor issue. Everything below is blue(r) sky...
That said, it could be useful for an error-analysis utility to know that
the message is (say) a WARNING categorized as an RX_ERR, especially if the
utility hasn't been configured to recognized that specific message string.
That's probably info that wouldn't come to you via printk (e.g., since
syslog discards the severity level), but could come via another logging
or monitoring system that plugs in (along with printk) via netdev_*.
One problem with this idea is that, as I read Becker's document
(URL above), "fatal" errors should always be logged, and therefore
not tagged as PROBE, TX_ERR, etc. If we wanted to pursue this idea,
we could implement
netdev_fatal(dev, PROBE, "...")
which logs the message unconditionally (KERN_ERR) and categorizes it as
a PROBE error.
Jeff Garzik replied:
printk'ing probe errors is definitely something I want to encourage.
Probe errors are the most visible indication of what went wrong, if the
driver fails to load. These are the messages that help developers
figure out the problem. So I like the direction you suggest, in "If we
wanted to pursue[...]"
In summary, the idea for netdev_fatal() is based on the idea that the msglevel
arg can not only be used for verbosity control, but can be logged as yet
another useful piece of info. For printk-based logging, it could easily be
added to the message prefix:
eth2: PROBE: Invalid Ethernet address
If you log this message using
netdev_err(dev, PROBE, "Invalid Ethernet address\n")
it will be logged only if the PROBE flag is set in the msg_enable bitmap.
If you log it using
netdev_fatal(dev, PROBE, "Invalid Ethernet address\n")
it will always be logged.
As mentioned above, I don't think the netdev_fatal idea is central to the
whole netdev_printk idea.
By the way, regarding using KERN_ERR vs. something stronger: It's pretty
unusual for a driver to log anything as KERN_CRIT or worse -- presumably
due to a desire not to overreact if the nth of n redundant devices happens
to fail. So unless we can agree on a definition of KERN_CRIT (e.g., it
applies to any failure that makes a device unavailable pending human
intervention), I'd prefer to steer clear of that.
Jim