From: Andrew Morton <akpm@linux-foundation.org>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Sasikanth babu <sasikanth.v19@gmail.com>, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] debugfs: New debugfs interface for creation of files, directory and symlinks
Date: Wed, 2 May 2012 15:44:38 -0700 [thread overview]
Message-ID: <20120502154438.8b44b5a3.akpm@linux-foundation.org> (raw)
In-Reply-To: <20120502223603.GA3103@kroah.com>
On Wed, 2 May 2012 15:36:03 -0700
Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
> >
> > The API is stupid and wrong, actually. There is no *advantage* to
> > having done it this way - none at all.
>
> Yes there is, it makes the caller logic trivial, which was the main goal
> here in getting people to use it over creating new proc files all the
> time for no good reason.
>
> No one cares about the return value when you create a proc file, either
> it succeeds or not, and you handle things from there, you never change
> the name to try it again.
>
> Same thing with debugfs, you only care if it works or not, and really,
> you don't even care if it works, as the api lets you continue on if it
> didn't just fine.
>
> These are debugging files, with no set rules on what they contain. Yes,
> people have grown to get used to them over the years, but the namespace
> in which they work has worked out for itself, and I have yet to ever
> hear of any two people wanting to create the same file/directory
> anywhere, and have anything fail.
>
> Or am I missing some subsystem that is having problems like this with
> debugfs?
grr, you appear to have ignored everything I wrote. Here it is again:
> > That's the whole reason we have errnos: to report on what went wrong,
> > so operators can understand *why* it failed and so that programmers can
> > diagnose and fix bugs.
and
> > If well-written code checks the return value (as it should) and then
> > propagates an error code back to its caller (as it should), the stupid
> > debugfs interface forces that caller to invent an errno from thin air.
> > And if that guessed errno is wrong, it is actively misleading!
I would add that an interface which encourages callers to silently
ignore programming and configuration errors is not a good one.
next prev parent reply other threads:[~2012-05-02 22:44 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-02 12:50 [PATCH] debugfs: New debugfs interface for creation of files, directory and symlinks Sasikantha babu
2012-05-02 15:31 ` Greg Kroah-Hartman
2012-05-02 21:58 ` Sasikanth babu
2012-05-02 22:04 ` Greg Kroah-Hartman
2012-05-02 22:20 ` Andrew Morton
2012-05-02 22:36 ` Greg Kroah-Hartman
2012-05-02 22:44 ` Andrew Morton [this message]
2012-05-02 23:07 ` Greg Kroah-Hartman
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=20120502154438.8b44b5a3.akpm@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=sasikanth.v19@gmail.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.