Hi Artem,

Pekka Enberg wrote:
quoted text
> > But these don't make much sense to me. Why would you want to be able
> > to compile out printks at this granularity? Why not enable all of them
> > when CONFIG_UBIFS_FS_DEBUG is enabled?

On Tue, Apr 1, 2008 at 11:51 AM, Artem Bityutskiy <dedekind@yandex.ru> wrote:
quoted text
>  Well, its just more convenient for us. If I know the bug is somewhere in
>  the journal, I enable the journal messages - less flooding. We may
>  lessen the amount, but it is still handy to have some classes of
>  prints separate.

Yeah, perhaps that's a sign that you're doing it wrong? You currently
have 430 separate debug printks sprinkled around in UBIFS. The way to
reduce that is to move as much logging as possible higher up the call
chain and dump as much information as you can there. That's what
ext2_error() does, for example. So I'm not opposed to a ubifs_error()
or ubifs_warning() even if that's used in a controlled fashion. The
way you do debugging checks now is totally ad hoc and IMHO not
acceptable to the mainline kernel.

And like I said, if you need _tracing_ you might want to look at
Ingo's ftrace or some other similar tracing infrastructure and use
that. The upside of it is that you can basically have it enabled at
run-time too.

Pekka Enberg wrote:
quoted text
> > Why would you not want to enable all of these for development kernels?

On Tue, Apr 1, 2008 at 11:51 AM, Artem Bityutskiy <dedekind@yandex.ru> wrote:
quoted text
>  Some of the checks are very heavy-weight. For example, the tree checking
>  functions scan the whole TNC/LPT B-tree, which means they read it from
>  flash, they check CRC, and they make sure the tree is consistent and
>  has sane data. They are very useful when hunting bugs, but they are too
>  slow to be always enabled.

So perhaps you could just separate those heavy-weight options and have
all others under CONFIG_UBIFS_DEBUG?

                        Pekka
--
unsubscribe notice
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/