![]() | |||||||||||
Messages in this thread Complete thread (EXPERIMENTAL) |
On Tue, Apr 1, 2008 at 11:51 AM, Artem Bityutskiy <dedekind@yandex.ru> wrote:
JFFS2 has the similar thing. I myself fixed bugs just by asking people
enabling them and sending the log. Very useful. This is why we also added
them to UBIFS - good JFFS2 experience. 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
Yeah, this is what the dbg_gen doing :-) But often we need messages from
lower layers, why not? I agree we should lessen the amount of prints, but
I still do not get it what is your argument against them the shiny prints
which we may compile in when we want to debug :)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
Why? What is wrong with this? As I said, we found it very useful in JFFS2,
because I has been working with JFFS2 for _long_ time. Talk to David
Woodhouse and ask how many times that made him fix a bug just by having
people send a log. Why do you want to prevent us from having this?
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.
This alternative is not really acceptable. We want to have only _few_
debugging things always enabled, and have other things always compiled
out and compiled in only when hunting a problem.On Tue, Apr 1, 2008 at 11:51 AM, Artem Bityutskiy <dedekind@yandex.ru> 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? We can if we have to. But these checks often affect the FS behavior and sometimes make bugs go away and become unreproducible. Especially locking problems. This is why we want to be able to enabling them separately. -- Best Regards, Artem Bityutskiy (Артём Битюцкий) -- 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/ | ||||||||||
![]() | |||||||||||
| Last update: 2008-04-01 11:31 [W:0.400 / U:0.140 seconds] ©2003-2005 Jasper Spaans | |||||||||||