Re: [PATCH] drivers/base/core.c: always output device renaming messages.

Re: [PATCH] drivers/base/core.c: always output device renaming messages.

[Greg KH]

On Fri, Oct 11, 2013 at 10:58:18AM +0800, ethan.zhao wrote:
> From: "ethan.zhao" <ethan.kernel@gmail.com>
> 
> While loading ixgbevf driver,every vf detected will be output as the
> same name 'eth4':
> 
>  ixgbevf: Intel(R) 10 Gigabit PCI Express Virtual Function Network Driver -
>  version 2.8.7
>  Copyright (c) 2009-2012 Intel Corporation.
>  ixgbevf 0000:20:10.0: enabling device (0000 -> 0002)
>  ixgbe 0000:20:00.0 eth0: VF Reset msg received from vf 0
>  ixgbevf 0000:20:10.0: irq 199 for MSI/MSI-X
>  ixgbevf 0000:20:10.0: irq 200 for MSI/MSI-X
>  ixgbevf: eth%d: ixgbevf_init_interrupt_scheme: Multiqueue Disabled: Rx Queue
>  count = 1, Tx Queue count = 1

What is that message?  That's not good, "eth%d"?

>  ixgbevf: eth4: ixgbevf_probe: Intel(R) X540 Virtual Function
>  aa:bb:cc:dd:ee:f1
>  ixgbevf: eth4: ixgbevf_probe: LRO is disabled
>  ixgbevf: eth4: ixgbevf_probe: GRO is enabled
>  ixgbevf: eth4: ixgbevf_probe: Intel(R) 10 Gigabit PCI Express Virtual
>  Function Network Driver
>  ixgbevf 0000:20:10.2: enabling device (0000 -> 0002)
>  ixgbe 0000:20:00.0 eth0: VF Reset msg received from vf 1
>  ixgbevf 0000:20:10.2: irq 201 for MSI/MSI-X
>  ixgbevf 0000:20:10.2: irq 202 for MSI/MSI-X
>  ixgbevf: eth%d: ixgbevf_init_interrupt_scheme: Multiqueue Disabled: Rx Queue
>  count = 1, Tx Queue count = 1
>  ixgbevf: eth4: ixgbevf_probe: Intel(R) X540 Virtual Function
>  aa:bb:cc:dd:ee:f2
>  ixgbevf: eth4: ixgbevf_probe: LRO is disabled
>  ixgbevf: eth4: ixgbevf_probe: GRO is enabled
>  ixgbevf: eth4: ixgbevf_probe: Intel(R) 10 Gigabit PCI Express Virtual
> 
> But if we view the NICs with ifconfig, found no NIC named 'eth4', the cause is
> udev has renamed the 'eth4' to 'eth10', 'eth10' one by one. because no renaming
> messages output, that is confusing.
> So we need always output renaming messages in device_name() instead of pr_debug().
> After applied this patch, it is much clearer:

How is journald tracking this today, without this extra message sent to
the kernel log?  It knows what devices are renamed to what somehow.

I really don't want to clutter up the syslog for things that aren't
needed, and as userspace was the one that told the kernel to rename the
device, why does the kernel have to spit it back out again to userspace?
That seems redundant, don't you think?

>  ixgbevf: Intel(R) 10 Gigabit PCI Express Virtual Function Network Driver -
>  version 2.8.7
>  Copyright (c) 2009-2012 Intel Corporation.
>  ixgbevf 0000:20:10.0: enabling device (0000 -> 0002)
>  ixgbe 0000:20:00.0 eth0: VF Reset msg received from vf 0
>  ixgbevf 0000:20:10.0: Multiqueue Disabled: Rx Queue count = 1, Tx Queue count
>  = 1
>  ixgbevf: eth4: ixgbevf_probe: Intel(R) X540 Virtual Function
>  net eth4: 'eth4' renaming to 'eth8'

A bit redundant, "eth4" shows up twice.

>  aa:bb:cc:dd:ee:11
>  ixgbevf: eth8: ixgbevf_probe: LRO is disabled
>  ixgbevf: eth8: ixgbevf_probe: GRO is enabled
>  ixgbevf: eth8: ixgbevf_probe: Intel(R) 10 Gigabit PCI Express Virtual
>  Function Network Driver
>  ixgbevf 0000:20:10.2: enabling device (0000 -> 0002)
>  ixgbe 0000:20:00.0 eth0: VF Reset msg received from vf 1
>  ixgbevf 0000:20:10.2: Multiqueue Disabled: Rx Queue count = 1, Tx Queue count
>  = 1
>  ixgbevf: eth4: ixgbevf_probe: Intel(R) X540 Virtual Function
>  net eth4: 'eth4' renaming to 'eth9'
>  aa:bb:cc:dd:ee:12
>  ixgbevf: eth9: ixgbevf_probe: LRO is disabled
>  ixgbevf: eth9: ixgbevf_probe: GRO is enabled
>  ixgbevf: eth9: ixgbevf_probe: Intel(R) 10 Gigabit PCI Express Virtual
>  Function Network Driver
> 
> Signed-off-by: ethan.zhao <ethan.kernel@gmail.com>
> ---
>  drivers/base/core.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/drivers/base/core.c b/drivers/base/core.c
> index 2d1c6ba..9a98794 100644
> --- a/drivers/base/core.c
> +++ b/drivers/base/core.c
> @@ -1904,8 +1904,7 @@ int device_rename(struct device *dev, const char *new_name)
>  	if (!dev)
>  		return -EINVAL;
>  
> -	pr_debug("device: '%s': %s: renaming to '%s'\n", dev_name(dev),
> -		 __func__, new_name);
> +	dev_info(dev, "'%s' renaming to '%s'\n", dev_name(dev), new_name);

How about:
	dev_dbg(dev, "renaming to '%s'\n", new_name);

should be all that is needed, right?  Good call on pointing out that we
don't need to use pr_debug() here, don't know why I never noticed
that...

That way, if you really want to know this information, you can
dynamically turn on that line to be printed out, no need to clutter up
everyone else's logs.

Care to redo this?

thanks,

greg k-h

Re: [PATCH] drivers/base/core.c: always output device renaming messages.

[Bjorn Helgaas]

[+cc Don, e1000-devel]

On Fri, Oct 11, 2013 at 9:35 AM, Greg KH <gregkh@linuxfoundation.org> wrote:
> On Fri, Oct 11, 2013 at 10:58:18AM +0800, ethan.zhao wrote:
>> From: "ethan.zhao" <ethan.kernel@gmail.com>
>>
>> While loading ixgbevf driver,every vf detected will be output as the
>> same name 'eth4':
>>
>>  ixgbevf: Intel(R) 10 Gigabit PCI Express Virtual Function Network Driver -
>>  version 2.8.7
>>  Copyright (c) 2009-2012 Intel Corporation.
>>  ixgbevf 0000:20:10.0: enabling device (0000 -> 0002)
>>  ixgbe 0000:20:00.0 eth0: VF Reset msg received from vf 0
>>  ixgbevf 0000:20:10.0: irq 199 for MSI/MSI-X
>>  ixgbevf 0000:20:10.0: irq 200 for MSI/MSI-X
>>  ixgbevf: eth%d: ixgbevf_init_interrupt_scheme: Multiqueue Disabled: Rx Queue
>>  count = 1, Tx Queue count = 1
>
> What is that message?  That's not good, "eth%d"?

Just a reminder that ixgbevf 2.8.7 is not the driver version that's in
the kernel tree, so it's easy to spend time on mainline issue that
have been fixed in the out-of-tree versions, or vice versa.

Per Don, the latest ixgbevf driver is here:
https://sourceforge.net/projects/e1000/files/ixgbevf%20stable/

Bjorn

