public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jiri Slaby <jslaby@suse.cz>
To: Chris Metcalf <cmetcalf@tilera.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
	Arnd Bergmann <arnd@arndb.de>,
	LKML <linux-kernel@vger.kernel.org>,
	Oleg Nesterov <oleg@redhat.com>,
	Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [GIT] writable_limits for 2.6.36
Date: Tue, 10 Aug 2010 18:43:01 +0200	[thread overview]
Message-ID: <4C618195.4000706@suse.cz> (raw)
In-Reply-To: <4C617C94.5010808@tilera.com>

On 08/10/2010 06:21 PM, Chris Metcalf wrote:
> On 8/10/2010 12:01 PM, Linus Torvalds wrote:
>> 2010/8/7 Jiri Slaby <jslaby@suse.cz>:
>>   
>>> please consider the following repository for 2.6.36. It introduces a new
>>> syscall for arch independent resource limits handling. It also adds a
>>> support for runtime limits changing. This feature is needed mostly by
>>> daemons servicing databases and similar service where limits are needed
>>> to be changed without services being restarted on production systems.
>>>     
>> Ok, so the code looks fine, and I don't have any real objections any
>> more. I don't know how much use this will get, but it doesn't appear
>> to be "wrong" in any way. So I was going to pull it.

Ok, thanks.

>> However, in the meantime we have commit 5360bd776f73 ("Fix up the
>> "generic" unistd.h ABI to be more useful") that clashes with it. Now,
>> the conflict is trivial to resolve, and I could do that easily - it's
>> not a technical problem. But that commit code comments say
>>
>>   + * Architectures may provide up to 16 syscalls of their own
>>   + * starting with this value.
>>   + */
>>   +#define __NR_arch_specific_syscall 244
>>
>> and the new writable rlimits syscall is obviously 244.
>>   
> 
> Jiri and I actually discussed this back on July 20th on LKML when it
> first conflicted in linux-next, and at the time he said he'd move
> prlimit64 to 261 in <asm-generic/unistd.h>.  It looks like what actually
> stuck in linux-next was different, however.  It's partly my fault for
> not following up on this.

I would do that if the tree reached linus's tree earlier, so that I
could rebase my tree on the top of that. Otherwise I couldn't do much
with that.

The resolving (merge) in -next is done by Stephen, so he probably
misunderstood us. (Oh, I could have a for-next branch where I would
merge your tree to solve the -next merging done by Stephen, but it
wouldn't solve the situation we got into now.)

thanks,
-- 
js
suse labs

  reply	other threads:[~2010-08-10 16:43 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-08-07 12:15 [GIT] writable_limits for 2.6.36 Jiri Slaby
2010-08-10 16:01 ` Linus Torvalds
2010-08-10 16:21   ` Chris Metcalf
2010-08-10 16:43     ` Jiri Slaby [this message]
2010-08-10 18:50     ` Arnd Bergmann
2010-08-10 19:12       ` Linus Torvalds
2010-08-10 19:43         ` Chris Metcalf
2010-08-10 21:44           ` Jiri Slaby
2010-08-11  2:39         ` Arnd Bergmann
2010-08-10 16:24   ` Linus Torvalds

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=4C618195.4000706@suse.cz \
    --to=jslaby@suse.cz \
    --cc=akpm@linux-foundation.org \
    --cc=arnd@arndb.de \
    --cc=cmetcalf@tilera.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=oleg@redhat.com \
    --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