usb.h: reduce syslog clutter

The current versions of the err() / info() / warn() message macros in include/linux/usb.h insert __FILE__ at the beginning of the message. When those macros where introduced, back in 2.2 times, that expanded to the name of the source file, which was fine.

However, with the build process changes in 2.5, __FILE__ now expands to the complete path name of the source file within the kernel tree. Consequently, that part of the kernel message now takes up about half of an 80 character screen line.

The following patch modifies these macros so that, when used in a module, they'll insert the module name instead, which is significantly shorter and also tends to be more useful to users (as opposed to kernel developers) trying to make sense of a particular message.

It also adds a macro for the "notice" message level which was missing so far.

The triple checks for defined(CONFIG_MODULES), defined(THIS_MODULE) and THIS_MODULE are necessary to catch all possible combinations of
- kernel being built with or without module support
- source file #including linux/usb.h or not
- source file actually being built as a module or not

Quoted 8 lines · Tilman Schmidt

The current versions of the err() / info() / warn() message macros in include/linux/usb.h insert __FILE__ at the beginning of the message. [...]
The following patch modifies these macros so that, when used in a module, they'll insert the module name instead, which is significantly shorter and also tends to be more useful to users (as opposed to kernel developers) trying to make sense of a particular message.

Quoted 2 lines

It also adds a macro for the "notice" message level which was missing so far.

[...]
What was wrong with my suggestion that we simply delete these macros and convert the USB code over to using the proper dev_info(), dev_warn(), dev_err(), and dev_notice() macros instead?

[T]here are a few places in the USB code that do
not have a valid device and so they can't be dropped entirely.

Quoted 10 lines · Greg KH

Quoted 8 lines · Tilman Schmidt

The current versions of the err() / info() / warn() message macros in include/linux/usb.h insert __FILE__ at the beginning of the message. [...]
The following patch modifies these macros so that, when used in a module, they'll insert the module name instead, which is significantly shorter and also tends to be more useful to users (as opposed to kernel developers) trying to make sense of a particular message.

Quoted 6 lines

Quoted 2 lines

It also adds a macro for the "notice" message level which was missing so far.

[...]
What was wrong with my suggestion that we simply delete these macros and convert the USB code over to using the proper dev_info(), dev_warn(), dev_err(), and dev_notice() macros instead?

Just that, as you remarked yourself:

Quoted 2 lines

[T]here are a few places in the USB code that do
not have a valid device and so they can't be dropped entirely.

and I still don't see how to handle that situation with the dev_ macros.

But I thought you said you would accept that patch if I submitted it through the kernel-janitors. Why the change of mind?

Quoted 25 lines · Tilman Schmidt

Quoted 11 lines · Greg KH

Quoted 8 lines · Tilman Schmidt

The current versions of the err() / info() / warn() message macros in include/linux/usb.h insert __FILE__ at the beginning of the message. [...]
The following patch modifies these macros so that, when used in a module, they'll insert the module name instead, which is significantly shorter and also tends to be more useful to users (as opposed to kernel developers) trying to make sense of a particular message.

Quoted 7 lines

Quoted 2 lines

It also adds a macro for the "notice" message level which was missing so far.

[...]
What was wrong with my suggestion that we simply delete these macros and convert the USB code over to using the proper dev_info(), dev_warn(), dev_err(), and dev_notice() macros instead?

Just that, as you remarked yourself:

Quoted 7 lines

Quoted 2 lines

[T]here are a few places in the USB code that do
not have a valid device and so they can't be dropped entirely.

and I still don't see how to handle that situation with the dev_ macros.

But I thought you said you would accept that patch if I submitted it through the kernel-janitors. Why the change of mind?

No, I think you misunderstood me. I said that converting the USB code over to using the proper dev_* macros would be a good janitor's project, not that you need to submit this patch through them.

There are only a very few places that these macros can not be used, and only after converting everything that can possibly be changed, then we can see if these are still really needed or not.

Quoted 35 lines · Greg KH

Quoted 25 lines · Tilman Schmidt

Quoted 11 lines · Greg KH

Quoted 8 lines · Tilman Schmidt

The current versions of the err() / info() / warn() message macros in include/linux/usb.h insert __FILE__ at the beginning of the message. [...]
The following patch modifies these macros so that, when used in a module, they'll insert the module name instead, which is significantly shorter and also tends to be more useful to users (as opposed to kernel developers) trying to make sense of a particular message.

Quoted 7 lines

Quoted 2 lines

It also adds a macro for the "notice" message level which was missing so far.

[...]
What was wrong with my suggestion that we simply delete these macros and convert the USB code over to using the proper dev_info(), dev_warn(), dev_err(), and dev_notice() macros instead?

Just that, as you remarked yourself:

Quoted 7 lines

Quoted 2 lines

[T]here are a few places in the USB code that do
not have a valid device and so they can't be dropped entirely.

and I still don't see how to handle that situation with the dev_ macros.

But I thought you said you would accept that patch if I submitted it through the kernel-janitors. Why the change of mind?

Quoted 7 lines

No, I think you misunderstood me. I said that converting the USB code over to using the proper dev_* macros would be a good janitor's project, not that you need to submit this patch through them.

There are only a very few places that these macros can not be used, and only after converting everything that can possibly be changed, then we can see if these are still really needed or not.

Greg, as you may remember, Hansj?rg and I are trying to submit an existing, working driver for inclusion in the main kernel tree. That driver does have quite a few places where it must emit a message without reliably having access to a valid device structure. The janitors can't convert that for us because it is not part of the tree yet;

it can't become part of the tree because it uses those macros you say shouldn't be propagated any further; I can't convert it myself because I don't know how, and when I ask you you only tell me not to worry. Catch-22.

What harm does it do to fix those macros now when they are needed in existing code, even if they might disappear sometime in kernel 2.6.21 or so? Does it justify blocking the inclusion of a driver in the tree?

Fourteen months ago you told me there were no valid reasons for not including a USB driver in the main kernel tree. Have we hit upon such a reason after all?