* [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 related [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 related [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 related [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 related [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 related [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 related [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 related [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 related [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 related [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 related [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).