LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
* [PATCH 00/10] tinification: Make memory-access char devices optional
@ 2015-01-23 18:37 Tom Zanussi
  2015-01-23 18:37 ` [PATCH 01/10] drivers/char: Support compiling out memory-access char devices Tom Zanussi
                   ` (9 more replies)
  0 siblings, 10 replies; 19+ messages in thread
From: Tom Zanussi @ 2015-01-23 18:37 UTC (permalink / raw)
  To: josh; +Cc: linux-kernel, Tom Zanussi

This patchset adds a top-level config option, CONFIG_DEVMEM_BASE, and
a series of dependent options below it which allow various devices
such as /dev/mem, /dev/null, /dev/zero, /dev/random, etc. to be
disabled.  This allows embedded systems systems that don't need any or
all of those devices to save the kernel memory associated with those
devices.

It also adds a related option to disable the getrandom(2) syscall,
CONFIG_GETRANDOM_SYSCALL, which allows code shared between it and
/dev/*random to be compiled out as well.

Disabling of CONFIG_DEVMEM_BASE and its dependent options is only
available if CONFIG_EMBEDDED is enabled; normal systems will still
have everything enabled as usual.

bloat-o-meter shows a total 6k savings for a tinyconfig kernel with
all options disabled, and about 10k savings for the same thing but
using defconfig.

bloat-o-meter (based on tinyconfig):

add/remove: 0/55 grow/shrink: 1/3 up/down: 332/-6563 (-6231)
function                                     old     new   delta
extract_entropy                              114     446    +332
__print_once                                  13      12      -1
write_null                                     3       -      -3
read_null                                      3       -      -3
mix_pool_bytes                                17      14      -3
aio_read_null                                  3       -      -3
pipe_to_null                                   4       -      -4
mem_class                                      4       -      -4
write_full                                     6       -      -6
devkmsg_release                               15       -     -15
random_fasync                                 16       -     -16
mmap_zero                                     16       -     -16
aio_write_null                                18       -     -18
open_port                                     19       -     -19
random_read                                   20       -     -20
splice_write_null                             24       -     -24
null_lseek                                    25       -     -25
mmap_mem_ops                                  32       -     -32
mem_devnode                                   35       -     -35
mmap_kmem                                     37       -     -37
random_write                                  42       -     -42
xfer_secondary_pool                           60       -     -60
write_pool                                    82       -     -82
random_poll                                   83       -     -83
read_iter_zero                                95       -     -95
urandom_read                                  96       -     -96
memory_open                                   96       -     -96
devkmsg_poll                                  97       -     -97
read_port                                     98       -     -98
mmap_mem                                     103       -    -103
devkmsg_open                                 112       -    -112
write_port                                   116       -    -116
zero_fops                                    120       -    -120
urandom_fops                                 120       -    -120
random_fops                                  120       -    -120
port_fops                                    120       -    -120
null_fops                                    120       -    -120
memory_fops                                  120       -    -120
mem_fops                                     120       -    -120
kmsg_fops                                    120       -    -120
kmem_fops                                    120       -    -120
full_fops                                    120       -    -120
memory_lseek                                 122       -    -122
devkmsg_llseek                               144       -    -144
chr_dev_init                                 162       3    -159
read_mem                                     162       -    -162
extract_buf                                  164       -    -164
_random_read.part                            173       -    -173
account                                      181       -    -181
write_mem                                    184       -    -184
devlist                                      192       -    -192
extract_entropy_user                         197       -    -197
devkmsg_write                                209       -    -209
sys_getrandom                                211       -    -211
zero_bdi                                     244       -    -244
read_kmem                                    290       -    -290
random_ioctl                                 319       -    -319
write_kmem                                   349       -    -349
devkmsg_read                                 699       -    -699


The following changes since commit 5eb11d6b3f55eb4d28c51ea7f641c0e5e255a70f:

  Merge tag 'sound-3.19-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound (2015-01-21 20:37:25 +1200)

are available in the git repository at:

  git://git.yoctoproject.org/linux-yocto-contrib.git tzanussi/devmem-tinification-v1
  http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto-contrib/log/?h=tzanussi/devmem-tinification-v1

Tom Zanussi (10):
  drivers/char: Support compiling out memory-access char devices
  drivers/char: Support compiling out /dev/mem
  drivers/char: Support compiling out /dev/port
  drivers/char: Support compiling out /dev/null
  drivers/char: Support compiling out /dev/zero
  drivers/char: Support compiling out /dev/full
  drivers/char: Support compiling out /dev/random
  drivers/char: Support compiling out /dev/urandom
  drivers/char: Support compiling out /dev/kmsg
  drivers/char: Support compiling out the getrandom(2) syscall

 arch/x86/Kconfig.debug |   1 +
 drivers/char/Kconfig   | 109 ++++++++++++++++++++++++++++++++++++++++++++++++-
 drivers/char/mem.c     |  83 +++++++++++++++++++++++++++----------
 drivers/char/random.c  |  24 ++++++++---
 kernel/printk/printk.c |   2 +
 kernel/sys_ni.c        |   1 +
 6 files changed, 192 insertions(+), 28 deletions(-)

-- 
1.9.3


^ permalink raw reply	[flat|nested] 19+ messages in thread

* [PATCH 01/10] drivers/char: Support compiling out memory-access char devices
  2015-01-23 18:37 [PATCH 00/10] tinification: Make memory-access char devices optional Tom Zanussi
@ 2015-01-23 18:37 ` Tom Zanussi
  2015-01-23 18:37 ` [PATCH 02/10] drivers/char: Support compiling out /dev/mem Tom Zanussi
                   ` (8 subsequent siblings)
  9 siblings, 0 replies; 19+ messages in thread
From: Tom Zanussi @ 2015-01-23 18:37 UTC (permalink / raw)
  To: josh; +Cc: linux-kernel, Tom Zanussi

Many embedded systems can get by without the complete set of
memory-access char devices: /dev/mem, /dev/kmem, /dev/zero, /dev/null,
/dev/full, /dev/random, /dev/urandom, /dev/port, and /dev/kmsg.

Omitting them all can be accomplished by disabling DEVMEM_BASE, a new
EMBEDDED config option.

If DEVMEM_BASE is enabled, each of those devices can still be enabled
individually.

bloat-o-meter (based on tinyconfig):

add/remove: 0/51 grow/shrink: 2/1 up/down: 313/-5820 (-5507)
function                                     old     new   delta
sys_getrandom                                211     432    +221
do_syslog                                   1027    1119     +92
write_null                                     3       -      -3
read_null                                      3       -      -3
aio_read_null                                  3       -      -3
pipe_to_null                                   4       -      -4
mem_class                                      4       -      -4
write_full                                     6       -      -6
devkmsg_release                               15       -     -15
random_fasync                                 16       -     -16
mmap_zero                                     16       -     -16
aio_write_null                                18       -     -18
open_port                                     19       -     -19
random_read                                   20       -     -20
splice_write_null                             24       -     -24
null_lseek                                    25       -     -25
mmap_mem_ops                                  32       -     -32
mem_devnode                                   35       -     -35
mmap_kmem                                     37       -     -37
random_write                                  42       -     -42
write_pool                                    82       -     -82
random_poll                                   83       -     -83
read_iter_zero                                95       -     -95
urandom_read                                  96       -     -96
memory_open                                   96       -     -96
devkmsg_poll                                  97       -     -97
read_port                                     98       -     -98
mmap_mem                                     103       -    -103
devkmsg_open                                 112       -    -112
check_syslog_permissions                     114       -    -114
zero_fops                                    116       -    -116
write_port                                   116       -    -116
urandom_fops                                 116       -    -116
random_fops                                  116       -    -116
port_fops                                    116       -    -116
null_fops                                    116       -    -116
memory_fops                                  116       -    -116
mem_fops                                     116       -    -116
kmsg_fops                                    116       -    -116
kmem_fops                                    116       -    -116
full_fops                                    116       -    -116
memory_lseek                                 122       -    -122
devkmsg_llseek                               144       -    -144
chr_dev_init                                 162       3    -159
read_mem                                     162       -    -162
_random_read.part                            173       -    -173
write_mem                                    184       -    -184
devlist                                      192       -    -192
devkmsg_write                                209       -    -209
zero_bdi                                     244       -    -244
read_kmem                                    290       -    -290
random_ioctl                                 319       -    -319
write_kmem                                   349       -    -349
devkmsg_read                                 699       -    -699

Signed-off-by: Tom Zanussi <tom.zanussi@linux.intel.com>
---
 arch/x86/Kconfig.debug |  1 +
 drivers/char/Kconfig   | 12 ++++++++++++
 drivers/char/mem.c     |  7 +++++++
 3 files changed, 20 insertions(+)

diff --git a/arch/x86/Kconfig.debug b/arch/x86/Kconfig.debug
index 61bd2ad..34a781a 100644
--- a/arch/x86/Kconfig.debug
+++ b/arch/x86/Kconfig.debug
@@ -7,6 +7,7 @@ source "lib/Kconfig.debug"
 
 config STRICT_DEVMEM
 	bool "Filter access to /dev/mem"
+	depends on DEVMEM_BASE
 	---help---
 	  If this option is disabled, you allow userspace (root) access to all
 	  of memory, including kernel and userspace memory. Accidental
diff --git a/drivers/char/Kconfig b/drivers/char/Kconfig
index efefd12..7a8204a 100644
--- a/drivers/char/Kconfig
+++ b/drivers/char/Kconfig
@@ -6,8 +6,19 @@ menu "Character devices"
 
 source "drivers/tty/Kconfig"
 
+config DEVMEM_BASE
+	bool "Base support for memory-access char devices" if EMBEDDED
+	default y
+	help
+	  Say Y here if you want to support the various character
+	  devices used to access memory, such as /dev/mem, /dev/null,
+	  /dev/zero, /dev/random, etc.  Many embedded systems can get
+	  by without these devices; doing so will save memory.  When
+	  in doubt, say "Y".
+
 config DEVKMEM
 	bool "/dev/kmem virtual device support"
+	depends on DEVMEM_BASE
 	default y
 	help
 	  Say Y here if you want to support the /dev/kmem device. The
@@ -577,6 +588,7 @@ config DEVPORT
 	bool
 	depends on !M68K
 	depends on ISA || PCI
+	depends on DEVMEM_BASE
 	default y
 
 source "drivers/s390/char/Kconfig"
diff --git a/drivers/char/mem.c b/drivers/char/mem.c
index 4c58333..c141c0f 100644
--- a/drivers/char/mem.c
+++ b/drivers/char/mem.c
@@ -34,6 +34,7 @@
 # include <linux/efi.h>
 #endif
 
+#ifdef CONFIG_DEVMEM_BASE
 #define DEVPORT_MINOR	4
 
 static inline unsigned long size_inside_page(unsigned long start,
@@ -876,5 +877,11 @@ static int __init chr_dev_init(void)
 
 	return tty_init();
 }
+#else
+static int __init chr_dev_init(void)
+{
+	return tty_init();
+}
+#endif /* CONFIG_DEVMEM_BASE */
 
 fs_initcall(chr_dev_init);
