On Tue, 2011-04-05 at 22:15 +0200, RafaÅ MiÅecki wrote:
> 2011/4/5 Joe Perches <joe@xxxxxxxxxxx>:
> > On Tue, 2011-04-05 at 21:57 +0200, RafaÅ MiÅecki wrote:
> >> Signed-off-by: RafaÅ MiÅecki <zajec5@xxxxxxxxx>
> > Just some trivia.
[]
> >> diff --git a/drivers/bcmai/core.c b/drivers/bcmai/core.c
> > []
> >> + bcmai_err("Power control not implemented!\n");
> > []
> >> diff --git a/include/linux/bcmai/bcmai.h b/include/linux/bcmai/bcmai.h
> > []
> >> +#define bcmai_info(fmt, args...) printk(KERN_INFO "bcmai: " fmt, ##args)
> >> +#ifdef CONFIG_BCMAI_DEBUG
> >> +#define bcmai_dbg(fmt, args...) printk(KERN_DEBUG "bcmai debug: " fmt, ##args)
> >> +#else
> >> +#define bcmai_dbg(fmt, args...) do { } while (0)
> >> +#endif
> >> +#define bcmai_err(fmt, args...) printk(KERN_ERR "bcmai error: " fmt, ##args)
> > I think there's very little value in prefixing
> > "error" and "debug" in front of equivalent
> > KERN_<level> message levels.
> > I think you might as well just use pr_<level>
> > and pr_fmt.
> Hm, I've taken this idea from ssb and b43:
> [b43err] printk(KERN_ERR "b43-%s ERROR: %pV", ...);
I think that per module extra text based
"error/info/whatnot" prefixes are just unnecessary
duplication to KERN_<level>.
> [_pll_init] ssb_printk(KERN_ERR PFX "ERROR: PLL init unknown for...
[]
I think ssb_printk and CONFIG_SSB_SILENT is not
particularly useful. I think printk support is
or should be generally enabled or disabled and a
per module on/off just for embedded module size
is unnecessary complexity for almost no benefit.
> is there some official coding-style for such a situations?
There's definitely no mandated coding-style for such things
and I certainly support per module named module_<level>
prefixing where the module passes some struct pointer
or another for things like masking printing of specific
errors or debugging levels.
Like:
#define <modulename>_info(foo, fmt, ...) \
pr_info("%s: " fmt, foo->info, ##__VA_ARGS__)
or
__attribute__((format (printf, 2, 3)))
int <modulename>_info(struct type, const char *fmt, ...)
{
int rtn;
struct va_format vaf;
va_list args;
va_start(args, fmt);
vaf.fmt = fmt;
vaf.va = &args;
rtn = pr_info"%s: %pV", type->info, &vaf);
va_end(args);
return rtn;
}
> >> diff --git a/include/linux/mod_devicetable.h b/include/linux/mod_devicetable.h
> > []
> >> +/* AI core, see drivers/bcmai/ */
> >> +struct bcmai_device_id {
> >> + __u16 manuf;
> >> + __u16 id;
> >> + __u8 rev;
> >> +};
> >
> > Do some of these structs need __packed declarations?
>
> I was reading about __packed long time ago and it was a little tricky
> for me. However I don't see anything in mod_devicetable.h using that
> __packed. Why should we?
I didn't look very hard. If this struct (or any other)
is read directly from some device expecting a contiguous
byte block, then it's likely that it should be declared
"__packed".
cheers, Joe
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
