From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756532Ab2AXLzZ (ORCPT ); Tue, 24 Jan 2012 06:55:25 -0500 Received: from mail-bk0-f46.google.com ([209.85.214.46]:54230 "EHLO mail-bk0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756034Ab2AXLzY (ORCPT ); Tue, 24 Jan 2012 06:55:24 -0500 Date: Tue, 24 Jan 2012 15:51:04 +0400 From: Vasiliy Kulikov To: Alexey Dobriyan Cc: Kees Cook , linux-kernel@vger.kernel.org, Andrew Morton , Linus Torvalds , Randy Dunlap , Borislav Petkov , Dan Ballard , Jiri Kosina , Al Viro , Stephen Wilson , David Rientjes , Ingo Molnar , Peter Zijlstra , Eric Paris , "Serge E. Hallyn" , linux-doc@vger.kernel.org, kernel-hardening@lists.openwall.com Subject: Re: [PATCH v3] sysctl: control functionality of /proc/pid/mem Message-ID: <20120124115104.GA5743@albatros> References: <20120123212115.GA29641@www.outflux.net> <20120124110332.GA4770@albatros> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jan 24, 2012 at 13:12 +0200, Alexey Dobriyan wrote: > On 1/24/12, Vasiliy Kulikov wrote: > >> + .procname = "proc_pid_mem", > >> + .data = &sysctl_proc_pid_mem, > >> + .maxlen = sizeof(int), > >> + .mode = 0644, > >> + .proc_handler = proc_dointvec_minmax, > >> + .extra1 = &zero, > >> + .extra2 = &two, > >> + }, > > >E.g. moving all such stuff to some sysctl group, not bloating > > kernel.*. > > Ehh. > How bloat is measured in this case? Do we want to add such sort of sysctls "from time to time" when we consider one or another feature as deprecated? If yes, I'd group them somehow, e.g. by introducing subdirectory inside of kernel. Btw, kernel sysctl dir contains all sort of stuff which goes to "kernel" as if it is "etc". It already contains ftrace, perf, printk, scheduler, ipc. IMHO plain kernel hierarchy is not profitable in the long term. Thanks, -- Vasiliy Kulikov http://www.openwall.com - bringing security into open computing environments