-- 
1.9.3


^ permalink raw reply	[flat|nested] 19+ messages in thread

* [PATCH 02/10] drivers/char: Support compiling out /dev/mem
  2015-01-23 18:37 [PATCH 00/10] tinification: Make memory-access char devices optional Tom Zanussi
  2015-01-23 18:37 ` [PATCH 01/10] drivers/char: Support compiling out memory-access char devices Tom Zanussi
@ 2015-01-23 18:37 ` Tom Zanussi
  2015-01-23 18:37 ` [PATCH 03/10] drivers/char: Support compiling out /dev/port Tom Zanussi
                   ` (7 subsequent siblings)
  9 siblings, 0 replies; 19+ messages in thread
From: Tom Zanussi @ 2015-01-23 18:37 UTC (permalink / raw)
  To: josh; +Cc: linux-kernel, Tom Zanussi

Most embedded systems have no use for /dev/mem, and omitting it saves
space.  Add a new EMBEDDED config option to disable it.

mmap_mem() is shared between /dev/mem and /dev/kmem; making it
__maybe_unused prevents it from emitting warnings if both devices are
compiled out, while avoiding ugly compound ifdefs.

Also, STRICT_DEVMEM can now be refined to depend on DEVMEM rather than
the big hammer, DEVMEM_BASE.

bloat-o-meter (based on tinyconfig):

add/remove: 0/4 grow/shrink: 1/0 up/down: 96/-565 (-469)
function                                     old     new   delta
mmap_kmem                                     37     133     +96
mmap_mem                                     103       -    -103
mem_fops                                     116       -    -116
read_mem                                     162       -    -162
write_mem                                    184       -    -184

Here we see mmap_mem inlined in mmap_kmem and mmap_mem going away.

bloat-o-meter showing only CONFIG_DEVKMEM off:

add/remove: 0/4 grow/shrink: 0/0 up/down: 0/-792 (-792)
function                                     old     new   delta
mmap_kmem                                     37       -     -37
kmem_fops                                    116       -    -116
read_kmem                                    290       -    -290
write_kmem                                   349       -    -349

bloat-o-meter showing the difference between only CONFIG_DEVKMEM off
and both CONFIG_DEVKMEM and CONFIG_DEVMEM off:

add/remove: 0/5 grow/shrink: 0/0 up/down: 0/-597 (-597)
function                                     old     new   delta
mmap_mem_ops                                  32       -     -32
mmap_mem                                     103       -    -103
mem_fops                                     116       -    -116
read_mem                                     162       -    -162
write_mem                                    184       -    -184

Here we see mmap_mem going away as before, but also not being inlined
by mmap_kmem because that's gone, and mmap_mem_ops goes away as well,
because it's not being used by even an inlined mmap_mem.

Signed-off-by: Tom Zanussi <tom.zanussi@linux.intel.com>
---
 arch/x86/Kconfig.debug |  2 +-
 drivers/char/Kconfig   | 10 ++++++++++
 drivers/char/mem.c     |  9 ++++++++-
 3 files changed, 19 insertions(+), 2 deletions(-)

diff --git a/arch/x86/Kconfig.debug b/arch/x86/Kconfig.debug
index 34a781a..39afd1c 100644
--- a/arch/x86/Kconfig.debug
+++ b/arch/x86/Kconfig.debug
@@ -7,7 +7,7 @@ source "lib/Kconfig.debug"
 
 config STRICT_DEVMEM
 	bool "Filter access to /dev/mem"
-	depends on DEVMEM_BASE
+	depends on DEVMEM
 	---help---
 	  If this option is disabled, you allow userspace (root) access to all
 	  of memory, including kernel and userspace memory. Accidental
diff --git a/drivers/char/Kconfig b/drivers/char/Kconfig
index 7a8204a..73e2bb8 100644
--- a/drivers/char/Kconfig
+++ b/drivers/char/Kconfig
@@ -26,6 +26,16 @@ config DEVKMEM
 	  kind of kernel debugging operations.
 	  When in doubt, say "N".
 
+config DEVMEM
+	bool "/dev/mem virtual device support" if EMBEDDED
+	depends on DEVMEM_BASE
+	default y
+	help
+	  Say Y here if you want to support the /dev/mem device. The
+	  /dev/mem device is used mainly by X and dosemu, and can be
+	  disabled on systems that will never use either, such as many
+	  embedded systems.  When in doubt, say "Y".
+
 config SGI_SNSC
 	bool "SGI Altix system controller communication support"
 	depends on (IA64_SGI_SN2 || IA64_GENERIC)
diff --git a/drivers/char/mem.c b/drivers/char/mem.c
index c141c0f..9b7b04e 100644
--- a/drivers/char/mem.c
+++ b/drivers/char/mem.c
@@ -92,6 +92,7 @@ void __weak unxlate_dev_mem_ptr(phys_addr_t phys, void *addr)
 }
 #endif
 
