From: Takashi Iwai <tiwai@suse.de>
To: Mark Brown <broonie@sirena.org.uk>
Cc: Zhaolei <zhaolei@cn.fujitsu.com>,
alsa-devel@alsa-project.org,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
lrg@slimlogic.co.uk
Subject: Re: [alsa-devel] [PATCH] Fix debugfs_create_dir's error checking method for sound/soc/
Date: Fri, 17 Oct 2008 17:21:21 +0200 [thread overview]
Message-ID: <s5hfxmvw8lq.wl%tiwai@suse.de> (raw)
In-Reply-To: <20081017132340.GF2546@sirena.org.uk>
At Fri, 17 Oct 2008 14:23:42 +0100,
Mark Brown wrote:
>
> On Fri, Oct 17, 2008 at 09:04:55PM +0800, Zhaolei wrote:
>
> > debugfs_create_dir() returns NULL if an error occurs, returns -ENODEV
> > when debugfs is not enabled in the kernel.
>
> ...
>
> > asoc_debugfs = debugfs_create_dir("asoc", NULL);
> > - if (!IS_ERR(asoc_debugfs))
> > + if (!IS_ERR(asoc_debugfs) && asoc_debugfs)
> > debugfs_create_u32("dapm_pop_time", 0744, asoc_debugfs,
> > &pop_time);
>
> Hrmpf. This looks like something that should be fixed in debugfs -
> using both error reporting strategies is rather unhelpful and we're
> actually loosing information in the case where debugfs is built. I'll
> send a patch and see what people thing.
This looks like a design. In linux/debugfs.h:
/*
* We do not return NULL from these functions if CONFIG_DEBUG_FS is not enabled
* so users have a chance to detect if there was a real error or not. We don't
* want to duplicate the design decision mistakes of procfs and devfs again.
*/
Though, I agree that the detailed error information is lost by
returning NULL...
Takashi
next prev parent reply other threads:[~2008-10-17 15:21 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-10-17 13:04 Zhaolei
2008-10-17 13:23 ` Mark Brown
2008-10-17 15:21 ` Takashi Iwai [this message]
2008-10-17 15:26 ` [alsa-devel] " Takashi Iwai
2008-10-17 15:28 ` Mark Brown
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=s5hfxmvw8lq.wl%tiwai@suse.de \
--to=tiwai@suse.de \
--cc=alsa-devel@alsa-project.org \
--cc=broonie@sirena.org.uk \
--cc=linux-kernel@vger.kernel.org \
--cc=lrg@slimlogic.co.uk \
--cc=zhaolei@cn.fujitsu.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®