Re: [PATCH] drivers/base/core.c: always output device renaming messages.

[Greg KH]

On Fri, Oct 11, 2013 at 10:08:09AM -0600, Bjorn Helgaas wrote:
> [+cc Don, e1000-devel]
> 
> On Fri, Oct 11, 2013 at 9:35 AM, Greg KH <gregkh@linuxfoundation.org> wrote:
> > On Fri, Oct 11, 2013 at 10:58:18AM +0800, ethan.zhao wrote:
> >> From: "ethan.zhao" <ethan.kernel@gmail.com>
> >>
> >> While loading ixgbevf driver,every vf detected will be output as the
> >> same name 'eth4':
> >>
> >>  ixgbevf: Intel(R) 10 Gigabit PCI Express Virtual Function Network Driver -
> >>  version 2.8.7
> >>  Copyright (c) 2009-2012 Intel Corporation.
> >>  ixgbevf 0000:20:10.0: enabling device (0000 -> 0002)
> >>  ixgbe 0000:20:00.0 eth0: VF Reset msg received from vf 0
> >>  ixgbevf 0000:20:10.0: irq 199 for MSI/MSI-X
> >>  ixgbevf 0000:20:10.0: irq 200 for MSI/MSI-X
> >>  ixgbevf: eth%d: ixgbevf_init_interrupt_scheme: Multiqueue Disabled: Rx Queue
> >>  count = 1, Tx Queue count = 1
> >
> > What is that message?  That's not good, "eth%d"?
> 
> Just a reminder that ixgbevf 2.8.7 is not the driver version that's in
> the kernel tree, so it's easy to spend time on mainline issue that
> have been fixed in the out-of-tree versions, or vice versa.
> 
> Per Don, the latest ixgbevf driver is here:
> https://sourceforge.net/projects/e1000/files/ixgbevf%20stable/