+#ifdef CONFIG_DEVMEM
 /*
  * This funcion reads the *physical* memory. The f_pos points directly to the
  * memory location.
@@ -220,6 +221,7 @@ static ssize_t write_mem(struct file *file, const char __user *buf,
 	*ppos += written;
 	return written;
 }
+#endif
 
 int __weak phys_mem_access_prot_allowed(struct file *file,
 	unsigned long pfn, unsigned long size, pgprot_t *vma_prot)
@@ -308,7 +310,8 @@ static const struct vm_operations_struct mmap_mem_ops = {
 #endif
 };
 
-static int mmap_mem(struct file *file, struct vm_area_struct *vma)
+static int __maybe_unused mmap_mem(struct file *file,
+				   struct vm_area_struct *vma)
 {
 	size_t size = vma->vm_end - vma->vm_start;
 
@@ -716,6 +719,7 @@ static int open_port(struct inode *inode, struct file *filp)
 #define open_mem	open_port
 #define open_kmem	open_mem
 
+#ifdef CONFIG_DEVMEM
 static const struct file_operations mem_fops = {
 	.llseek		= memory_lseek,
 	.read		= read_mem,
@@ -724,6 +728,7 @@ static const struct file_operations mem_fops = {
 	.open		= open_mem,
 	.get_unmapped_area = get_unmapped_area_mem,
 };
+#endif
 
 #ifdef CONFIG_DEVKMEM
 static const struct file_operations kmem_fops = {
@@ -786,7 +791,9 @@ static const struct memdev {
 	const struct file_operations *fops;
 	struct backing_dev_info *dev_info;
 } devlist[] = {
+#ifdef CONFIG_DEVMEM
 	 [1] = { "mem", 0, &mem_fops, &directly_mappable_cdev_bdi },
+#endif
 #ifdef CONFIG_DEVKMEM
 	 [2] = { "kmem", 0, &kmem_fops, &directly_mappable_cdev_bdi },
 #endif
-- 
1.9.3


^ permalink raw reply	[flat|nested] 19+ messages in thread

* [PATCH 03/10] drivers/char: Support compiling out /dev/port
  2015-01-23 18:37 [PATCH 00/10] tinification: Make memory-access char devices optional Tom Zanussi
  2015-01-23 18:37 ` [PATCH 01/10] drivers/char: Support compiling out memory-access char devices Tom Zanussi
  2015-01-23 18:37 ` [PATCH 02/10] drivers/char: Support compiling out /dev/mem Tom Zanussi
@ 2015-01-23 18:37 ` Tom Zanussi
  2015-01-23 18:37 ` [PATCH 04/10] drivers/char: Support compiling out /dev/null Tom Zanussi
                   ` (6 subsequent siblings)
  9 siblings, 0 replies; 19+ messages in thread
From: Tom Zanussi @ 2015-01-23 18:37 UTC (permalink / raw)
  To: josh; +Cc: linux-kernel, Tom Zanussi

There's already a CONFIG_DEVPORT option, but it isn't accessible to
users.  Give it some menu and help text and allow it to be toggled
off.

Aside from giving embedded systems that don't need it the ability to
turn it off, it also allows the code shared between it and other
options to be compiled out (open_port() shared with /dev/mem, and
memory_lseek() shared with /dev/mem and /dev/kmem; both functions have
been changed to __maybe_unused for when all of the above are compiled
out).

bloat-o-meter (based on tinyconfig):

add/remove: 0/3 grow/shrink: 0/0 up/down: 0/-330 (-330)
function                                     old     new   delta
read_port                                     98       -     -98
write_port                                   116       -    -116
port_fops                                    116       -    -116

bloat-o-meter showing the difference between both CONFIG_DEVKMEM and
CONFIG_DEVMEM off and that plus CONFIG_DEVPORT off:

add/remove: 0/5 grow/shrink: 0/0 up/down: 0/-471 (-471)
function                                     old     new   delta
open_port                                     19       -     -19
read_port                                     98       -     -98
write_port                                   116       -    -116
port_fops                                    116       -    -116
memory_lseek                                 122       -    -122

So with all three configured out, we see the mutually shared open_port
and memory_lseek drop out.

Signed-off-by: Tom Zanussi <tom.zanussi@linux.intel.com>
---
 drivers/char/Kconfig | 7 ++++++-
 drivers/char/mem.c   | 5 +++--
 2 files changed, 9 insertions(+), 3 deletions(-)

diff --git a/drivers/char/Kconfig b/drivers/char/Kconfig
index 73e2bb8..5a6c060 100644
--- a/drivers/char/Kconfig
+++ b/drivers/char/Kconfig
@@ -595,11 +595,16 @@ config TELCLOCK
 	  controlling the behavior of this hardware.
 
 config DEVPORT
-	bool
+	bool "/dev/port virtual device support"
 	depends on !M68K
 	depends on ISA || PCI
 	depends on DEVMEM_BASE
 	default y
+	help
+	  Say Y here if you want to support the /dev/port device. The
+	  /dev/port device is a character device that allows userspace
+	  access to I/O ports, which may be needed by some programs.
+	  When in doubt, say "Y".
 
 source "drivers/s390/char/Kconfig"
 
diff --git a/drivers/char/mem.c b/drivers/char/mem.c
index 9b7b04e..5944d87 100644
--- a/drivers/char/mem.c
+++ b/drivers/char/mem.c
@@ -682,7 +682,8 @@ static loff_t null_lseek(struct file *file, loff_t offset, int orig)
  * also note that seeking relative to the "end of file" isn't supported:
  * it has no meaning, so it returns -EINVAL.
  */
-static loff_t memory_lseek(struct file *file, loff_t offset, int orig)
+static loff_t __maybe_unused memory_lseek(struct file *file, loff_t offset,
+					  int orig)
 {
 	loff_t ret;
 
@@ -707,7 +708,7 @@ static loff_t memory_lseek(struct file *file, loff_t offset, int orig)
 	return ret;
 }
 
-static int open_port(struct inode *inode, struct file *filp)
+static int __maybe_unused open_port(struct inode *inode, struct file *filp)
 {
 	return capable(CAP_SYS_RAWIO) ? 0 : -EPERM;
 }
-- 
1.9.3


^ permalink raw reply	[flat|nested] 19+ messages in thread

* [PATCH 04/10] drivers/char: Support compiling out /dev/null
  2015-01-23 18:37 [PATCH 00/10] tinification: Make memory-access char devices optional Tom Zanussi
                   ` (2 preceding siblings ...)
  2015-01-23 18:37 ` [PATCH 03/10] drivers/char: Support compiling out /dev/port Tom Zanussi
