On Tue, Apr 1, 2008 at 11:51 AM, Artem Bityutskiy <dedekind@xxxxxxxxx> wrote:JFFS2 has the similar thing. I myself fixed bugs just by asking peopleWell, 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 toYeah, this is what the dbg_gen doing :-) But often we need messages from
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 whatWhy? What is wrong with this? As I said, we found it very useful in JFFS2,
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 atThis alternative is not really acceptable. We want to have only _few_
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.
On Tue, Apr 1, 2008 at 11:51 AM, Artem Bityutskiy <dedekind@xxxxxxxxx> wrote: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?