public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Randy Dunlap <randy.dunlap@oracle.com>
To: tytso@mit.edu, Greg KH <greg@kroah.com>,
	Arve Hj?nnev?g <arve@android.com>,
	linux-pm@lists.linux-foundation.org,
	linux-kernel@vger.kernel.org, Pavel Machek <pavel@ucw.cz>,
	"Rafael J. Wysocki" <rjw@sisk.pl>,
	Len Brown <len.brown@intel.com>
Subject: Re: [PATCH 5/9] PM: suspend_block: Add debugfs file
Date: Sun, 25 Apr 2010 17:50:28 -0700	[thread overview]
Message-ID: <4BD4E354.6010803@oracle.com> (raw)
In-Reply-To: <20100426004558.GA13043@thunk.org>

On 04/25/10 17:45, tytso@mit.edu wrote:
> On Sun, Apr 25, 2010 at 05:23:06PM -0700, Randy Dunlap wrote:
>> Yeah, I think that it should be in procfs.  It's not strictly closed
>> to new files.  (IOW, I'm sure that we can find a bunch of recent files
>> added to procfs.)
> 
> That's reasonable (I think the whole /proc is evil crusade is really
> dumb) --- but at the same time, remember how frustrating it is for the
> poor embedded developer who doesn't know who to ignore and what
> "rules" to ignore.  They were told months ago /proc is evil, and so
> they moved it to /debugfs, precisely because it was billed as "it has
> no rules".  For all I know some helpful community developer may have
> even suggested that to them.
> 
> It is extremely frustrating to embedded developers when they get
> conflicting advice, especially in this case, when it was *in* /proc in
> the first place.  I'm not sure what to do about this --- my approach
> is to sometimes say, "f*ck it, that's stupid advice", and ship it to
> Linus, who tends to be *much* less of a pendant than most of the
> people who review code --- but that's because I know what I can
> ignore.  (I seriously doubt Linus cares much about whether it ends up
> the file ends up /debugfs or /proc, and would take the code either
> way.)  But for someone who doesn't understand when you can do this,
> and who tries to follow every single piece of criticism they get, the
> end result can often be a huge amount fo wasted time and frustration.
> 
> It would be nice if we could get better at this, since I'm sure this
> is not the only time when embedded code submissions have gotten what
> the submitting developers might consider to be a runaround....

Agreed, we could/should do much better.
Agreed, I'm sure that it is frustrating to the contributors.
Agreed about Linus taking it either way.  :)

Thanks for your summary and bringing it up (yet again).

> (And just to be clear, I'm not criticising your commends; my personal
> preference is slightly in favor of /proc, but more than anythign else,
> I consider it a very minor point.  I just want to point out that they
> _started_ with the file in /proc and changed it to /debugfs based on
> someone NACK'ing their patch, with a "/proc, eeeeewwww" comment.
> Sometimes I think some code reviewers get too much of a sense of power
> trip by thinking they can NACK other people's code over their own pet
> peeves.... instead of approaching it from a somewhat more collegial
> point of view trying to make the code better.  Present company
> excepted, of course.  :-)


-- 
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***

  reply	other threads:[~2010-04-26  0:51 UTC|newest]

