lkml.org 
[lkml]   [2006]   [Jun]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: 2.6.18 -mm merge plans
Date
"Serge E. Hallyn" <serue@us.ibm.com> writes:

> Quoting Andrew Morton (akpm@osdl.org):
>> proc-sysctl-add-_proc_do_string-helper.patch
>> namespaces-add-nsproxy.patch
>> namespaces-add-nsproxy-dont-include-compileh.patch
>> namespaces-incorporate-fs-namespace-into-nsproxy.patch
>> namespaces-utsname-introduce-temporary-helpers.patch
>> namespaces-utsname-switch-to-using-uts-namespaces.patch
>> namespaces-utsname-switch-to-using-uts-namespaces-alpha-fix.patch
>> namespaces-utsname-switch-to-using-uts-namespaces-cleanup.patch
>> namespaces-utsname-use-init_utsname-when-appropriate.patch
>> namespaces-utsname-use-init_utsname-when-appropriate-cifs-update.patch
>> namespaces-utsname-implement-utsname-namespaces.patch
>> namespaces-utsname-implement-utsname-namespaces-export.patch
>> namespaces-utsname-implement-utsname-namespaces-dont-include-compileh.patch
>> namespaces-utsname-sysctl-hack.patch
>> namespaces-utsname-sysctl-hack-cleanup.patch
>> namespaces-utsname-sysctl-hack-cleanup-2.patch
>> namespaces-utsname-sysctl-hack-cleanup-2-fix.patch
>> namespaces-utsname-remove-system_utsname.patch
>> namespaces-utsname-implement-clone_newuts-flag.patch
>> uts-copy-nsproxy-only-when-needed.patch
>> # needed if git-klibc isn't there:
>> #namespaces-utsname-switch-to-using-uts-namespaces-klibc-bit.patch
>> #namespaces-utsname-use-init_utsname-when-appropriate-klibc-bit.patch
>> #namespaces-utsname-switch-to-using-uts-namespaces-klibc-bit-2.patch
>>
>> utsname virtualisation. This doesn't seem very pointful as a standalone
>> thing. That's a general problem with infrastructural work for a very
>> large new feature.
>>
>> So probably I'll continue to babysit these patches, unless someone can
>> identify a decent reason why mainline needs this work.
>>
>> I don't want to carry an ever-growing stream of OS-virtualisation
>> groundwork patches for ever and ever so if we're going to do this thing...
>> faster, please.

Ack. I agree we need to start moving faster.
I had a couple of distractions but I should be sending out some
relevant patches in a bit. The more we can get out for review
before kernel summit the better the conversation will be I suspect.

> Eric, Kirill, Dave, Hubertus,
>
> In the spirit of 'faster, please', does someone care to port and
> resubmit a pidspace patch?

I think I can get that one. Except for the very tail end though
most of my patches probably won't be directly pidspace patches.
I'm going to work on killing sys_sysctl a little before I
get to far into that. A pidspace is one of the most controversial
patches so it is a bit tricky.

> I'll do it if noone else wants to, just don't want to step on anyone's
> toes if you were already working on it.

If you want to help with the bare pid to struct pid conversion I
don't have any outstanding patches, and getting that done kills
some theoretical pid wrap around problems as well as laying the ground
work for a simple pidspace implementation.

Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2006-06-08 21:59    [W:0.294 / U:1.296 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site