On Tue, 2020-06-09 at 18:42 +0100, Edward Cree wrote: > On 09/06/2020 17:58, Joe Perches wrote: > > On Tue, 2020-06-09 at 13:16 +0200, Greg Kroah-Hartman wrote: > > > What is wrong with the existing control of dynamic > > > debug messages that you want to add another type of arbitrary grouping > > > to it? > > There is no existing grouping mechanism. > > > > Many drivers and some subsystems used an internal one > > before dynamic debug. > > > > $ git grep "MODULE_PARM.*\bdebug\b"|wc -l > > 501 > > > > This is an attempt to unify those homebrew mechanisms. > In network drivers, this is probablyusing the existing groupings > defined by netif_level() - see NETIF_MSG_DRV and friends. Note > that those groups are orthogonal to the level, i.e. they control > netif_err() etc. as well, not just debug messages. These are _not_ netif_<level> control flags. Some are though. For instance: $ git grep "MODULE_PARM.*\bdebug\b" drivers/net | head -10 drivers/net/ethernet/3com/3c509.c:MODULE_PARM_DESC(debug, "debug level (0-6)"); drivers/net/ethernet/3com/3c515.c:MODULE_PARM_DESC(debug, "3c515 debug level (0-6)"); drivers/net/ethernet/3com/3c59x.c:MODULE_PARM_DESC(debug, "3c59x debug level (0-6)"); drivers/net/ethernet/adaptec/starfire.c:MODULE_PARM_DESC(debug, "Debug level (0-6)"); drivers/net/ethernet/allwinner/sun4i-emac.c:MODULE_PARM_DESC(debug, "debug message flags"); drivers/net/ethernet/altera/altera_tse_main.c:MODULE_PARM_DESC(debug, "Message Level (-1: default, 0: no output, 16: all)"); drivers/net/ethernet/amazon/ena/ena_netdev.c:MODULE_PARM_DESC(debug, "Debug level (0=none,...,16=all)"); drivers/net/ethernet/amd/atarilance.c:MODULE_PARM_DESC(lance_debug, "atarilance debug level (0-3)"); drivers/net/ethernet/amd/lance.c:MODULE_PARM_DESC(lance_debug, "LANCE/PCnet debug level (0-7)"); drivers/net/ethernet/amd/pcnet32.c:MODULE_PARM_DESC(debug, DRV_NAME " debug level"); These are all level/class output controls. > Certainly in the case of sfc, and I'd imagine for many other net > drivers too, the 'debug' modparam is setting the default for > net_dev->msg_enable, which can be changed after probe with > ethtool. True. > It doesn't look like the proposed mechanism subsumes that (we have > rather more than 5 groups, and it's not clear how you'd connect > it to the existing msg_enable (which uapi must be maintained); if > you don't have a way to do this, better exclude drivers/net/ from > your grep|wc because you won't be unifying those - in my tree > that's 119 hits. Likely not. I agree it'd be useful to attach the modparam control flag to the dynamic debug use somehow. cheers, Joe