[Tux3] Review incoming changes

OGAWA Hirofumi hirofumi at mail.parknet.co.jp
Tue Dec 16 01:48:40 PST 2008


Daniel Phillips <phillips at phunq.net> writes:

> Introduce tux_error() for fs corruption:
>
>    We should add sb to all warn, error and trace and assert macros,
>    then tux_error can just be warn.  The difference between warn and
>    error in kernel is that error would put the fs into read-only
>    mode, as should assert (which calls error), instead of just oopsing.
>    There may be a few places where I have assumed error will not return,
>    these should be hunted down and changed to error returns.
>
>    With the additional sb parameter, we can turn tracing output on and
>    off at runtime.  When we start hitting bugs on big filesystems, that
>    kind of control can be a real help.
>
>    I don't think we need to call these macros tux_, they are pretty
>    generic.

It would work if we remove many erorr(), e.g. in main(). Then it is
defined/used like tux_error(). However, we would want current error()
instead after all (error message with exit() or die()). So, instead, I
added tux_error() with comment, and of course, it will become to the
function finally with read-only or panic() or something.

> Clear the existent magic first, then overwrite:
>
>    Yes, more sensible.  Does MD really want us to clear 64 KB at the top
>    of the volume?  That would seem rather sloppy of MD.  Really, it
>    should rely on the just the final sector of a volume to know if it
>    is an MD volume.

IIRC, MD RAID is using final 64kb. I think we should clear the top
1024bytes and final 64kb. (And with it, to make sure, we would check if
volume size is bigger than 64kb, instead of clearing 64kb blindly.)

> Introduce ARRAY_SIZE():
>
>    This macro fits the pattern of vecset, veccpy and vecmove already
>    in tux3.h, so we can rename it to vecsize.

The kernel has ARRAY_SIZE() already. And vec* can be pointer, but
ARRAY_SIZE() must be real array. Actually, the kernel has more code to
check if argument is real array.

Thanks.
-- 
OGAWA Hirofumi <hirofumi at mail.parknet.co.jp>

_______________________________________________
Tux3 mailing list
Tux3 at tux3.org
http://mailman.tux3.org/cgi-bin/mailman/listinfo/tux3



More information about the Tux3 mailing list