All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paul Moore <paul.moore@hp.com>
To: Vesa-Matti J Kari <vmkari@cc.helsinki.fi>
Cc: Eric Paris <eparis@parisplace.org>,
	Stephen Smalley <sds@tycho.nsa.gov>,
	James Morris <jmorris@namei.org>,
	selinux@tycho.nsa.gov
Subject: Re: [patch] SELinux: trivial, unify iterator variable naming
Date: Mon, 21 Jul 2008 09:38:31 -0400	[thread overview]
Message-ID: <200807210938.31144.paul.moore@hp.com> (raw)
In-Reply-To: <Pine.LNX.4.64L.0807211546530.23634@ruuvi.it.helsinki.fi>

On Monday 21 July 2008 9:08:16 am Vesa-Matti J Kari wrote:
> Hello,
>
> On Mon, 21 Jul 2008, Paul Moore wrote:
> > The kernel is a very large piece of code, which is developed and
> > maintained by literally thousands of people.  While there are rules
> > and guidelines to help maintain consistency there will _always_ be
> > inconsistent style in the Linux Kernel.
>
> Sure. But is that really a valid argument to block the changes that
> attempt to bring *at least some* unity to the code?

I obviously thought so which is why I voted "NO".  Not all change is 
good, even if the intentions are correct.  All change brings risk and 
if there is not an advantage to offset that risk then all you are doing 
is adding risk into the system.  Risk of runtime bugs, risk of 
merging/porting bugs, etc.

I don't have a problem with fixing significant style problems in the 
code; I agreed with Eric's massive whitespace cleanup earlier this year 
and I think your patch to convert to '\0' NULL terminators is a good 
one.  However, I do draw the line at patches that only rename 
variables, especially the conversion of 'idx' to 'i'.

> I mean, what you are saying is analogous to the argument, "the world
> peace can never be achieved, therefore we should not bother to settle
> local issues either".

Please stick to the argument at hand and not some overblown analogue.

> I certainly don't intend to wade through the entire kernel. I just
> want to make some changes to one particular subsystem that I am
> interested in (SELinux), to make the reading experience more
> enjoyable to me and others, and, hopefully, to somewhat improve the
> code.

A few thoughts: others did not object to those variable names when the 
patches were proposed, or at any point prior to this thread, and no one 
besides you and I has commented on this thread.  This is a sign to me 
that the 'idx' variable name is not a significant distraction to the 
community.

Another thought, if you want to help improve the code, especially 
SELinux, I would encourage you to look at the ToDo lists:

 * http://www.selinuxproject.org/page/Kernel_Development#To_Do_List
 * http://www.selinuxproject.org/page/Userspace_Development

... and attempt to work on one of the issues on those lists.  I would be 
more than happy to help if you get stuck and need a hand.

-- 
paul moore
linux @ hp

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

  reply	other threads:[~2008-07-21 13:38 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-07-20 21:46 [patch] SELinux: trivial, unify iterator variable naming Vesa-Matti J Kari
2008-07-21  1:25 ` Paul Moore
2008-07-21  8:08   ` Vesa-Matti J Kari
2008-07-21 12:24     ` Paul Moore
2008-07-21 13:08       ` Vesa-Matti J Kari
2008-07-21 13:38         ` Paul Moore [this message]
2008-07-22 18:21           ` Vesa-Matti J Kari
2008-07-23  3:10             ` Paul Moore
2008-07-30  2:47           ` Russell Coker
2008-07-30 15:22             ` Paul Moore
2008-07-30 16:04               ` Vesa-Matti J Kari

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=200807210938.31144.paul.moore@hp.com \
    --to=paul.moore@hp.com \
    --cc=eparis@parisplace.org \
    --cc=jmorris@namei.org \
    --cc=sds@tycho.nsa.gov \
    --cc=selinux@tycho.nsa.gov \
    --cc=vmkari@cc.helsinki.fi \
    /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.