On Wed, Jan 28, 2015 at 05:20:08PM -0600, Tom Zanussi wrote: > On Wed, 2015-01-28 at 13:51 -0800, j...@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 <tom.zanu...@linux.intel.com> > > > > > > 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/