* Andrew Morton <akpm@linux-foundation.org> wrote:i asked for that because we had regressions in the past in the form of "it takes one minute to resume". please keep the warn-on so that it can be detected automatically. Adding yet another printk just complicates the automated answer to the "is this kernel that just booted up fine or not" question. In fact i'd love to have the analogue to /proc/lockdep_debug's "debug_locks: 0" output. I.e. the kernel should know it via one central flag whether any bugs that need human review have been detected so far. Say /proc/sys/kernel/kernel_is_buggy. This value could even be multi-level: a WARN_ON() increases it by +1, a kernel crash increases it by +1000. ( That way i could run overnight tests that will only stop on a kernel_is_buggy >= 1000 condition, while it could ignore simpler WARN_ON()s. ) Ingo --
| Ingo Molnar | [bug] block subsystem related crash with latest -git |
| Tarkan Erimer | Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3 |
| Greg KH | [GIT PATCH] driver core patches against 2.6.24 |
| Adrian Bunk | Re: net/ipv4/fib_trie.c - compile error (Re: 2.6.23-rc3-mm1) |
git: | |
| Gerrit Renker | [PATCH 03/37] dccp: List management for new feature negotiation |
| Jarek Poplawski | [PATCH take 2] pkt_sched: Protect gen estimators under est_lock. |
| David Miller | [GIT]: Networking |
| Natalie Protasevich | [BUG] New Kernel Bugs |
