Messages in this thread |  | | Date | Tue, 10 Sep 2002 14:32:28 -0500 | From | Oliver Xymoron <> | Subject | Re: [linux-usb-devel] Re: [BK PATCH] USB changes for 2.5.34 |
| |
On Tue, Sep 10, 2002 at 11:40:27AM -0700, Linus Torvalds wrote: > > On Tue, 10 Sep 2002, David S. Miller wrote: > > > > IMO we should have ASSERT() and OHSHIT(), > > > > I fully support the addition of an OHSHIT() macro. > > Oh, please no. We'd end up with endless asserts in the networking layer, > just because David would find it amusing. > > I can just see it now - code bloat hell. > > And no, I still don't like ASSERT(). > > I think the approach should clearly spell what the trouble level is: > > DEBUG(x != y, "x=%d, y=%d\n", x, y); > > WARN(x != y, "crap happens: x=%d y=%d\n", x, y); > > FATAL(x != y, "Aiee: x=%d y=%d\n", x, y); > > where the DEBUG one gets compiled out normally (or has some nice per-file > way of being enabled/disabled - a perfect world would expose the on/off in > devicefs as a per-file entity when kernel debugging is on), WARN continues > but writes a message (and normally does _not_ get compiled out), and FATAL > is like our current BUG_ON().
Which still leaves the question, does it really make sense for FATAL/BUG to forcibly kill the machine? If the bug is truly fatal, presumably the machine kills itself in short order anyway, otherwise we might have a shot at recording the situation. A more useful distinction might be in terms of risk of damaging filesystems (or perhaps hardware) if we continue, something like BROKEN/DANGEROUSLY_BROKEN.
-- "Love the dolphins," she advised him. "Write by W.A.S.T.E.." - 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/
|  |