Thread overview: 61+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-04-23  1:08 [PATCH 0/9] Suspend block api (version 4) Arve Hjønnevåg
2010-04-23  1:08 ` [PATCH 1/9] PM: Add suspend block api Arve Hjønnevåg
2010-04-23  1:08   ` [PATCH 2/9] PM: suspend_block: Add driver to access suspend blockers from user-space Arve Hjønnevåg
2010-04-23  1:08     ` [PATCH 3/9] PM: suspend_block: Abort task freezing if a suspend_blocker is active Arve Hjønnevåg
2010-04-23  1:08       ` [PATCH 4/9] PM: suspend_block: Switch to list of active and inactive suspend blockers Arve Hjønnevåg
2010-04-23  1:08         ` [PATCH 5/9] PM: suspend_block: Add debugfs file Arve Hjønnevåg
2010-04-23  1:08           ` [PATCH 6/9] PM: suspend_block: Add suspend_blocker stats Arve Hjønnevåg
2010-04-23  1:08             ` [PATCH 7/9] PM: Add suspend blocking work Arve Hjønnevåg
2010-04-23  1:08               ` [PATCH 8/9] Input: Block suspend while event queue is not empty Arve Hjønnevåg
2010-04-23  1:08                 ` [PATCH 9/9] power_supply: Block suspend while power supply change notifications are pending Arve Hjønnevåg
2010-04-23 20:56                 ` [PATCH 8/9] Input: Block suspend while event queue is not empty Randy Dunlap
2010-04-23 21:08                   ` Dmitry Torokhov
2010-04-24  5:02                     ` Arve Hjønnevåg
2010-04-24 14:36                       ` [linux-pm] " Alan Stern
2010-04-25  2:30                         ` Rafael J. Wysocki
2010-04-25 15:29                           ` Alan Stern
2010-04-25 22:41                             ` Arve Hjønnevåg
2010-04-24  4:58                   ` Arve Hjønnevåg
2010-04-23  8:16               ` [PATCH 7/9] PM: Add suspend blocking work Tejun Heo
2010-04-23 12:20                 ` Oleg Nesterov
2010-04-23 22:49                   ` Arve Hjønnevåg
2010-04-24  5:21                     ` Arve Hjønnevåg
2010-04-24  6:33                     ` Tejun Heo
2010-04-24  7:21                       ` Arve Hjønnevåg
2010-04-24  7:43                         ` Tejun Heo
2010-04-26 14:06                     ` Oleg Nesterov
2010-04-23 20:58           ` [PATCH 5/9] PM: suspend_block: Add debugfs file Randy Dunlap
2010-04-24  3:23             ` Arve Hjønnevåg
2010-04-24  4:24               ` Randy Dunlap
2010-04-24  4:54                 ` Arve Hjønnevåg
2010-04-25 18:15             ` Greg KH
2010-04-25 19:53               ` Randy Dunlap
2010-04-26  0:00                 ` tytso
2010-04-26  0:23                   ` Randy Dunlap
2010-04-26  0:45                     ` tytso
2010-04-26  0:50                       ` Randy Dunlap [this message]
2010-04-26  1:39                     ` [linux-pm] " Alan Stern
2010-04-26  6:24                 ` Brian Swetland
2010-04-26 13:28                   ` Randy Dunlap
2010-04-23  2:25     ` [linux-pm] [PATCH 2/9] PM: suspend_block: Add driver to access suspend blockers from user-space Matt Helsley
2010-04-23  3:54       ` Arve Hjønnevåg
2010-04-23  4:38       ` Greg KH
2010-04-23  8:43     ` Pavel Machek
2010-04-23 16:43       ` [linux-pm] " Alan Stern
2010-04-24  3:20         ` Arve Hjønnevåg
2010-04-24  5:55           ` Pavel Machek
2010-04-24 14:44             ` Alan Stern
2010-04-25 22:34               ` Arve Hjønnevåg
2010-04-26 19:25                 ` Alan Stern
2010-04-27  4:04                   ` Arve Hjønnevåg
2010-04-27 18:33                     ` Alan Stern
2010-04-27 22:03                       ` Rafael J. Wysocki
2010-04-27 23:22                         ` Arve Hjønnevåg
2010-04-24  1:53       ` tytso
2010-04-24  5:39         ` Pavel Machek
2010-04-23 16:33   ` [PATCH 1/9] PM: Add suspend block api Alan Stern
2010-04-23 16:45     ` [linux-pm] " Alan Stern
2010-04-24  2:15     ` Arve Hjønnevåg
2010-04-24  2:30       ` Alan Stern
2010-04-24  3:14         ` Arve Hjønnevåg
2010-04-23  4:39 ` [linux-pm] [PATCH 0/9] Suspend block api (version 4) Greg KH

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=4BD4E354.6010803@oracle.com \
    --to=randy.dunlap@oracle.com \
    --cc=arve@android.com \
    --cc=greg@kroah.com \
    --cc=len.brown@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@lists.linux-foundation.org \
    --cc=pavel@ucw.cz \
    --cc=rjw@sisk.pl \
    --cc=tytso@mit.edu \
    /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