mirror of
https://github.com/sheumann/hush.git
synced 2024-12-30 05:29:47 +00:00
changes in comments only
This commit is contained in:
parent
70685bd022
commit
fe733a9744
@ -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;
|
||||||
|
@ -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;
|
||||||
|
Loading…
Reference in New Issue
Block a user