[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20091128072839.GA6689@elte.hu>
Date: Sat, 28 Nov 2009 08:28:39 +0100
From: Ingo Molnar <mingo@...e.hu>
To: Jiri Slaby <jirislaby@...il.com>
Cc: Jiri Slaby <jslaby@...e.cz>, nhorman@...driver.com,
sfr@...b.auug.org.au, linux-kernel@...r.kernel.org,
akpm@...ux-foundation.org, marcin.slusarz@...il.com,
tglx@...utronix.de, mingo@...hat.com, hpa@...or.com,
torvalds@...ux-foundation.org, oleg@...hat.com,
Stephen Smalley <sds@...ho.nsa.gov>,
Eric Paris <eparis@...isplace.org>,
David Howells <dhowells@...hat.com>
Subject: Re: [PATCH v3 00/27] writable limits
* Jiri Slaby <jirislaby@...il.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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists