public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@elte.hu>
To: Jiri Slaby <jirislaby@gmail.com>
Cc: Jiri Slaby <jslaby@suse.cz>,
	nhorman@tuxdriver.com, sfr@canb.auug.org.au,
	linux-kernel@vger.kernel.org, akpm@linux-foundation.org,
	marcin.slusarz@gmail.com, tglx@linutronix.de, mingo@redhat.com,
	hpa@zytor.com, torvalds@linux-foundation.org, oleg@redhat.com,
	Stephen Smalley <sds@tycho.nsa.gov>,
	Eric Paris <eparis@parisplace.org>,
	David Howells <dhowells@redhat.com>
Subject: Re: [PATCH v3 00/27] writable limits
Date: Sat, 28 Nov 2009 08:28:39 +0100	[thread overview]
Message-ID: <20091128072839.GA6689@elte.hu> (raw)
In-Reply-To: <4B1063A7.2030206@gmail.com>


* Jiri Slaby <jirislaby@gmail.com> wrote:

> Hi,
> 
> I broke the threading to not mess up with the long thread.
> 
> In this version I got rid of the rlim access_only ugliness.

Thanks Jiri - this series looks very clean already and the helpers make 
the various usage sites easier to understand as well.

One (very small) naming suggestion, please rename:

 rlim_get_cur()
 rlim_get_max()
 task_rlim_get_cur()
 task_rlim_get_max()

To a more natural sounding scheme like:

 rlimit()
 rlimit_max()
 task_rlimit()
 task_rlimit_max()

Reasons:

 - 'cur' is a misnomer that came a decade+ ago from an ABI and there's 
   no need to continue that bad tradition in helper functions. It can 
   also be confused with 'curr' which we often use for the current task.

 - 'rlimit' is general meme, plus there's no need to say it out aloud 
   that we 'get' it - rlimit() is obvious enough.

Beyond solving these issues it makes it shorter and more logical as 
well.

Thanks,

	Ingo

      reply	other threads:[~2009-11-28 11:10 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-11-27 23:05 [PATCH v3 01/27] SECURITY: selinux, fix update_rlimit_cpu parameter Jiri Slaby
2009-11-27 23:05 ` [PATCH v3 02/27] SECURITY: add task_struct to setrlimit Jiri Slaby
2009-11-27 23:05 ` [PATCH v3 03/27] core: add task_struct to update_rlimit_cpu Jiri Slaby
2009-11-27 23:05 ` [PATCH v3 04/27] sys_setrlimit: make sure ->rlim_max never grows Jiri Slaby
2009-11-27 23:05 ` [PATCH v3 05/27] core: split sys_setrlimit Jiri Slaby
2009-11-27 23:05 ` [PATCH v3 06/27] core: allow setrlimit to non-current tasks Jiri Slaby
2009-11-27 23:05 ` [PATCH v3 07/27] core: optimize setrlimit for current task Jiri Slaby
2009-11-27 23:05 ` [PATCH v3 08/27] FS: proc, switch limits reading to fops Jiri Slaby
2009-11-27 23:05 ` [PATCH v3 09/27] FS: proc, make limits writable Jiri Slaby
2009-11-27 23:05 ` [PATCH v3 10/27] core: do security check under task_lock Jiri Slaby
2009-11-27 23:05 ` [PATCH v3 11/27] core: rename setrlimit to do_setrlimit Jiri Slaby
2009-11-27 23:05 ` [PATCH v3 12/27] resource: move kernel functions inside __KERNEL__ Jiri Slaby
2009-11-27 23:05 ` [PATCH v3 13/27] core: posix-cpu-timers, cleanup rlimits usage Jiri Slaby
2009-11-27 23:05 ` [PATCH v3 14/27] resource: add helpers for fetching rlimits Jiri Slaby
2009-11-27 23:05 ` [PATCH v3 15/27] IA64: use helpers for rlimits Jiri Slaby
2009-11-27 23:05 ` [PATCH v3 16/27] PPC: " Jiri Slaby
2009-11-28  0:19   ` Benjamin Herrenschmidt
2009-11-28  8:47     ` Jiri Slaby
2009-11-28 21:16       ` Benjamin Herrenschmidt
2009-11-29 11:06         ` Stephen Rothwell
2009-11-27 23:05 ` [PATCH v3 17/27] S390: " Jiri Slaby
2009-11-27 23:05 ` [PATCH v3 18/27] SPARC: " Jiri Slaby
2009-11-27 23:05 ` [PATCH v3 19/27] X86: " Jiri Slaby
2009-11-27 23:06 ` [PATCH v3 20/27] FS: " Jiri Slaby
2009-11-27 23:06 ` [PATCH v3 21/27] MM: " Jiri Slaby
2009-11-27 23:06 ` [PATCH v3 22/27] core: " Jiri Slaby
2009-11-27 23:06 ` [PATCH v3 23/27] misc: " Jiri Slaby
2009-12-09 23:59   ` Roland Dreier
2009-11-27 23:06 ` [PATCH v3 24/27] core: implement getprlimit and setprlimit syscalls Jiri Slaby
2009-11-27 23:06 ` [PATCH v3 25/27] unistd: add __NR_[get|set]prlimit syscall numbers Jiri Slaby
2009-11-27 23:06 ` [PATCH v3 26/27] COMPAT: add get/put_compat_rlimit Jiri Slaby
2009-11-27 23:06 ` [PATCH v3 27/27] x86: add ia32 compat prlimit syscalls Jiri Slaby
2009-11-27 23:41 ` [PATCH v3 00/27] writable limits Jiri Slaby
2009-11-28  7:28   ` Ingo Molnar [this message]

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=20091128072839.GA6689@elte.hu \
    --to=mingo@elte.hu \
    --cc=akpm@linux-foundation.org \
    --cc=dhowells@redhat.com \
    --cc=eparis@parisplace.org \
    --cc=hpa@zytor.com \
    --cc=jirislaby@gmail.com \
    --cc=jslaby@suse.cz \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marcin.slusarz@gmail.com \
    --cc=mingo@redhat.com \
    --cc=nhorman@tuxdriver.com \
    --cc=oleg@redhat.com \
    --cc=sds@tycho.nsa.gov \
    --cc=sfr@canb.auug.org.au \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.org \
    /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