From: Pekka Enberg <penberg@cs.helsinki.fi>
To: Michael Thompson <michael.craig.thompson@gmail.com>
Cc: Phillip Hellewell <phillip@hellewell.homeip.net>,
akpm@osdl.org, linux-kernel@vger.kernel.org,
linux-fsdevel@vger.kernel.org, viro@ftp.linux.org.uk,
mike@halcrow.us, mhalcrow@us.ibm.com, mcthomps@us.ibm.com,
yoder1@us.ibm.com
Subject: Re: [PATCH 4/12: eCryptfs] Main module functions
Date: Mon, 21 Nov 2005 18:21:29 +0200 [thread overview]
Message-ID: <1132590089.8487.11.camel@localhost> (raw)
In-Reply-To: <afcef88a0511210810m751e8d35p603915edf96a67c6@mail.gmail.com>
Hi,
On 11/19/05, Pekka Enberg <penberg@cs.helsinki.fi> wrote:
> > > + ecryptfs_printk(1, KERN_NOTICE, "Enter; lower_dentry = [%p], "
> > > + "lower_dentry->d_name.name = [%s], dentry = "
> > > + "[%p], dentry->d_name.name = [%s], sb = [%p]; "
> > > + "flag = [%.4x]; lower_dentry->d_count "
> > > + "= [%d]; dentry->d_count = [%d]\n", lower_dentry,
> > > + lower_dentry->d_name.name, dentry, dentry->d_name.name,
> > > + sb, flag, atomic_read(&lower_dentry->d_count),
> > > + atomic_read(&dentry->d_count));
> >
> > Could you use KERN_DEBUG instead and drop ecryptfs_printk()?
On Mon, 2005-11-21 at 10:10 -0600, Michael Thompson wrote:
> I don't follow with what you mean. We use ecryptfs_printk for 2 reasons:
Okay, let me spell it out for you: I think it is damn ugly :-)
> 1) Debugging. There is (or atleast at one time was) a large amount of
> ecryptfs_printk's scattered around during the development process.
> Obviously, much has been removed because we don't need them much
> anymore. However, the normal printk functionality doesn't, afaik,
> provide function & line number by default. ecryptfs_printk inserts it
> automatically for easy of use.
Like you said, not all debugging aids should be merged. I don't think
function and line number is enough an argument to justify putting your
own printk() in. That's my thinking anyway.
> 2) Verbosity switch. The intent, eventually atleast, is to be able to
> toggle the value of the verbosity level of ecryptfs at run time (this
> isn't implemented at the moment)... or atleast that's my plan :P Its
> not my project so I have to get "approval" etc. The 0th argument is
> the verbosity in which this message applies (1 being just informative,
> 0 being critical).
Do you really need it? Wouldn't it be better if you figured out which
debug printk() statements make sense and leave those in with KERN_DEBUG?
Pekka
next prev parent reply other threads:[~2005-11-21 16:21 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-11-19 4:11 [PATCH 0/12: eCryptfs] eCryptfs version 0.1 Phillip Hellewell
2005-11-19 4:14 ` [PATCH 1/12: eCryptfs] Makefile and Kconfig Phillip Hellewell
2005-11-19 4:16 ` [PATCH 2/12: eCryptfs] Documentation Phillip Hellewell
2005-11-19 4:16 ` [PATCH 3/12: eCryptfs] Makefile Phillip Hellewell
2005-11-19 4:17 ` [PATCH 4/12: eCryptfs] Main module functions Phillip Hellewell
2005-11-19 10:47 ` Pekka Enberg
2005-11-20 15:34 ` Anton Altaparmakov
2005-11-20 19:06 ` Pekka Enberg
2005-11-21 16:10 ` Michael Thompson
2005-11-21 16:12 ` Michael Thompson
2005-11-21 16:21 ` Pekka Enberg [this message]
2005-11-19 4:18 ` [PATCH 5/12: eCryptfs] Header declarations Phillip Hellewell
2005-11-19 10:37 ` Pekka Enberg
2005-11-21 15:50 ` Michael Thompson
2005-11-19 4:19 ` [PATCH 6/12: eCryptfs] Superblock operations Phillip Hellewell
2005-11-19 10:50 ` Pekka Enberg
2005-11-21 15:57 ` Michael Thompson
2005-11-21 16:01 ` Pekka Enberg
2005-11-21 16:13 ` Michael Thompson
2005-11-21 16:15 ` Michael Thompson
2005-11-21 16:20 ` Pekka Enberg
2005-11-19 4:20 ` [PATCH 7/12: eCryptfs] File operations Phillip Hellewell
2005-11-19 10:53 ` Pekka Enberg
2005-11-21 15:58 ` Michael Thompson
2005-11-19 4:20 ` [PATCH 8/12: eCryptfs] Dentry operations Phillip Hellewell
2005-11-19 4:21 ` [PATCH 9/12: eCryptfs] Inode operations Phillip Hellewell
2005-11-19 4:22 ` [PATCH 10/12: eCryptfs] Mmap operations Phillip Hellewell
2005-11-19 4:23 ` [PATCH 11/12: eCryptfs] Keystore Phillip Hellewell
2005-11-19 4:23 ` [PATCH 12/12: eCryptfs] Crypto functions Phillip Hellewell
2005-11-19 6:16 ` [PATCH 0/12: eCryptfs] eCryptfs version 0.1 Andrew Morton
2005-11-21 20:28 ` Michael Halcrow
2005-11-21 21:41 ` James Morris
2005-11-21 22:11 ` Michael Thompson
-- strict thread matches above, loose matches on Subject: below --
2005-11-03 3:32 Phillip Hellewell
2005-11-03 3:49 ` [PATCH 4/12: eCryptfs] Main module functions Phillip Hellewell
2005-11-03 6:02 ` Greg KH
2005-11-03 15:09 ` Michael Thompson
2005-11-03 15:47 ` Alexey Dobriyan
2005-11-03 15:40 ` Michael Thompson
2005-11-03 21:34 ` Michael Thompson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1132590089.8487.11.camel@localhost \
--to=penberg@cs.helsinki.fi \
--cc=akpm@osdl.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mcthomps@us.ibm.com \
--cc=mhalcrow@us.ibm.com \
--cc=michael.craig.thompson@gmail.com \
--cc=mike@halcrow.us \
--cc=phillip@hellewell.homeip.net \
--cc=viro@ftp.linux.org.uk \
--cc=yoder1@us.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.