Re: Tiny error in printk output for clocksource : a3:<6>Time: acpi_pm clocksource has been installed.

[Joe Perches <joe@perches.com>]

On Thu, 2006-09-28 at 18:19 +0200, Denis Vlasenko wrote:
> Actually, I think it makes sense to have both: yours for complicated
> cases (printk with lots of other %something) and mine for simple ones
> (no local variable, smaller code).
> > Strictly, not all MAC addresses are 6 byte.
> > Maybe all the Ethernet/TR addresses should use the
> > IEEE EUI48 designation?  That feels a bit like the
> > KiB/KB distinction, but it is technically correct.
> > Would a patch with an DEV6_ADDR->EUI48 substitution
> > be acceptable?
> Maybe. Doesn't look obvious, but if it is in standards...

I brought the RFC patch from several months ago forward
using the implicit stack var in DECLARE_EUI48.

It's quite large, > 300k.

The patches also use single printks for more messages so
that when CONFIG_PCI_MULTITHREAD_PROBE is set, message
lines won't be split.

I separated the patches into groups where the output is:
1-identical, 2-changed but likely harmless, and 3-other.

In some cases, mac addresses are formatted for use in
/proc and seq_printf either in lower case or with just
a "%x" instead of "%02X", or not colon separated.
It's not good to change those formats.

I'd like to agree on the form before posting.

implicit DECLARE_EUI48; and EUI48(address)
or
explicit DECLARE_EUI48(name) and EUI48(name, address)

Warts:

There are some new non-debug warnings that are generated
when using the stack automatic because some of the debug
printks don't get compiled and you get "unused variable"
warnings.

It's possible to remove the DECLARE_EUI48 completely
by not indirecting the formatting string
"%02X:%02X:%02X:%02X:%02X:%02X" to "%s" and a function,
but it increases the kernel or module size.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/