Re: [PATCH 1/3] Introduce FW_BUG and FW_INFO to consistenly tell users about BIOS bugs

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, 27 Aug 2008 17:44:02 +0200 Thomas Renninger <trenn@xxxxxxx> wrote:

> The idea is to add this to printk after the severity:
> printk(KERN_ERR FW_BUG "This is not our fault\n");
> 
> If a Firmware issue should be hidden, because it is
> work-arounded, but you still want to see something popping up e.g.
> for info only:
> printk(KERN_INFO FW_INFO "This is done stupid, we can handle it,
> but it should better be avoided in future\n");
> 
> or on the Linuxfirmwarekit to tell vendors that they did something
> stupid or wrong without bothering the user:
> printk(KERN_INFO FW_BUG "This is done stupid, we can handle it,
> but it should better be avoided in future\n");
> 
> Signed-off-by: Thomas Renninger <trenn@xxxxxxx>
> ---
>  include/linux/kernel.h |    3 +++
>  1 files changed, 3 insertions(+), 0 deletions(-)
> 
> diff --git a/include/linux/kernel.h b/include/linux/kernel.h
> index 2651f80..68ebfc2 100644
> --- a/include/linux/kernel.h
> +++ b/include/linux/kernel.h
> @@ -190,6 +190,9 @@ extern int kernel_text_address(unsigned long addr);
>  struct pid;
>  extern struct pid *session_of_pgrp(struct pid *pgrp);
>  
> +#define FW_BUG		"[FW Bug]: "
> +#define FW_INFO		"[FW Info]: "
> +
>  #ifdef CONFIG_PRINTK
>  asmlinkage int vprintk(const char *fmt, va_list args)
>  	__attribute__ ((format (printf, 1, 0)));

It all seems a bit pointless to me.  Presumably there is some
real-world supportability benefit to this.  If that were convincingly
described in the changelog then people might be a bit more interested.

Also, what is a user to do when they see this mysterious "[FW Bug]:" thing?

They can do

	grep -r "FW Bug" Documentation

but that won't work.

Then they might google for "[FW Bug]: ", but google thinks they're
searching for Volkswagens.

So as this change is designed to fix some as-yet-unrevealed
supportability problem, it could be significantly improved upon, no?

--
To unsubscribe from this list: send the line "unsubscribe cpufreq" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Devel]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Forum]     [Linux SCSI]

  Powered by Linux