@ 2015-01-23 18:37 ` Tom Zanussi
  2015-01-23 18:37 ` [PATCH 05/10] drivers/char: Support compiling out /dev/zero Tom Zanussi
                   ` (5 subsequent siblings)
  9 siblings, 0 replies; 19+ messages in thread
From: Tom Zanussi @ 2015-01-23 18:37 UTC (permalink / raw)
  To: josh; +Cc: linux-kernel, Tom Zanussi

Some embedded systems with tightly controlled userspace have no use
for /dev/null, and could benefit from the size savings gained by
omitting it.  Add a new EMBEDDED config option to disable it.

write_null() and aio_write_null() are shared between /dev/null and
/dev/zero; making it __maybe_unused prevents them from emitting
warnings if both devices are compiled out, while avoiding ugly
compound ifdefs.  Similarly for null_lseek, shared between /dev/null,
/dev/zero, and /dev/full.

bloat-o-meter (based on tinyconfig):

add/remove: 0/5 grow/shrink: 0/0 up/down: 0/-150 (-150)
function                                     old     new   delta
read_null                                      3       -      -3
aio_read_null                                  3       -      -3
pipe_to_null                                   4       -      -4
splice_write_null                             24       -     -24
null_fops                                    116       -    -116

bloat-o-meter showing the difference between only CONFIG_DEVZERO and
CONFIG_DEVFULL off and both those plus CONFIG_DEVNULL off:

add/remove: 0/8 grow/shrink: 0/0 up/down: 0/-196 (-196)
function                                     old     new   delta
write_null                                     3       -      -3
read_null                                      3       -      -3
aio_read_null                                  3       -      -3
pipe_to_null                                   4       -      -4
aio_write_null                                18       -     -18
splice_write_null                             24       -     -24
null_lseek                                    25       -     -25
null_fops                                    116       -    -116

So with DEVZERO also configured out, we see the shared write_null,
aio_write_null, and null_lseek drop out.

Signed-off-by: Tom Zanussi <tom.zanussi@linux.intel.com>
---
 drivers/char/Kconfig | 10 ++++++++++
 drivers/char/mem.c   | 35 ++++++++++++++++++++++-------------
 2 files changed, 32 insertions(+), 13 deletions(-)

diff --git a/drivers/char/Kconfig b/drivers/char/Kconfig
index 5a6c060..17f6ddf 100644
--- a/drivers/char/Kconfig
+++ b/drivers/char/Kconfig
@@ -36,6 +36,16 @@ config DEVMEM
 	  disabled on systems that will never use either, such as many
 	  embedded systems.  When in doubt, say "Y".
 
+config DEVNULL
+	bool "/dev/null virtual device support" if EMBEDDED
+	depends on DEVMEM_BASE
+	default y
+	help
+	  Say Y here if you want to support the /dev/null device. The
+	  /dev/null device is used by many programs, but some embedded
+	  systems with strictly controlled userspace may not need it.
+	  When in doubt, say "Y".
+
 config SGI_SNSC
 	bool "SGI Altix system controller communication support"
 	depends on (IA64_SGI_SN2 || IA64_GENERIC)
diff --git a/drivers/char/mem.c b/drivers/char/mem.c
index 5944d87..25d6f5b 100644
--- a/drivers/char/mem.c
+++ b/drivers/char/mem.c
@@ -593,30 +593,19 @@ static ssize_t write_port(struct file *file, const char __user *buf,
 }
 #endif
 
+#ifdef CONFIG_DEVNULL
 static ssize_t read_null(struct file *file, char __user *buf,
 			 size_t count, loff_t *ppos)
 {
 	return 0;
 }
 
-static ssize_t write_null(struct file *file, const char __user *buf,
-			  size_t count, loff_t *ppos)
-{
-	return count;
-}
-
 static ssize_t aio_read_null(struct kiocb *iocb, const struct iovec *iov,
 			     unsigned long nr_segs, loff_t pos)
 {
 	return 0;
 }
 
-static ssize_t aio_write_null(struct kiocb *iocb, const struct iovec *iov,
-			      unsigned long nr_segs, loff_t pos)
-{
-	return iov_length(iov, nr_segs);
-}
-
 static int pipe_to_null(struct pipe_inode_info *info, struct pipe_buffer *buf,
 			struct splice_desc *sd)
 {
@@ -628,6 +617,21 @@ static ssize_t splice_write_null(struct pipe_inode_info *pipe, struct file *out,
 {
 	return splice_from_pipe(pipe, out, ppos, len, flags, pipe_to_null);
 }
+#endif
+
+static ssize_t __maybe_unused write_null(struct file *file,
+					 const char __user *buf,
+					 size_t count, loff_t *ppos)
+{
+	return count;
+}
+
+static ssize_t __maybe_unused aio_write_null(struct kiocb *iocb,
+					     const struct iovec *iov,
+					     unsigned long nr_segs, loff_t pos)
+{
+	return iov_length(iov, nr_segs);
+}
 
 static ssize_t read_iter_zero(struct kiocb *iocb, struct iov_iter *iter)
 {
@@ -669,7 +673,8 @@ static ssize_t write_full(struct file *file, const char __user *buf,
  * can fopen() both devices with "a" now.  This was previously impossible.
  * -- SRB.
  */
-static loff_t null_lseek(struct file *file, loff_t offset, int orig)
+static loff_t __maybe_unused null_lseek(struct file *file, loff_t offset,
+					int orig)
 {
 	return file->f_pos = 0;
 }
@@ -742,6 +747,7 @@ static const struct file_operations kmem_fops = {
 };
 #endif
 
+#ifdef CONFIG_DEVNULL
 static const struct file_operations null_fops = {
 	.llseek		= null_lseek,
 	.read		= read_null,
@@ -750,6 +756,7 @@ static const struct file_operations null_fops = {
 	.aio_write	= aio_write_null,
 	.splice_write	= splice_write_null,
 };
+#endif
 
 #ifdef CONFIG_DEVPORT
 static const struct file_operations port_fops = {
@@ -798,7 +805,9 @@ static const struct memdev {
 #ifdef CONFIG_DEVKMEM
 	 [2] = { "kmem", 0, &kmem_fops, &directly_mappable_cdev_bdi },
 #endif
+#ifdef CONFIG_DEVNULL
 	 [3] = { "null", 0666, &null_fops, NULL },
+#endif
 #ifdef CONFIG_DEVPORT
 	 [4] = { "port", 0, &port_fops, NULL },
 #endif
-- 
1.9.3


^ permalink raw reply	[flat|nested] 19+ messages in thread

* [PATCH 05/10] drivers/char: Support compiling out /dev/zero
  2015-01-23 18:37 [PATCH 00/10] tinification: Make memory-access char devices optional Tom Zanussi
                   ` (3 preceding siblings ...)
  2015-01-23 18:37 ` [PATCH 04/10] drivers/char: Support compiling out /dev/null Tom Zanussi
@ 2015-01-23 18:37 ` Tom Zanussi
  2015-01-28 21:07   ` Pavel Machek
  2015-01-23 18:37 ` [PATCH 06/10] drivers/char: Support compiling out /dev/full Tom Zanussi
                   ` (4 subsequent siblings)
  9 siblings, 1 reply; 19+ messages in thread
From: Tom Zanussi @ 2015-01-23 18:37 UTC (permalink / raw)
  To: josh; +Cc: linux-kernel, Tom Zanussi

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.zanussi@linux.intel.com>
---
 drivers/char/Kconfig | 10 ++++++++++
 drivers/char/mem.c   | 15 +++++++++++----
 2 files changed, 21 insertions(+), 4 deletions(-)

diff --git a/drivers/char/Kconfig b/drivers/char/Kconfig
index 17f6ddf..00f9b8a 100644
--- a/drivers/char/Kconfig
+++ b/drivers/char/Kconfig
@@ -46,6 +46,16 @@ config DEVNULL
 	  systems with strictly controlled userspace may not need it.
 	  When in doubt, say "Y".
 
+config DEVZERO
+	bool "/dev/zero virtual device support" if EMBEDDED
+	depends on DEVMEM_BASE
+	default y
+	help
+	  Say Y here if you want to support the /dev/zero device. The
+	  /dev/zero device is used by many programs, but some embedded
+	  systems with strictly controlled userspace may not need it.
+	  When in doubt, say "Y".
+
 config SGI_SNSC
 	bool "SGI Altix system controller communication support"
 	depends on (IA64_SGI_SN2 || IA64_GENERIC)
diff --git a/drivers/char/mem.c b/drivers/char/mem.c
index 25d6f5b..96f7a9d 100644
--- a/drivers/char/mem.c
+++ b/drivers/char/mem.c
@@ -633,7 +633,8 @@ static ssize_t __maybe_unused aio_write_null(struct kiocb *iocb,
 	return iov_length(iov, nr_segs);
 }
 
-static ssize_t read_iter_zero(struct kiocb *iocb, struct iov_iter *iter)
+static ssize_t __maybe_unused read_iter_zero(struct kiocb *iocb,
+					     struct iov_iter *iter)
 {
 	size_t written = 0;
 
@@ -652,6 +653,7 @@ static ssize_t read_iter_zero(struct kiocb *iocb, struct iov_iter *iter)
 	return written;
 }
 
+#ifdef CONFIG_DEVZERO
 static int mmap_zero(struct file *file, struct vm_area_struct *vma)
 {
 #ifndef CONFIG_MMU
@@ -661,6 +663,7 @@ static int mmap_zero(struct file *file, struct vm_area_struct *vma)
 		return shmem_zero_setup(vma);
 	return 0;
 }
+#endif
 
 static ssize_t write_full(struct file *file, const char __user *buf,
 			  size_t count, loff_t *ppos)
@@ -767,6 +770,7 @@ static const struct file_operations port_fops = {
 };
 #endif
 
+#ifdef CONFIG_DEVZERO
 static const struct file_operations zero_fops = {
 	.llseek		= zero_lseek,
 	.read		= new_sync_read,
@@ -785,6 +789,7 @@ static struct backing_dev_info zero_bdi = {
 	.name		= "char/mem",
 	.capabilities	= BDI_CAP_MAP_COPY | BDI_CAP_NO_ACCT_AND_WRITEBACK,
 };
+#endif
 
 static const struct file_operations full_fops = {
 	.llseek		= full_lseek,
@@ -811,7 +816,9 @@ static const struct memdev {
 #ifdef CONFIG_DEVPORT
 	 [4] = { "port", 0, &port_fops, NULL },
 #endif
+#ifdef CONFIG_DEVZERO
 	 [5] = { "zero", 0666, &zero_fops, &zero_bdi },
+#endif
 	 [7] = { "full", 0666, &full_fops, NULL },
 	 [8] = { "random", 0666, &random_fops, NULL },
 	 [9] = { "urandom", 0666, &urandom_fops, NULL },
@@ -864,12 +871,12 @@ static struct class *mem_class;
 static int __init chr_dev_init(void)
 {
 	int minor;
-	int err;
 
-	err = bdi_init(&zero_bdi);
+#ifdef CONFIG_DEVZERO
+	int err = bdi_init(&zero_bdi);
 	if (err)
 		return err;
-
+#endif
 	if (register_chrdev(MEM_MAJOR, "mem", &memory_fops))
 		printk("unable to get major %d for memory devs\n", MEM_MAJOR);
 
-- 
1.9.3


^ permalink raw reply	[flat|nested] 19+ messages in thread

* [PATCH 06/10] drivers/char: Support compiling out /dev/full
  2015-01-23 18:37 [PATCH 00/10] tinification: Make memory-access char devices optional Tom Zanussi
                   ` (4 preceding siblings ...)
  2015-01-23 18:37 ` [PATCH 05/10] drivers/char: Support compiling out /dev/zero Tom Zanussi
@ 2015-01-23 18:37 ` Tom Zanussi
  2015-01-23 18:37 ` [PATCH 07/10] drivers/char: Support compiling out /dev/random Tom Zanussi
                   ` (3 subsequent siblings)
  9 siblings, 0 replies; 19+ messages in thread
From: Tom Zanussi @ 2015-01-23 18:37 UTC (permalink / raw)
  To: josh; +Cc: linux-kernel, Tom Zanussi

