emo/busybox
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

changes in comments only

Browse Source
This commit is contained in:
Denis Vlasenko 2008-06-24 16:08:22 +00:00
parent 70685bd022
commit fe733a9744
2 changed files with 10 additions and 7 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
libbb/read.c
View File

@ -203,8 +203,8 @@ ssize_t open_read_close(const char *filename, void *buf, size_t size)
return read_close(fd, buf, size); return read_close(fd, buf, size);
} }
// Read (potentially big) files in one go. File size is estimated by // Read (potentially big) files in one go. File size is estimated
// lseek to end. // by stat.
void *xmalloc_open_read_close(const char *filename, size_t *sizep) void *xmalloc_open_read_close(const char *filename, size_t *sizep)
{ {
char *buf; char *buf;

13
modutils/insmod.c
View File

@ -4235,12 +4235,15 @@ static int insmod_ng_main(int argc ATTRIBUTE_UNUSED, char **argv)
} }
#if 0 #if 0
/* Any special reason why mmap? It isn't performace critical... */ /* 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
/* 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 * 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; int fd;
struct stat st; struct stat st;
unsigned long len; unsigned long len;