[lkml]   [2007]   [Jun]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: LogFS take four
    On Mon, 4 June 2007 00:18:21 +0200, Arnd Bergmann wrote:
    > On Sunday 03 June 2007, Jörn Engel wrote:
    > > Unchanged:
    > > o error handling
    > >
    > ...
    > > Won't happen (unless I get convinced to do otherwise):
    > > o Change LOGFS_BUG() and LOGFS_BUG_ON() to inline functions
    > > These are macros for very much the same reasons BUG() and BUG_ON() are.
    > I wonder how many of your LOGFS_BUG{,_ON} still remain after the
    > error handling is in place to deal with broken file system contents.
    > Ideally, I'd say the current LOGFS_BUG() should be replaced with
    > a function that prints about the kind of error it has hit (rate-limited),
    > potentially calls logfs_crash_dump(), and remounts the medium read-only,
    > but _not_ call BUG().

    That sounds fairly useful, actually. Do a WARN_ON(), call
    logfs_crash_dump(), remount read-only and finished. Rate-limiting might
    be unnecessary as the read-only thing already limits the rate to 1.

    I like the idea.


    Fools ignore complexity. Pragmatists suffer it.
    Some can avoid it. Geniuses remove it.
    -- Perlis's Programming Proverb #58, SIGPLAN Notices, Sept. 1982
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2007-06-04 11:13    [W:0.020 / U:28.352 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site