Most embedded systems have no use for /dev/full, and omitting it saves
space.  Add a new EMBEDDED config option to disable it.

bloat-o-meter (based on tinyconfig):

add/remove: 0/2 grow/shrink: 0/0 up/down: 0/-122 (-122)
function                                     old     new   delta
write_full                                     6       -      -6
full_fops                                    116       -    -116

Signed-off-by: Tom Zanussi <tom.zanussi@linux.intel.com>
---
 drivers/char/Kconfig | 11 +++++++++++
 drivers/char/mem.c   |  6 ++++++
 2 files changed, 17 insertions(+)

diff --git a/drivers/char/Kconfig b/drivers/char/Kconfig
index 00f9b8a..62290e0 100644
--- a/drivers/char/Kconfig
+++ b/drivers/char/Kconfig
@@ -56,6 +56,17 @@ config DEVZERO
 	  systems with strictly controlled userspace may not need it.
 	  When in doubt, say "Y".
 
+config DEVFULL
+	bool "/dev/full virtual device support" if EMBEDDED
+	depends on DEVMEM_BASE
+	default y
+	help
+	  Say Y here if you want to support the /dev/full device. The
+	  /dev/full device is used mainly for testing how programs
+	  respond to ENOSPC, and can be disabled on systems that will
+	  never use it in production, such as many embedded systems.
+	  When in doubt, say "Y".
+
 config SGI_SNSC
 	bool "SGI Altix system controller communication support"
 	depends on (IA64_SGI_SN2 || IA64_GENERIC)
diff --git a/drivers/char/mem.c b/drivers/char/mem.c
index 96f7a9d..5b60003 100644
--- a/drivers/char/mem.c
+++ b/drivers/char/mem.c
@@ -665,11 +665,13 @@ static int mmap_zero(struct file *file, struct vm_area_struct *vma)
 }
 #endif
 
+#ifdef CONFIG_DEVFULL
 static ssize_t write_full(struct file *file, const char __user *buf,
 			  size_t count, loff_t *ppos)
 {
 	return -ENOSPC;
 }