I hate to ask why isn't this merged upstream, but given that this is an
Intel network driver, I know the answer :(

Thanks for pointing this out, saved me a trip through the kernel tree...

greg k-h

> 
> Bjorn

Re: [PATCH] drivers/base/core.c: always output device renaming messages.

[Ethan Zhao]

On Sat, Oct 12, 2013 at 1:26 AM, Skidmore, Donald C
<donald.c.skidmore@intel.com> wrote:
>> -----Original Message-----
>> From: Greg KH [mailto:gregkh@linuxfoundation.org]
>> Sent: Friday, October 11, 2013 9:12 AM
>> To: Bjorn Helgaas
>> Cc: ethan.zhao; linux-kernel@vger.kernel.org; Skidmore, Donald C; e1000-
>> devel@lists.sourceforge.net
>> Subject: Re: [PATCH] drivers/base/core.c: always output device renaming
>> messages.
>>
>> On Fri, Oct 11, 2013 at 10:08:09AM -0600, Bjorn Helgaas wrote:
>> > [+cc Don, e1000-devel]
>> >
>> > On Fri, Oct 11, 2013 at 9:35 AM, Greg KH <gregkh@linuxfoundation.org>
>> wrote:
>> > > On Fri, Oct 11, 2013 at 10:58:18AM +0800, ethan.zhao wrote:
>> > >> From: "ethan.zhao" <ethan.kernel@gmail.com>
>> > >>
>> > >> While loading ixgbevf driver,every vf detected will be output as
>> > >> the same name 'eth4':
>> > >>
>> > >>  ixgbevf: Intel(R) 10 Gigabit PCI Express Virtual Function Network
>> > >> Driver -  version 2.8.7  Copyright (c) 2009-2012 Intel Corporation.
>> > >>  ixgbevf 0000:20:10.0: enabling device (0000 -> 0002)  ixgbe
>> > >> 0000:20:00.0 eth0: VF Reset msg received from vf 0  ixgbevf
>> > >> 0000:20:10.0: irq 199 for MSI/MSI-X  ixgbevf 0000:20:10.0: irq 200
>> > >> for MSI/MSI-X
>> > >>  ixgbevf: eth%d: ixgbevf_init_interrupt_scheme: Multiqueue
>> > >> Disabled: Rx Queue  count = 1, Tx Queue count = 1
>> > >
>> > > What is that message?  That's not good, "eth%d"?
>> >
>> > Just a reminder that ixgbevf 2.8.7 is not the driver version that's in
>> > the kernel tree, so it's easy to spend time on mainline issue that
>> > have been fixed in the out-of-tree versions, or vice versa.
>> >
>> > Per Don, the latest ixgbevf driver is here:
>> > https://sourceforge.net/projects/e1000/files/ixgbevf%20stable/
>>
>> I hate to ask why isn't this merged upstream, but given that this is an Intel
>> network driver, I know the answer :(
>>
>> Thanks for pointing this out, saved me a trip through the kernel tree...
>>
>
> That message sure does look strange "eth%d"?   From reading your email I'm implying that it came from a 2.8.7 out or tree driver, is that correct?  The reason I'm asking is I want to make sure this is not an issue in the kernel tree or the latest out of tree driver.
Yes, it came from ixgbevf 2.8.7
>
> Also for what it is worth I do have all the patches queued in Jeff K. tree that gets the kernel tree and latest out of tree driver functionally in sync.  Once they pass our internal validation he should be pushing them upstream.
>
> Thanks for pointing out the error,
> -Don Skidmore <donald.c.skidmore@intel.com>
>
>

[PATCH] ixgbevf: Fix the debugging output when device is not registered

[Joe Perches]

A message can be output with an unidentified eth%d port
when the ixgbevf device is not registered.

ie: ixgbevf: eth%d: ixgbevf_init_interrupt_scheme: etc...

Fix this by using the generic netdev_name() helper
to emit "(unregistered net_device)" instead of "eth%d".

Neaten the format string that emits this too.

Signed-off-by: Joe Perches <joe@perches.com>
---
 drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c b/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c
index 59a62bb..1b48a55 100644
--- a/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c
+++ b/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c
@@ -2010,10 +2010,10 @@ static int ixgbevf_init_interrupt_scheme(struct ixgbevf_adapter *adapter)
 		goto err_alloc_queues;
 	}
 
-	hw_dbg(&adapter->hw, "Multiqueue %s: Rx Queue count = %u, "
-	       "Tx Queue count = %u\n",
-	       (adapter->num_rx_queues > 1) ? "Enabled" :
-	       "Disabled", adapter->num_rx_queues, adapter->num_tx_queues);
+	hw_dbg(&adapter->hw,
+	       "Multiqueue %s: Rx Queue count = %u, Tx Queue count = %u\n",
+	       (adapter->num_rx_queues > 1) ? "Enabled" : "Disabled",
+	       adapter->num_rx_queues, adapter->num_tx_queues);
 
 	set_bit(__IXGBEVF_DOWN, &adapter->state);
 
@@ -3645,7 +3645,7 @@ static void __exit ixgbevf_exit_module(void)
 char *ixgbevf_get_hw_dev_name(struct ixgbe_hw *hw)
 {
 	struct ixgbevf_adapter *adapter = hw->back;
-	return adapter->netdev->name;
+	return netdev_name(adapter->netdev);
 }
 
 #endif

Re: [PATCH] drivers/base/core.c: always output device renaming messages.

[Ethan Zhao]

On Sat, Oct 12, 2013 at 12:08 AM, Bjorn Helgaas <bhelgaas@google.com> wrote:
> [+cc Don, e1000-devel]
>
> On Fri, Oct 11, 2013 at 9:35 AM, Greg KH <gregkh@linuxfoundation.org> wrote:
>> On Fri, Oct 11, 2013 at 10:58:18AM +0800, ethan.zhao wrote:
>>> From: "ethan.zhao" <ethan.kernel@gmail.com>
>>>
>>> While loading ixgbevf driver,every vf detected will be output as the
>>> same name 'eth4':
>>>
>>>  ixgbevf: Intel(R) 10 Gigabit PCI Express Virtual Function Network Driver -
>>>  version 2.8.7
>>>  Copyright (c) 2009-2012 Intel Corporation.
>>>  ixgbevf 0000:20:10.0: enabling device (0000 -> 0002)
>>>  ixgbe 0000:20:00.0 eth0: VF Reset msg received from vf 0
>>>  ixgbevf 0000:20:10.0: irq 199 for MSI/MSI-X
>>>  ixgbevf 0000:20:10.0: irq 200 for MSI/MSI-X
>>>  ixgbevf: eth%d: ixgbevf_init_interrupt_scheme: Multiqueue Disabled: Rx Queue
>>>  count = 1, Tx Queue count = 1
>>
>> What is that message?  That's not good, "eth%d"?
>
> Just a reminder that ixgbevf 2.8.7 is not the driver version that's in
> the kernel tree, so it's easy to spend time on mainline issue that
> have been fixed in the out-of-tree versions, or vice versa.
>
Thanks, Yes, the driver version of ixgbevf in mainline  is far later
from the ones
in sourceforge.
the "eth%d" issue maybe  was fixed in recent 2.11.3 .

> Per Don, the latest ixgbevf driver is here:
> https://sourceforge.net/projects/e1000/files/ixgbevf%20stable/
>
> Bjorn

Re: [PATCH] drivers/base/core.c: always output device renaming messages.

[Ethan Zhao]

On Fri, Oct 11, 2013 at 11:35 PM, Greg KH <gregkh@linuxfoundation.org> wrote:
> On Fri, Oct 11, 2013 at 10:58:18AM +0800, ethan.zhao wrote:
>> From: "ethan.zhao" <ethan.kernel@gmail.com>
>>
>> While loading ixgbevf driver,every vf detected will be output as the
>> same name 'eth4':
>>
>>  ixgbevf: Intel(R) 10 Gigabit PCI Express Virtual Function Network Driver -
>>  version 2.8.7
>>  Copyright (c) 2009-2012 Intel Corporation.
>>  ixgbevf 0000:20:10.0: enabling device (0000 -> 0002)
>>  ixgbe 0000:20:00.0 eth0: VF Reset msg received from vf 0
>>  ixgbevf 0000:20:10.0: irq 199 for MSI/MSI-X
>>  ixgbevf 0000:20:10.0: irq 200 for MSI/MSI-X
>>  ixgbevf: eth%d: ixgbevf_init_interrupt_scheme: Multiqueue Disabled: Rx Queue
>>  count = 1, Tx Queue count = 1
>
> What is that message?  That's not good, "eth%d"?
>
This message came from ixgbevf version 2.8.7, not from kernel 3.11.4,
output netdev name before registration.

>>  ixgbevf: eth4: ixgbevf_probe: Intel(R) X540 Virtual Function
>>  aa:bb:cc:dd:ee:f1
>>  ixgbevf: eth4: ixgbevf_probe: LRO is disabled
>>  ixgbevf: eth4: ixgbevf_probe: GRO is enabled
>>  ixgbevf: eth4: ixgbevf_probe: Intel(R) 10 Gigabit PCI Express Virtual
>>  Function Network Driver
>>  ixgbevf 0000:20:10.2: enabling device (0000 -> 0002)
>>  ixgbe 0000:20:00.0 eth0: VF Reset msg received from vf 1
>>  ixgbevf 0000:20:10.2: irq 201 for MSI/MSI-X
>>  ixgbevf 0000:20:10.2: irq 202 for MSI/MSI-X
>>  ixgbevf: eth%d: ixgbevf_init_interrupt_scheme: Multiqueue Disabled: Rx Queue
>>  count = 1, Tx Queue count = 1
>>  ixgbevf: eth4: ixgbevf_probe: Intel(R) X540 Virtual Function
>>  aa:bb:cc:dd:ee:f2
>>  ixgbevf: eth4: ixgbevf_probe: LRO is disabled
>>  ixgbevf: eth4: ixgbevf_probe: GRO is enabled
>>  ixgbevf: eth4: ixgbevf_probe: Intel(R) 10 Gigabit PCI Express Virtual
>>
>> But if we view the NICs with ifconfig, found no NIC named 'eth4', the cause is
>> udev has renamed the 'eth4' to 'eth10', 'eth10' one by one. because no renaming
>> messages output, that is confusing.
>> So we need always output renaming messages in device_name() instead of pr_debug().
>> After applied this patch, it is much clearer:
>
> How is journald tracking this today, without this extra message sent to
> the kernel log?  It knows what devices are renamed to what somehow.
>
> I really don't want to clutter up the syslog for things that aren't
> needed, and as userspace was the one that told the kernel to rename the
> device, why does the kernel have to spit it back out again to userspace?
> That seems redundant, don't you think?
Yes, agree somehow , perfect system should run without any noise and
rubbish in log.
But if something wrong happened, no message shown will make us helpless.
As an user space daemon, udev, also has the reason to refuse any
message  output(
you have udev tracking tools).

'redundant', yes, sometime waste and not perfect, but sometime the
backup help us more.
>
>>  ixgbevf: Intel(R) 10 Gigabit PCI Express Virtual Function Network Driver -
>>  version 2.8.7
>>  Copyright (c) 2009-2012 Intel Corporation.
>>  ixgbevf 0000:20:10.0: enabling device (0000 -> 0002)
>>  ixgbe 0000:20:00.0 eth0: VF Reset msg received from vf 0
>>  ixgbevf 0000:20:10.0: Multiqueue Disabled: Rx Queue count = 1, Tx Queue count
>>  = 1
>>  ixgbevf: eth4: ixgbevf_probe: Intel(R) X540 Virtual Function
>>  net eth4: 'eth4' renaming to 'eth8'
>
> A bit redundant, "eth4" shows up twice.
You hate 'redundant' , got it.
>
>>  aa:bb:cc:dd:ee:11
>>  ixgbevf: eth8: ixgbevf_probe: LRO is disabled
>>  ixgbevf: eth8: ixgbevf_probe: GRO is enabled
>>  ixgbevf: eth8: ixgbevf_probe: Intel(R) 10 Gigabit PCI Express Virtual
>>  Function Network Driver
>>  ixgbevf 0000:20:10.2: enabling device (0000 -> 0002)
>>  ixgbe 0000:20:00.0 eth0: VF Reset msg received from vf 1
>>  ixgbevf 0000:20:10.2: Multiqueue Disabled: Rx Queue count = 1, Tx Queue count
>>  = 1
>>  ixgbevf: eth4: ixgbevf_probe: Intel(R) X540 Virtual Function
>>  net eth4: 'eth4' renaming to 'eth9'
>>  aa:bb:cc:dd:ee:12
>>  ixgbevf: eth9: ixgbevf_probe: LRO is disabled
>>  ixgbevf: eth9: ixgbevf_probe: GRO is enabled
>>  ixgbevf: eth9: ixgbevf_probe: Intel(R) 10 Gigabit PCI Express Virtual
>>  Function Network Driver
>>
>> Signed-off-by: ethan.zhao <ethan.kernel@gmail.com>
>> ---
>>  drivers/base/core.c | 3 +--
>>  1 file changed, 1 insertion(+), 2 deletions(-)
>>
>> diff --git a/drivers/base/core.c b/drivers/base/core.c
>> index 2d1c6ba..9a98794 100644
>> --- a/drivers/base/core.c
>> +++ b/drivers/base/core.c
>> @@ -1904,8 +1904,7 @@ int device_rename(struct device *dev, const char *new_name)
>>       if (!dev)
>>               return -EINVAL;
>>
>> -     pr_debug("device: '%s': %s: renaming to '%s'\n", dev_name(dev),
>> -              __func__, new_name);
>> +     dev_info(dev, "'%s' renaming to '%s'\n", dev_name(dev), new_name);
>
> How about:
>         dev_dbg(dev, "renaming to '%s'\n", new_name);

If something confusing or wrong, need to take a look.
For pr_debug(), We have to build and load a debug kernel…
For dev_dbg(),  We have to rebuild a kernel with CONFIG_DYNAMIC_DEBUG
set to 'y', that is default 'n'.
So, do you mean

dev_printk(KERN_DEBUG, dev, "renaming to '%s'\n", new_name);  ?

>
> should be all that is needed, right?  Good call on pointing out that we
> don't need to use pr_debug() here, don't know why I never noticed
> that...
>
> That way, if you really want to know this information, you can
> dynamically turn on that line to be printed out, no need to clutter up
> everyone else's logs.
>
> Care to redo this?
>
> thanks,
>
> greg k-h

Re: [PATCH] drivers/base/core.c: always output device renaming messages.

[Greg KH]

On Sat, Oct 12, 2013 at 02:52:51PM +0800, Ethan Zhao wrote:
> >> --- a/drivers/base/core.c
> >> +++ b/drivers/base/core.c
> >> @@ -1904,8 +1904,7 @@ int device_rename(struct device *dev, const char *new_name)
> >>       if (!dev)
> >>               return -EINVAL;
> >>
> >> -     pr_debug("device: '%s': %s: renaming to '%s'\n", dev_name(dev),
> >> -              __func__, new_name);
> >> +     dev_info(dev, "'%s' renaming to '%s'\n", dev_name(dev), new_name);
> >
> > How about:
> >         dev_dbg(dev, "renaming to '%s'\n", new_name);
> 
> If something confusing or wrong, need to take a look.
> For pr_debug(), We have to build and load a debug kernel…
> For dev_dbg(),  We have to rebuild a kernel with CONFIG_DYNAMIC_DEBUG
> set to 'y', that is default 'n'.

Why would you not enable that option these days?  All distros enable it,
and if you should too :)

> So, do you mean
> 
> dev_printk(KERN_DEBUG, dev, "renaming to '%s'\n", new_name);  ?

No, dev_dbg();.

thanks,

greg k-h

Re: [PATCH] drivers/base/core.c: always output device renaming messages.

[Ethan Zhao]

On Sun, Oct 13, 2013 at 1:50 AM, Greg KH <gregkh@linuxfoundation.org> wrote:
> On Sat, Oct 12, 2013 at 02:52:51PM +0800, Ethan Zhao wrote:
>> >> --- a/drivers/base/core.c
>> >> +++ b/drivers/base/core.c
>> >> @@ -1904,8 +1904,7 @@ int device_rename(struct device *dev, const char *new_name)
>> >>       if (!dev)
>> >>               return -EINVAL;
>> >>
>> >> -     pr_debug("device: '%s': %s: renaming to '%s'\n", dev_name(dev),
>> >> -              __func__, new_name);
>> >> +     dev_info(dev, "'%s' renaming to '%s'\n", dev_name(dev), new_name);
>> >
>> > How about:
>> >         dev_dbg(dev, "renaming to '%s'\n", new_name);
>>
>> If something confusing or wrong, need to take a look.
>> For pr_debug(), We have to build and load a debug kernel…
>> For dev_dbg(),  We have to rebuild a kernel with CONFIG_DYNAMIC_DEBUG
>> set to 'y', that is default 'n'.
>
> Why would you not enable that option these days?  All distros enable it,
> and if you should too :)
>
Okey, let them enable it in the Linux distribution.

Thanks,
Ethan

>> So, do you mean
>>
>> dev_printk(KERN_DEBUG, dev, "renaming to '%s'\n", new_name);  ?
>
> No, dev_dbg();.
>
> thanks,
>
> greg k-h