svn commit: trunk/busybox: libbb modutils

[vda at busybox.net]

Author: vda
Date: 2008-06-24 09:08:22 -0700 (Tue, 24 Jun 2008)
New Revision: 22491

Log:
changes in comments only



Modified:
   trunk/busybox/libbb/read.c
   trunk/busybox/modutils/insmod.c


Changeset:
Modified: trunk/busybox/libbb/read.c
===================================================================
--- trunk/busybox/libbb/read.c	2008-06-24 16:02:22 UTC (rev 22490)
+++ trunk/busybox/libbb/read.c	2008-06-24 16:08:22 UTC (rev 22491)
@@ -203,8 +203,8 @@
 	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;

Modified: trunk/busybox/modutils/insmod.c
===================================================================
--- trunk/busybox/modutils/insmod.c	2008-06-24 16:02:22 UTC (rev 22490)
+++ trunk/busybox/modutils/insmod.c	2008-06-24 16:08:22 UTC (rev 22491)
@@ -4235,12 +4235,15 @@
 	}
 
 #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;