+#endif
 
 /*
  * Special lseek() function for /dev/null and /dev/zero.  Most notably, you
@@ -791,12 +793,14 @@ static struct backing_dev_info zero_bdi = {
 };
 #endif
 
+#ifdef CONFIG_DEVFULL
 static const struct file_operations full_fops = {
 	.llseek		= full_lseek,
 	.read		= new_sync_read,
 	.read_iter	= read_iter_zero,
 	.write		= write_full,
 };
+#endif
 
 static const struct memdev {
 	const char *name;
@@ -819,7 +823,9 @@ static const struct memdev {
 #ifdef CONFIG_DEVZERO
 	 [5] = { "zero", 0666, &zero_fops, &zero_bdi },
 #endif
+#ifdef CONFIG_DEVFULL
 	 [7] = { "full", 0666, &full_fops, NULL },
+#endif
 	 [8] = { "random", 0666, &random_fops, NULL },
 	 [9] = { "urandom", 0666, &urandom_fops, NULL },
 #ifdef CONFIG_PRINTK
-- 
1.9.3


^ permalink raw reply	[flat|nested] 19+ messages in thread

* [PATCH 07/10] drivers/char: Support compiling out /dev/random
  2015-01-23 18:37 [PATCH 00/10] tinification: Make memory-access char devices optional Tom Zanussi
                   ` (5 preceding siblings ...)
  2015-01-23 18:37 ` [PATCH 06/10] drivers/char: Support compiling out /dev/full Tom Zanussi
@ 2015-01-23 18:37 ` Tom Zanussi
  2015-01-23 18:37 ` [PATCH 08/10] drivers/char: Support compiling out /dev/urandom Tom Zanussi
                   ` (2 subsequent siblings)
  9 siblings, 0 replies; 19+ messages in thread
From: Tom Zanussi @ 2015-01-23 18:37 UTC (permalink / raw)
  To: josh; +Cc: linux-kernel, Tom Zanussi

Some embedded systems with tightly controlled userspace have no use
for /dev/random, and could benefit from the size savings gained by
omitting it.  Add a new EMBEDDED config option to disable it.

The newly marked __maybe_unused functions, random_write, random_ioctl,
and random_fasync are shared between /dev/random and /dev/urandom, and
will be compiled out if both devices are disabled.

bloat-o-meter (based on tinyconfig):

add/remove: 0/4 grow/shrink: 1/0 up/down: 139/-392 (-253)
function                                     old     new   delta
sys_getrandom                                211     350    +139
random_read                                   20       -     -20
random_poll                                   83       -     -83
random_fops                                  116       -    -116
_random_read.part                            173       -    -173

bloat-o-meter showing the difference between only CONFIG_DEVURANDOM
off and both CONFIG_DEVURANDOM and CONFIG_DEVRANDOM off:

add/remove: 0/8 grow/shrink: 1/0 up/down: 144/-851 (-707)
function                                     old     new   delta
sys_getrandom                                288     432    +144
random_fasync                                 16       -     -16
random_read                                   20       -     -20
random_write                                  42       -     -42
write_pool                                    82       -     -82
random_poll                                   83       -     -83
random_fops                                  116       -    -116
_random_read.part                            173       -    -173
random_ioctl                                 319       -    -319

So we see the extra symbols drop, while _random_read is inlined into
sys_getrandom.

Signed-off-by: Tom Zanussi <tom.zanussi@linux.intel.com>
---
 drivers/char/Kconfig  | 11 +++++++++++
 drivers/char/mem.c    |  2 ++
 drivers/char/random.c | 16 ++++++++++++----
 3 files changed, 25 insertions(+), 4 deletions(-)

diff --git a/drivers/char/Kconfig b/drivers/char/Kconfig
index 62290e0..9416b7e 100644
--- a/drivers/char/Kconfig
+++ b/drivers/char/Kconfig
@@ -67,6 +67,17 @@ config DEVFULL
 	  never use it in production, such as many embedded systems.
 	  When in doubt, say "Y".
 
+config DEVRANDOM
+	bool "/dev/random virtual device support" if EMBEDDED
+	depends on DEVMEM_BASE
+	default y
+	help
+	  Say Y here if you want to support the /dev/random
+	  device. The /dev/random device is the blocking userspace
+	  interface to the kernel random number generator, and can be
+	  disabled on systems that will never use it in production,
+	  such as many embedded systems.  When in doubt, say "Y".
+
 config SGI_SNSC
 	bool "SGI Altix system controller communication support"
 	depends on (IA64_SGI_SN2 || IA64_GENERIC)
diff --git a/drivers/char/mem.c b/drivers/char/mem.c
index 5b60003..f226714 100644
--- a/drivers/char/mem.c
+++ b/drivers/char/mem.c
@@ -826,7 +826,9 @@ static const struct memdev {
 #ifdef CONFIG_DEVFULL
 	 [7] = { "full", 0666, &full_fops, NULL },
 #endif
+#ifdef CONFIG_DEVRANDOM
 	 [8] = { "random", 0666, &random_fops, NULL },
+#endif
 	 [9] = { "urandom", 0666, &urandom_fops, NULL },
 #ifdef CONFIG_PRINTK
 	[11] = { "kmsg", 0644, &kmsg_fops, NULL },
diff --git a/drivers/char/random.c b/drivers/char/random.c
index 04645c0..8547056 100644
--- a/drivers/char/random.c
+++ b/drivers/char/random.c
@@ -1370,11 +1370,13 @@ _random_read(int nonblock, char __user *buf, size_t nbytes)
 	}
 }
 
+#ifdef CONFIG_DEVRANDOM
 static ssize_t
 random_read(struct file *file, char __user *buf, size_t nbytes, loff_t *ppos)
 {
 	return _random_read(file->f_flags & O_NONBLOCK, buf, nbytes);
 }
+#endif
 
 static ssize_t
 urandom_read(struct file *file, char __user *buf, size_t nbytes, loff_t *ppos)
@@ -1394,6 +1396,7 @@ urandom_read(struct file *file, char __user *buf, size_t nbytes, loff_t *ppos)
 	return ret;
 }
 
+#ifdef CONFIG_DEVRANDOM
 static unsigned int
 random_poll(struct file *file, poll_table * wait)
 {
@@ -1408,6 +1411,7 @@ random_poll(struct file *file, poll_table * wait)
 		mask |= POLLOUT | POLLWRNORM;
 	return mask;
 }
+#endif
 
 static int
 write_pool(struct entropy_store *r, const char __user *buffer, size_t count)
@@ -1431,8 +1435,9 @@ write_pool(struct entropy_store *r, const char __user *buffer, size_t count)
 	return 0;
 }
 
-static ssize_t random_write(struct file *file, const char __user *buffer,
-			    size_t count, loff_t *ppos)
+static ssize_t __maybe_unused random_write(struct file *file,
+					   const char __user *buffer,
+					   size_t count, loff_t *ppos)
 {
 	size_t ret;
 
@@ -1446,7 +1451,8 @@ static ssize_t random_write(struct file *file, const char __user *buffer,
 	return (ssize_t)count;
 }
 
-static long random_ioctl(struct file *f, unsigned int cmd, unsigned long arg)
+static long __maybe_unused random_ioctl(struct file *f, unsigned int cmd,
+					unsigned long arg)
 {
 	int size, ent_count;
 	int __user *p = (int __user *)arg;
@@ -1498,11 +1504,12 @@ static long random_ioctl(struct file *f, unsigned int cmd, unsigned long arg)
 	}
 }
 
-static int random_fasync(int fd, struct file *filp, int on)
+static int __maybe_unused random_fasync(int fd, struct file *filp, int on)
 {
 	return fasync_helper(fd, filp, on, &fasync);
 }
 
+#ifdef CONFIG_DEVRANDOM
 const struct file_operations random_fops = {
 	.read  = random_read,
 	.write = random_write,
@@ -1511,6 +1518,7 @@ const struct file_operations random_fops = {
 	.fasync = random_fasync,
 	.llseek = noop_llseek,
 };
+#endif
 
 const struct file_operations urandom_fops = {
 	.read  = urandom_read,
-- 
1.9.3


^ permalink raw reply	[flat|nested] 19+ messages in thread

* [PATCH 08/10] drivers/char: Support compiling out /dev/urandom
  2015-01-23 18:37 [PATCH 00/10] tinification: Make memory-access char devices optional Tom Zanussi
                   ` (6 preceding siblings ...)
  2015-01-23 18:37 ` [PATCH 07/10] drivers/char: Support compiling out /dev/random Tom Zanussi
@ 2015-01-23 18:37 ` Tom Zanussi
  2015-01-23 18:37 ` [PATCH 09/10] drivers/char: Support compiling out /dev/kmsg Tom Zanussi
  2015-01-23 18:37 ` [PATCH 10/10] drivers/char: Support compiling out the getrandom(2) syscall Tom Zanussi
  9 siblings, 0 replies; 19+ messages in thread
From: Tom Zanussi @ 2015-01-23 18:37 UTC (permalink / raw)
  To: josh; +Cc: linux-kernel, Tom Zanussi

Some embedded systems with tightly controlled userspace have no use
for /dev/urandom, 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/2 grow/shrink: 1/0 up/down: 77/-212 (-135)
function                                     old     new   delta
sys_getrandom                                211     288     +77
urandom_read                                  96       -     -96
urandom_fops                                 116       -    -116

Signed-off-by: Tom Zanussi <tom.zanussi@linux.intel.com>
---
 drivers/char/Kconfig  | 11 +++++++++++
 drivers/char/mem.c    |  2 ++
 drivers/char/random.c |  2 ++
 3 files changed, 15 insertions(+)

diff --git a/drivers/char/Kconfig b/drivers/char/Kconfig
index 9416b7e..1af4551 100644
--- a/drivers/char/Kconfig
+++ b/drivers/char/Kconfig
@@ -78,6 +78,17 @@ config DEVRANDOM
 	  disabled on systems that will never use it in production,
 	  such as many embedded systems.  When in doubt, say "Y".
 
+config DEVURANDOM
+	bool "/dev/urandom virtual device support" if EMBEDDED
+	depends on DEVMEM_BASE
+	default y
+	help
+	  Say Y here if you want to support the /dev/urandom
+	  device. The /dev/urandom device is the nonblocking userspace
+	  interface to the kernel random number generator, and can be
+	  disabled on systems that will never use it in production,
+	  such as many embedded systems.  When in doubt, say "Y".
+
 config SGI_SNSC
 	bool "SGI Altix system controller communication support"
 	depends on (IA64_SGI_SN2 || IA64_GENERIC)
diff --git a/drivers/char/mem.c b/drivers/char/mem.c
index f226714..5315f63 100644
--- a/drivers/char/mem.c
+++ b/drivers/char/mem.c
@@ -829,7 +829,9 @@ static const struct memdev {
 #ifdef CONFIG_DEVRANDOM
 	 [8] = { "random", 0666, &random_fops, NULL },
 #endif
+#ifdef CONFIG_DEVURANDOM
 	 [9] = { "urandom", 0666, &urandom_fops, NULL },
+#endif
 #ifdef CONFIG_PRINTK
 	[11] = { "kmsg", 0644, &kmsg_fops, NULL },
 #endif
diff --git a/drivers/char/random.c b/drivers/char/random.c
index 8547056..7e5a423 100644
--- a/drivers/char/random.c
+++ b/drivers/char/random.c
@@ -1520,6 +1520,7 @@ const struct file_operations random_fops = {
 };
 #endif
 
+#ifdef CONFIG_DEVURANDOM
 const struct file_operations urandom_fops = {
 	.read  = urandom_read,
 	.write = random_write,
@@ -1527,6 +1528,7 @@ const struct file_operations urandom_fops = {
 	.fasync = random_fasync,
 	.llseek = noop_llseek,
 };
+#endif
 
 SYSCALL_DEFINE3(getrandom, char __user *, buf, size_t, count,
 		unsigned int, flags)
-- 
1.9.3


^ permalink raw reply	[flat|nested] 19+ messages in thread

* [PATCH 09/10] drivers/char: Support compiling out /dev/kmsg
  2015-01-23 18:37 [PATCH 00/10] tinification: Make memory-access char devices optional Tom Zanussi
                   ` (7 preceding siblings ...)
  2015-01-23 18:37 ` [PATCH 08/10] drivers/char: Support compiling out /dev/urandom Tom Zanussi
@ 2015-01-23 18:37 ` Tom Zanussi
  2015-01-23 18:37 ` [PATCH 10/10] drivers/char: Support compiling out the getrandom(2) syscall Tom Zanussi
  9 siblings, 0 replies; 19+ messages in thread
From: Tom Zanussi @ 2015-01-23 18:37 UTC (permalink / raw)
  To: josh; +Cc: linux-kernel, Tom Zanussi

Some embedded systems with tightly controlled userspace have no use
for /dev/kmsg, 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/8 grow/shrink: 1/1 up/down: 92/-1538 (-1446)
function                                     old     new   delta
do_syslog                                   1027    1119     +92
devkmsg_release                               15       -     -15
devlist                                      192     160     -32
devkmsg_poll                                  97       -     -97
devkmsg_open                                 112       -    -112
check_syslog_permissions                     114       -    -114
kmsg_fops                                    116       -    -116
devkmsg_llseek                               144       -    -144
devkmsg_write                                209       -    -209
devkmsg_read                                 699       -    -699

Signed-off-by: Tom Zanussi <tom.zanussi@linux.intel.com>
---
 drivers/char/Kconfig   | 14 ++++++++++++++
 drivers/char/mem.c     |  2 +-
 kernel/printk/printk.c |  2 ++
 3 files changed, 17 insertions(+), 1 deletion(-)

diff --git a/drivers/char/Kconfig b/drivers/char/Kconfig
index 1af4551..25fe627 100644
--- a/drivers/char/Kconfig
+++ b/drivers/char/Kconfig
@@ -89,6 +89,20 @@ config DEVURANDOM
 	  disabled on systems that will never use it in production,
 	  such as many embedded systems.  When in doubt, say "Y".
 
+config DEVKMSG
+	bool "/dev/kmsg virtual device support" if EMBEDDED
+	depends on DEVMEM_BASE && PRINTK
+	default y
+	help
+	  Say Y here if you want to support the /dev/kmsg device. The
+	  /dev/kmsg device provides access to the raw kernel message
+	  ring buffer, and can be disabled on systems that will never
+	  use it in production, such as many embedded systems.  The
+	  kernel log buffer is also accessible via the syslog() kernel
+	  interface and userspace tools such as dmesg (using -S) can
+	  be directed to use that interface instead.  When in doubt,
+	  say "Y".
+
 config SGI_SNSC
 	bool "SGI Altix system controller communication support"
 	depends on (IA64_SGI_SN2 || IA64_GENERIC)
diff --git a/drivers/char/mem.c b/drivers/char/mem.c
index 5315f63..6cc26ea 100644
--- a/drivers/char/mem.c
+++ b/drivers/char/mem.c
@@ -832,7 +832,7 @@ static const struct memdev {
 #ifdef CONFIG_DEVURANDOM
 	 [9] = { "urandom", 0666, &urandom_fops, NULL },
 #endif
-#ifdef CONFIG_PRINTK
+#ifdef CONFIG_DEVKMSG
 	[11] = { "kmsg", 0644, &kmsg_fops, NULL },
 #endif
 };
diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
index 02d6b6d..fbd05d8 100644
--- a/kernel/printk/printk.c
+++ b/kernel/printk/printk.c
@@ -505,6 +505,7 @@ int check_syslog_permissions(int type, bool from_file)
 	return security_syslog(type);
 }
 
+#ifdef CONFIG_DEVKMSG
 
 /* /dev/kmsg - userspace message inject/listen interface */
 struct devkmsg_user {
@@ -797,6 +798,7 @@ const struct file_operations kmsg_fops = {
 	.poll = devkmsg_poll,
 	.release = devkmsg_release,
 };
+#endif
 
 #ifdef CONFIG_KEXEC
 /*
-- 
1.9.3


^ permalink raw reply	[flat|nested] 19+ messages in thread

* [PATCH 10/10] drivers/char: Support compiling out the getrandom(2) syscall
  2015-01-23 18:37 [PATCH 00/10] tinification: Make memory-access char devices optional Tom Zanussi
                   ` (8 preceding siblings ...)
  2015-01-23 18:37 ` [PATCH 09/10] drivers/char: Support compiling out /dev/kmsg Tom Zanussi
@ 2015-01-23 18:37 ` Tom Zanussi
  2015-01-23 19:46   ` Theodore Ts'o
  9 siblings, 1 reply; 19+ messages in thread
From: Tom Zanussi @ 2015-01-23 18:37 UTC (permalink / raw)
  To: josh; +Cc: linux-kernel, Tom Zanussi

Many embedded systems have no use for getrandom, and could benefit
from the size savings gained by omitting it.  Add a new EXPERT config
option, CONFIG_GETRANDOM_SYSCALL (default y), to support compiling it
out.

The newly marked __maybe_unused _random_read is shared between
getrandom(2) and /dev/random, and urandom_read is shared between
getrandom(2) and /dev/urandom, and will be compiled out respectively
if either devices and getrandom(2) are disabled.

bloat-o-meter (based on tinyconfig):

add/remove: 0/2 grow/shrink: 1/0 up/down: 163/-384 (-221)
function                                     old     new   delta
random_read                                   20     183    +163
_random_read.part                            173       -    -173
sys_getrandom                                211       -    -211

Here, _random_read is inlined into random_read, which drops the cold
part of the _random_read partial inline _random_read.part.

bloat-o-meter showing the difference between both CONFIG_DEVRANDOM and
CONFIG_DEVURANDOM off and that plus CONFIG_GETRANDOM_SYSCALL off:

add/remove: 0/5 grow/shrink: 1/2 up/down: 332/-1038 (-706)
function                                     old     new   delta
extract_entropy                              114     446    +332
__print_once                                  16      15      -1
mix_pool_bytes                                17      14      -3
xfer_secondary_pool                           60       -     -60
extract_buf                                  164       -    -164
account                                      181       -    -181
extract_entropy_user                         197       -    -197
sys_getrandom                                432       -    -432

Here we see xfer_secondary_pool, extract_buf, and account inlined into
extract_entropy, while extract_entropy_user from _random_read drops
out because _random_read is dropped (random_read and _random_read.part
drop out when only DEVRANDOM and DEVURANDOM are compiled out -
_random_read is inlined into sys_getrandom in that case, which drops
out when GETRANDOM_SYSCALL is disabled).

Signed-off-by: Tom Zanussi <tom.zanussi@linux.intel.com>
---
 drivers/char/Kconfig  | 13 +++++++++++++
 drivers/char/random.c |  6 ++++--
 kernel/sys_ni.c       |  1 +
 3 files changed, 18 insertions(+), 2 deletions(-)

diff --git a/drivers/char/Kconfig b/drivers/char/Kconfig
index 25fe627..7f7c921 100644
--- a/drivers/char/Kconfig
+++ b/drivers/char/Kconfig
@@ -103,6 +103,19 @@ config DEVKMSG
 	  be directed to use that interface instead.  When in doubt,
 	  say "Y".
 
+config GETRANDOM_SYSCALL
+	bool "Enable getrandom(2) syscall" if EXPERT
+	default y
+	help
+	  Say Y here if you want to enable the getrandom(2) syscall.
+	  The getrandom(2) syscall provides a means to access the
+	  kernel random number generator in cases where /dev/[u]random
+	  is not available.  It also adds optional blocking semantics
+	  to the /dev/urandom entropy pool for programs that are
+	  designed to use it.  It can be disabled on systems that will
+	  never use it in production, such as many embedded systems.
+	  When in doubt, say "Y".
+
 config SGI_SNSC
 	bool "SGI Altix system controller communication support"
 	depends on (IA64_SGI_SN2 || IA64_GENERIC)
diff --git a/drivers/char/random.c b/drivers/char/random.c
index 7e5a423..2a9955f 100644
--- a/drivers/char/random.c
+++ b/drivers/char/random.c
@@ -1339,7 +1339,7 @@ void rand_initialize_disk(struct gendisk *disk)
 }
 #endif
 
-static ssize_t
+static ssize_t __maybe_unused
 _random_read(int nonblock, char __user *buf, size_t nbytes)
 {
 	ssize_t n;
@@ -1378,7 +1378,7 @@ random_read(struct file *file, char __user *buf, size_t nbytes, loff_t *ppos)
 }
 #endif
 
-static ssize_t
+static ssize_t __maybe_unused
 urandom_read(struct file *file, char __user *buf, size_t nbytes, loff_t *ppos)
 {
 	int ret;
@@ -1530,6 +1530,7 @@ const struct file_operations urandom_fops = {
 };
 #endif
 
+#ifdef CONFIG_GETRANDOM_SYSCALL
 SYSCALL_DEFINE3(getrandom, char __user *, buf, size_t, count,
 		unsigned int, flags)
 {
@@ -1552,6 +1553,7 @@ SYSCALL_DEFINE3(getrandom, char __user *, buf, size_t, count,
 	}
 	return urandom_read(NULL, buf, count, NULL);
 }
+#endif
 
 /***************************************************************
  * Random UUID interface
diff --git a/kernel/sys_ni.c b/kernel/sys_ni.c
index 5adcb0a..796021b 100644
--- a/kernel/sys_ni.c
+++ b/kernel/sys_ni.c
@@ -159,6 +159,7 @@ cond_syscall(sys_uselib);
 cond_syscall(sys_fadvise64);
 cond_syscall(sys_fadvise64_64);
 cond_syscall(sys_madvise);
+cond_syscall(sys_getrandom);
 
 /* arch-specific weak syscall entries */
 cond_syscall(sys_pciconfig_read);
-- 
1.9.3


^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [PATCH 10/10] drivers/char: Support compiling out the getrandom(2) syscall
  2015-01-23 18:37 ` [PATCH 10/10] drivers/char: Support compiling out the getrandom(2) syscall Tom Zanussi
@ 2015-01-23 19:46   ` Theodore Ts'o
  2015-01-23 20:04     ` Tom Zanussi
  2015-01-23 22:30     ` josh
  0 siblings, 2 replies; 19+ messages in thread
From: Theodore Ts'o @ 2015-01-23 19:46 UTC (permalink / raw)
  To: Tom Zanussi; +Cc: josh, linux-kernel

On Fri, Jan 23, 2015 at 12:37:16PM -0600, Tom Zanussi wrote:
> Many embedded systems have no use for getrandom, and could benefit
> from the size savings gained by omitting it.  Add a new EXPERT config
> option, CONFIG_GETRANDOM_SYSCALL (default y), to support compiling it
> out.

I'm really not sure this is a good idea.  Even the tiniest embedded
device need secure crypto.  In fact, one could argue that in the case
of the Internet of Things, the tiniests embedded devices
**especially** need secure crypto.  It would be.... unfortunate.... if
the next time North Korea gets upset at the Great Satan, that all of
our light bulbs, refridgerators, cars, heating systems, etc., are
subject to attack.

We know already that home routers are running ancient kernels that are
absolutely no protection whatever.  Is saving a few bytes really worth
potentially opening up a similar attack vector on devices that will
probably be at least an order of magnitude or more numerous than home
routers, and even harder to upgrade once they get out there?

And if you don't have a good random number generator, you really are
*toast*.

It's for this reason that /dev/[u]random were not eligible from being
disabled from the very beginning; it's too much of an attractive
nuisance to a clueless product manager....

	     	  	    	    	 - Ted

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [PATCH 10/10] drivers/char: Support compiling out the getrandom(2) syscall
  2015-01-23 19:46   ` Theodore Ts'o
@ 2015-01-23 20:04     ` Tom Zanussi
  2015-01-23 22:30     ` josh
  1 sibling, 0 replies; 19+ messages in thread
From: Tom Zanussi @ 2015-01-23 20:04 UTC (permalink / raw)
  To: Theodore Ts'o, josh, linux-kernel



On 01/23/2015 01:46 PM, Theodore Ts'o wrote:
> On Fri, Jan 23, 2015 at 12:37:16PM -0600, Tom Zanussi wrote:
>> Many embedded systems have no use for getrandom, and could benefit
>> from the size savings gained by omitting it.  Add a new EXPERT config
>> option, CONFIG_GETRANDOM_SYSCALL (default y), to support compiling it
>> out.
>
> I'm really not sure this is a good idea.  Even the tiniest embedded
> device need secure crypto.  In fact, one could argue that in the case
> of the Internet of Things, the tiniests embedded devices
> **especially** need secure crypto.  It would be.... unfortunate.... if
> the next time North Korea gets upset at the Great Satan, that all of
> our light bulbs, refridgerators, cars, heating systems, etc., are
> subject to attack.
>

Right, but not everything is networked - there are standalone embedded 
systems that could benefit from the savings.  Anyway, it's not a huge 
savings so I could just remove them to avoid the temptation...

Tom.

> We know already that home routers are running ancient kernels that are
> absolutely no protection whatever.  Is saving a few bytes really worth
> potentially opening up a similar attack vector on devices that will
> probably be at least an order of magnitude or more numerous than home
> routers, and even harder to upgrade once they get out there?
>
> And if you don't have a good random number generator, you really are
> *toast*.
>
> It's for this reason that /dev/[u]random were not eligible from being
> disabled from the very beginning; it's too much of an attractive
> nuisance to a clueless product manager....
>
> 	     	  	    	    	 - Ted
>

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [PATCH 10/10] drivers/char: Support compiling out the getrandom(2) syscall
  2015-01-23 19:46   ` Theodore Ts'o
  2015-01-23 20:04     ` Tom Zanussi
@ 2015-01-23 22:30     ` josh
  1 sibling, 0 replies; 19+ messages in thread
From: josh @ 2015-01-23 22:30 UTC (permalink / raw)
  To: Theodore Ts'o, Tom Zanussi, linux-kernel

On Fri, Jan 23, 2015 at 02:46:10PM -0500, Theodore Ts'o wrote:
> On Fri, Jan 23, 2015 at 12:37:16PM -0600, Tom Zanussi wrote:
> > Many embedded systems have no use for getrandom, and could benefit
> > from the size savings gained by omitting it.  Add a new EXPERT config
> > option, CONFIG_GETRANDOM_SYSCALL (default y), to support compiling it
> > out.
> 
> I'm really not sure this is a good idea.  Even the tiniest embedded
> device need secure crypto.
[...]
> We know already that home routers are running ancient kernels that are
> absolutely no protection whatever.  Is saving a few bytes really worth
> potentially opening up a similar attack vector on devices that will
> probably be at least an order of magnitude or more numerous than home
> routers, and even harder to upgrade once they get out there?
> 
> And if you don't have a good random number generator, you really are
> *toast*.
> 
> It's for this reason that /dev/[u]random were not eligible from being
> disabled from the very beginning; it's too much of an attractive
> nuisance to a clueless product manager....

Forcing the availability of the random devices and getrandom syscall
will not force userspace to actually *use* them, and there do exist real
devices that do not need them.

We're not yet talking about the full in-kernel entropy infrastructure,
which should also be removable *if* you aren't using it for CONFIG_NET
or similar.  We're talking about the userspace interfaces.  If you
aren't running any userspace bits that open /dev/*random or that call
getrandom, forcing the existence of those devices will not magically
make the system more secure.  Not all userspaces actually need
randomness, and some of those that do have better alternatives than
/dev/*random or getrandom (such as hardware RNGs).

- Josh Triplett

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [PATCH 05/10] drivers/char: Support compiling out /dev/zero
  2015-01-23 18:37 ` [PATCH 05/10] drivers/char: Support compiling out /dev/zero Tom Zanussi
@ 2015-01-28 21:07   ` Pavel Machek
  2015-01-28 21:51     ` josh
  0 siblings, 1 reply; 19+ messages in thread
From: Pavel Machek @ 2015-01-28 21:07 UTC (permalink / raw)
  To: Tom Zanussi; +Cc: josh, linux-kernel

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.zanussi@linux.intel.com>

I'm not sure that 400 bytes are worth additional Kconfig noise. .. and
pretty much everyone needs /dev/zero...

								Pavel
								
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [PATCH 05/10] drivers/char: Support compiling out /dev/zero
  2015-01-28 21:07   ` Pavel Machek
@ 2015-01-28 21:51     ` josh
  2015-01-28 21:52       ` Pavel Machek
  2015-01-28 23:20       ` Tom Zanussi
  0 siblings, 2 replies; 19+ messages in thread
From: josh @ 2015-01-28 21:51 UTC (permalink / raw)
  To: Pavel Machek; +Cc: Tom Zanussi, linux-kernel

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.zanussi@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).

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.

Personally, I'm hoping that we eventually end up with a disableable
CONFIG_CHAR similar to CONFIG_BLOCK.

- Josh Triplett

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [PATCH 05/10] drivers/char: Support compiling out /dev/zero
  2015-01-28 21:51     ` josh
@ 2015-01-28 21:52       ` Pavel Machek
  2015-01-28 23:20       ` Tom Zanussi
  1 sibling, 0 replies; 19+ messages in thread
From: Pavel Machek @ 2015-01-28 21:52 UTC (permalink / raw)
  To: josh; +Cc: Tom Zanussi, linux-kernel

On Wed 2015-01-28 13:51:06, 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 <tom.zanussi@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).
> 
> 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.

Yes, grouping it would make it more acceptable.

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [PATCH 05/10] drivers/char: Support compiling out /dev/zero
  2015-01-28 21:51     ` josh
  2015-01-28 21:52       ` Pavel Machek
@ 2015-01-28 23:20       ` Tom Zanussi
  2015-01-31 23:08         ` Josh Triplett
  1 sibling, 1 reply; 19+ messages in thread
From: Tom Zanussi @ 2015-01-28 23:20 UTC (permalink / raw)
  To: josh; +Cc: Pavel Machek, linux-kernel

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 <tom.zanussi@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. 

> 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 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.

If you have better ideas and/or naming, please let me know.

> 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.

Tom

> - Josh Triplett



^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [PATCH 05/10] drivers/char: Support compiling out /dev/zero
  2015-01-28 23:20       ` Tom Zanussi
@ 2015-01-31 23:08         ` Josh Triplett
  0 siblings, 0 replies; 19+ messages in thread
From: Josh Triplett @ 2015-01-31 23:08 UTC (permalink / raw)
  To: Tom Zanussi; +Cc: Pavel Machek, linux-kernel

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 <tom.zanussi@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

^ permalink raw reply	[flat|nested] 19+ messages in thread

end of thread, other threads:[~2015-01-31 23:08 UTC | newest]

Thread overview: 19+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-01-23 18:37 [PATCH 00/10] tinification: Make memory-access char devices optional Tom Zanussi
2015-01-23 18:37 ` [PATCH 01/10] drivers/char: Support compiling out memory-access char devices Tom Zanussi
2015-01-23 18:37 ` [PATCH 02/10] drivers/char: Support compiling out /dev/mem Tom Zanussi
2015-01-23 18:37 ` [PATCH 03/10] drivers/char: Support compiling out /dev/port Tom Zanussi
2015-01-23 18:37 ` [PATCH 04/10] drivers/char: Support compiling out /dev/null Tom Zanussi
2015-01-23 18:37 ` [PATCH 05/10] drivers/char: Support compiling out /dev/zero Tom Zanussi
2015-01-28 21:07   ` Pavel Machek
2015-01-28 21:51     ` josh
2015-01-28 21:52       ` Pavel Machek
2015-01-28 23:20       ` Tom Zanussi
2015-01-31 23:08         ` Josh Triplett
2015-01-23 18:37 ` [PATCH 06/10] drivers/char: Support compiling out /dev/full Tom Zanussi
2015-01-23 18:37 ` [PATCH 07/10] drivers/char: Support compiling out /dev/random Tom Zanussi
2015-01-23 18:37 ` [PATCH 08/10] drivers/char: Support compiling out /dev/urandom Tom Zanussi
2015-01-23 18:37 ` [PATCH 09/10] drivers/char: Support compiling out /dev/kmsg Tom Zanussi
2015-01-23 18:37 ` [PATCH 10/10] drivers/char: Support compiling out the getrandom(2) syscall Tom Zanussi
2015-01-23 19:46   ` Theodore Ts'o
2015-01-23 20:04     ` Tom Zanussi
2015-01-23 22:30     ` josh

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).