03 May, 2011

1 commit


23 Sep, 2010

1 commit


17 Oct, 2008

1 commit

  • Base infrastructure to enable per-module debug messages.

    I've introduced CONFIG_DYNAMIC_PRINTK_DEBUG, which when enabled centralizes
    control of debugging statements on a per-module basis in one /proc file,
    currently, /dynamic_printk/modules. When, CONFIG_DYNAMIC_PRINTK_DEBUG,
    is not set, debugging statements can still be enabled as before, often by
    defining 'DEBUG' for the proper compilation unit. Thus, this patch set has no
    affect when CONFIG_DYNAMIC_PRINTK_DEBUG is not set.

    The infrastructure currently ties into all pr_debug() and dev_dbg() calls. That
    is, if CONFIG_DYNAMIC_PRINTK_DEBUG is set, all pr_debug() and dev_dbg() calls
    can be dynamically enabled/disabled on a per-module basis.

    Future plans include extending this functionality to subsystems, that define
    their own debug levels and flags.

    Usage:

    Dynamic debugging is controlled by the debugfs file,
    /dynamic_printk/modules. This file contains a list of the modules that
    can be enabled. The format of the file is as follows:


    .
    .
    .

    : Name of the module in which the debug call resides
    : whether the messages are enabled or not

    For example:

    snd_hda_intel enabled=0
    fixup enabled=1
    driver enabled=0

    Enable a module:

    $echo "set enabled=1 " > dynamic_printk/modules

    Disable a module:

    $echo "set enabled=0 " > dynamic_printk/modules

    Enable all modules:

    $echo "set enabled=1 all" > dynamic_printk/modules

    Disable all modules:

    $echo "set enabled=0 all" > dynamic_printk/modules

    Finally, passing "dynamic_printk" at the command line enables
    debugging for all modules. This mode can be turned off via the above
    disable command.

    [gkh: minor cleanups and tweaks to make the build work quietly]

    Signed-off-by: Jason Baron
    Signed-off-by: Greg Kroah-Hartman

    Jason Baron
     

13 Oct, 2007

1 commit


09 Jun, 2006

1 commit

  • Now that kconfig can load multiple configurations, it becomes simple to
    integrate the split config step, by simply comparing the new .config file with
    the old auto.conf (and then saving the new auto.conf). A nice side effect is
    that this saves a bit of disk space and cache, as no data needs to be read
    from or saved into the splitted config files anymore (e.g. include/config is
    now 648KB instead of 5.2MB).

    Signed-off-by: Roman Zippel
    Signed-off-by: Andrew Morton
    Signed-off-by: Sam Ravnborg

    Roman Zippel
     

17 Apr, 2005

1 commit

  • Initial git repository build. I'm not bothering with the full history,
    even though we have it. We can create a separate "historical" git
    archive of that later if we want to, and in the meantime it's about
    3.2GB when imported into git - space that would just make the early
    git days unnecessarily complicated, when we don't have a lot of good
    infrastructure for it.

    Let it rip!

    Linus Torvalds