From fe733a974457dae2126edf6b2e2bae594418ad74 Mon Sep 17 00:00:00 2001 From: Denis Vlasenko Date: Tue, 24 Jun 2008 16:08:22 +0000 Subject: changes in comments only --- libbb/read.c | 4 ++-- modutils/insmod.c | 13 ++++++++----- 2 files changed, 10 insertions(+), 7 deletions(-) diff --git a/libbb/read.c b/libbb/read.c index fb903c18a..fa9874d31 100644 --- a/libbb/read.c +++ b/libbb/read.c @@ -203,8 +203,8 @@ ssize_t open_read_close(const char *filename, void *buf, size_t size) return read_close(fd, buf, size); } -// Read (potentially big) files in one go. File size is estimated by -// lseek to end. +// Read (potentially big) files in one go. File size is estimated +// by stat. void *xmalloc_open_read_close(const char *filename, size_t *sizep) { char *buf; diff --git a/modutils/insmod.c b/modutils/insmod.c index f45a59465..3fbb02b75 100644 --- a/modutils/insmod.c +++ b/modutils/insmod.c @@ -4235,12 +4235,15 @@ static int insmod_ng_main(int argc ATTRIBUTE_UNUSED, char **argv) } #if 0 - /* Any special reason why mmap? It isn't performace critical... */ - - /* yes, xmalloc'ing can use *alot* of RAM. Don't forget that there are + /* Any special reason why mmap? It isn't performance critical. -vda */ + /* Yes, xmalloc'ing can use *alot* of RAM. Don't forget that there are * modules out there that are half a megabyte! mmap()ing is way nicer - * for small mem boxes, i guess. - */ + * for small mem boxes, i guess. */ + /* But after load, these modules will take up that 0.5mb in kernel + * anyway. Using malloc here causes only a transient spike to 1mb, + * after module is loaded, we go back to normal 0.5mb usage + * (in kernel). Also, mmap isn't magic - when we touch mapped data, + * we use memory. -vda */ int fd; struct stat st; unsigned long len; -- cgit v1.2.3