linux-kernel - Re: [RFC PATCH 26/26] UBIFS: include FS to compilation

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 28 Apr 2008 14:23:26 +0300
From:	Adrian Hunter <ext-adrian.hunter@...ia.com>
To:	ext ext Christoph Hellwig <hch@...radead.org>
CC:	Artem Bityutskiy <dedekind@...dex.ru>,
	Pekka Enberg <penberg@...helsinki.fi>,
	Artem Bityutskiy <Artem.Bityutskiy@...ia.com>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [RFC PATCH 26/26] UBIFS: include FS to compilation

Christoph Hellwig wrote:
>Artem Bityutskiy wrote:
>>Pekka Enberg wrote:
>>>>Artem Bityutskiy wrote:
>>>>  +config UBIFS_FS_DEBUG_MSG_GEN
>>>>  +
>>>>  +config UBIFS_FS_DEBUG_MSG_JRN
>>>>  +
>>>>  +config UBIFS_FS_DEBUG_MSG_CMT
>>>>  +
>>>>  +config UBIFS_FS_DEBUG_MSG_BUDG
>>>>  +
>>>>  +config UBIFS_FS_DEBUG_MSG_LOG
>>>>  +
>>>>  +config UBIFS_FS_DEBUG_MSG_TNC
>>>>  +
>>>>  +config UBIFS_FS_DEBUG_MSG_LP
>>>>  +
>>>>  +config UBIFS_FS_DEBUG_MSG_FIND
>>>>  +
>>>>  +config UBIFS_FS_DEBUG_MSG_MNT
>>>>  +
>>>>  +config UBIFS_FS_DEBUG_MSG_IO
>>>>  +
>>>>  +config UBIFS_FS_DEBUG_MSG_GC
>>>>  +
>>>>  +config UBIFS_FS_DEBUG_MSG_SCAN
>>>
>>> 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? 
>>
>>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.
>>
>>We will think how to lessen the amount and granularity of this. 
>>
> On Mon, Apr 28, 2008 at 10:09:06AM +0300, Adrian Hunter wrote:
>>Christoph Hellwig wrote:
>>> It's everything but convenient :)  Please make it one config option to
>>> compile in all debug code and then have a module option to select the
>>> verbosity level at runtime.
>> Surely that judgement should be made by people who actually debug UBIFS.
> 
> I've debugged enough code including filesystems far more complex than
> ubifs so you can happily trust my judgement.  Even if not you can simply
> switch on your brain and notice that a runtime/boottime switch is always
> more convenient than a compile-time switch, and the only reason against
> it would be a performance penalty.

You have gone off on a tangent.  The original context was discussing the
need for granulated debug messages.  I have restored the context above.

Addressing the original discussion, the convenience is best expressed by
example.  Say you want to try improving the garbage collector.  It is
convenient to be able to get messages just about the garbage collector.
Say you want to add index node merging to the TNC, it is convenient to
get messages just about the TNC.  And so on.  Hence my original point
stands:  the convenience is evident to someone working with the code, but
not to someone who isn't.

Note also, that switching on all the debug messages is not exactly
inconvenient.  After all, you just select all the config options.

You seem to have mistakenly inferred I was impugning your judgement.  That
was not the point.

Coming back to your issue of a mount-time option for debug messages.  I am
not sure any other file systems do that.  In general I would say having to
switch on the debug config option and also change either the kernel command
line or init scripts, seems in fact much less convenient.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/