From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1764494AbdEWPjq (ORCPT ); Tue, 23 May 2017 11:39:46 -0400 Received: from out01.mta.xmission.com ([166.70.13.231]:37256 "EHLO out01.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1758474AbdEWPjl (ORCPT ); Tue, 23 May 2017 11:39:41 -0400 From: ebiederm@xmission.com (Eric W. Biederman) To: David Howells Cc: trondmy@primarydata.com, mszeredi@redhat.com, linux-nfs@vger.kernel.org, jlayton@redhat.com, linux-kernel@vger.kernel.org, viro@zeniv.linux.org.uk, linux-fsdevel@vger.kernel.org, cgroups@vger.kernel.org References: <149547014649.10599.12025037906646164347.stgit@warthog.procyon.org.uk> Date: Tue, 23 May 2017 10:33:01 -0500 In-Reply-To: <149547014649.10599.12025037906646164347.stgit@warthog.procyon.org.uk> (David Howells's message of "Mon, 22 May 2017 17:22:26 +0100") Message-ID: <87mva3k2qa.fsf@xmission.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-XM-SPF: eid=1dDBuI-0003k9-Mm;;;mid=<87mva3k2qa.fsf@xmission.com>;;;hst=in01.mta.xmission.com;;;ip=97.121.81.159;;;frm=ebiederm@xmission.com;;;spf=neutral X-XM-AID: U2FsdGVkX1+ciRnxiioeWf1EB0HWf47sjJFl8MCsbs0= X-SA-Exim-Connect-IP: 97.121.81.159 X-SA-Exim-Mail-From: ebiederm@xmission.com X-Spam-Report: * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP * 0.0 TVD_RCVD_IP Message was received from an IP address * 1.5 XMNoVowels Alpha-numberic number with no vowels * 1.5 TR_Symld_Words too many words that have symbols inside * 0.0 T_TM2_M_HEADER_IN_MSG BODY: No description available. * 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% * [score: 0.5000] * -0.0 DCC_CHECK_NEGATIVE Not listed in DCC * [sa05 1397; Body=1 Fuz1=1 Fuz2=1] X-Spam-DCC: XMission; sa05 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: **;David Howells X-Spam-Relay-Country: X-Spam-Timing: total 5541 ms - load_scoreonly_sql: 0.34 (0.0%), signal_user_changed: 5 (0.1%), b_tie_ro: 3.3 (0.1%), parse: 0.75 (0.0%), extract_message_metadata: 10 (0.2%), get_uri_detail_list: 0.81 (0.0%), tests_pri_-1000: 6 (0.1%), tests_pri_-950: 1.16 (0.0%), tests_pri_-900: 0.98 (0.0%), tests_pri_-400: 16 (0.3%), check_bayes: 15 (0.3%), b_tokenize: 4.6 (0.1%), b_tok_get_all: 5 (0.1%), b_comp_prob: 1.69 (0.0%), b_tok_touch_all: 2.00 (0.0%), b_finish: 0.59 (0.0%), tests_pri_0: 109 (2.0%), check_dkim_signature: 0.54 (0.0%), check_dkim_adsp: 2.6 (0.0%), tests_pri_500: 5391 (97.3%), poll_dns_idle: 5383 (97.1%), rewrite_mail: 0.00 (0.0%) Subject: Re: [RFC][PATCH 0/9] Make containers kernel objects X-Spam-Flag: No X-SA-Exim-Version: 4.2.1 (built Thu, 05 May 2016 13:38:54 -0600) X-SA-Exim-Scanned: Yes (on in01.mta.xmission.com) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org David Howells writes: > Here are a set of patches to define a container object for the kernel and > to provide some methods to create and manipulate them. Just so this discussion has some clarity. Nacked-by: "Eric W. Biederman" As a user visible entity I see nothing this container data structure helps solve it only muddies the waters and makes things more brittle. Embracing the complexity of namespaces head on tends to mean all of the goofy scary semantic corner cases are visible from the first version of the design, and so developers can't take short cuts that result in buggy kernel code that persists for decades. I am rather tired of finding and fixing those. Eric From mboxrd@z Thu Jan 1 00:00:00 1970 From: ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org (Eric W. Biederman) Subject: Re: [RFC][PATCH 0/9] Make containers kernel objects Date: Tue, 23 May 2017 10:33:01 -0500 Message-ID: <87mva3k2qa.fsf@xmission.com> References: <149547014649.10599.12025037906646164347.stgit@warthog.procyon.org.uk> Mime-Version: 1.0 Return-path: In-Reply-To: <149547014649.10599.12025037906646164347.stgit-S6HVgzuS8uM4Awkfq6JHfwNdhmdF6hFW@public.gmane.org> (David Howells's message of "Mon, 22 May 2017 17:22:26 +0100") Sender: cgroups-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-ID: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: David Howells Cc: trondmy-7I+n7zu2hftEKMMhf/gKZA@public.gmane.org, mszeredi-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org, linux-nfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, jlayton-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, viro-RmSDqhL/yNMiFSDQTTA3OLVCufUGDwFn@public.gmane.org, linux-fsdevel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org David Howells writes: > Here are a set of patches to define a container object for the kernel and > to provide some methods to create and manipulate them. Just so this discussion has some clarity. Nacked-by: "Eric W. Biederman" As a user visible entity I see nothing this container data structure helps solve it only muddies the waters and makes things more brittle. Embracing the complexity of namespaces head on tends to mean all of the goofy scary semantic corner cases are visible from the first version of the design, and so developers can't take short cuts that result in buggy kernel code that persists for decades. I am rather tired of finding and fixing those. Eric