From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753651AbbAaXIz (ORCPT ); Sat, 31 Jan 2015 18:08:55 -0500 Received: from relay6-d.mail.gandi.net ([217.70.183.198]:59541 "EHLO relay6-d.mail.gandi.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751450AbbAaXIx (ORCPT ); Sat, 31 Jan 2015 18:08:53 -0500 X-Originating-IP: 50.43.58.154 Date: Sat, 31 Jan 2015 15:08:45 -0800 From: Josh Triplett To: Tom Zanussi Cc: Pavel Machek , linux-kernel@vger.kernel.org Subject: Re: [PATCH 05/10] drivers/char: Support compiling out /dev/zero Message-ID: <20150131230844.GA2809@thin> References: <79846ac644fe9103ef9b7cb0ab69e6f196f27853.1422035184.git.tom.zanussi@linux.intel.com> <20150128210751.GA14006@amd> <20150128215106.GA6338@cloud> <1422487208.6127.44.camel@picadillo> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1422487208.6127.44.camel@picadillo> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jan 28, 2015 at 05:20:08PM -0600, Tom Zanussi wrote: > On Wed, 2015-01-28 at 13:51 -0800, josh@joshtriplett.org wrote: > > On Wed, Jan 28, 2015 at 10:07:51PM +0100, Pavel Machek wrote: > > > On Fri 2015-01-23 12:37:11, Tom Zanussi wrote: > > > > Some embedded systems with tightly controlled userspace have no use > > > > for /dev/zero, and could benefit from the size savings gained by > > > > omitting it. Add a new EMBEDDED config option to disable it. > > > > > > > > bloat-o-meter (based on tinyconfig): > > > > > > > > add/remove: 0/3 grow/shrink: 0/1 up/down: 0/-391 (-391) > > > > function old new delta > > > > chr_dev_init 162 147 -15 > > > > mmap_zero 16 - -16 > > > > zero_fops 116 - -116 > > > > zero_bdi 244 - -244 > > > > > > > > Signed-off-by: Tom Zanussi > > > > > > I'm not sure that 400 bytes are worth additional Kconfig noise. .. and > > > pretty much everyone needs /dev/zero... > > > > Relatively few, actually, given MMAP_ANONYMOUS. Memory isn't allocated > > via an mmap of /dev/zero. It's useful for systems with shells that want > > to redirect from it or read from it, but less useful for environments > > with entirely compiled code. > > > > /dev/null is much more commonly needed, though there are still systems > > that won't need it (and can just disable read/writes on an fd entirely > > rather than duping /dev/null to that fd). > > For testing, I was able to boot my dev system (Ubuntu) into a usable > shell with networking with only /dev/null and /dev/urandom. A > restricted userspace could be made/verified to not touch /dev/null. And a carefully constructed system with narrower needs (rather than a general-purpose distribution) could avoid touching *any* files in /dev. > > That said, I'd be entirely in favor of consolidating many of these > > "miscellaneous character device" options into a couple of Kconfig > > options. It doesn't seem critical to *individually* control each of > > these files in /dev. > > I can easily create a small set of groupings instead - how about > something like: DEVMEM_RANDOM(/dev/random, /dev/urandom, getrandom()), > DEVMEM_MEM (/dev/mem, /dev/kmem, /dev/port), DEVMEM_RW > (/dev/null, /dev/zero), and DEVMEM_MISC (/dev/full, /dev/kmsg)? > > That cuts the number in half, from 8->4 (we still have a separate > DEVPORT and DEVKMEM regardless). I don't think it makes sense to group full and kmsg. I'd suggest giving kmsg its own option (which likely needs to depend on printk, since it doesn't make sense without a kernel message buffer), and putting null, zero, and full together. (Though full seems like the least useful of the lot.) > I can also get rid of DEVMEM_RANDOM entirely as mentioned in a previous > post, and not allow those to be disabled at all, which saves even more > on Kconfig noise. Please don't. > > Personally, I'm hoping that we eventually end up with a disableable > > CONFIG_CHAR similar to CONFIG_BLOCK. > > If we ditch DEVMEM_RANDOM i.e. make certain devices undisableable then > it seems CONFIG_CHAR wouldn't be possible either. An excellent reason not to ditch it, then. - Josh Triplett