Messages in this thread | | | Date | Sun, 29 Aug 2004 16:08:27 +0200 | From | Jens Axboe <> | Subject | Re: [2.6 patch][3/3] mm/ BUG -> BUG_ON conversions |
| |
On Sun, Aug 29 2004, Adrian Bunk wrote: > On Sun, Aug 29, 2004 at 03:01:56PM +0200, Jens Axboe wrote: > > On Sun, Aug 29 2004, Oliver Neukum wrote: > > > Am Sonntag, 29. August 2004 14:03 schrieb Jens Axboe: > > > > > The intention is, to add an option that lets BUG/BUG_ON/WARN_ON/PAGE_BUG > > > > > do nothing. This option should be hidden under EMBEDDED. > > > > > > > > > > In some environments, this seems to be desirable. > > > > > > > > That only makes sense if you are using BUG incorrectly. A BUG() > > > > condition is something that is non-recoverable, undefining that doesn't > > > > make any sense regardless of the environment. > > > > > > Why not? Giving reports about unrecoverable errors is sensible > > > only if the report can be read. On system this is not the case, you > > > can just salvage the memory and let it crash. > > > > "Unrecoverable" can quite easily mean "something really bad has > > happened, corruption imminent". So maybe you would want BUG/BUG_ON to > > restart the box there, the restart-on-panic should help you there. > >... > > The current sh/sh64 implementation doesn't seem to do any of the things > you expect from BUG: > > #define BUG() do { \ > printk("kernel BUG at %s:%d!\n", __FILE__, __LINE__); \ > asm volatile("nop"); \ > } while (0)
Well too bad for them, I'm glad I'm not trusting any data to a machine with that architecture.
-- Jens Axboe
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |