Apple-2gs-SW/hush
1
0
Fork 0
mirror of https://github.com/sheumann/hush.git synced 2024-10-05 12:54:51 +00:00
Code Issues 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);
}
// 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;

13
modutils/insmod.c
View File

@ -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;