**** BEGIN LOGGING AT Sat Dec 27 02:59:57 2008 Dec 27 05:31:14 03Mike Westerhof  07org.openembedded.dev * r0faec81b54 10openembedded.git/packages/ftpd-topfield/ (files/usb-header-name-2-6-23.patch ftpd-topfield_0.7.5.bb): ftpd-topfield: add patch for 2.6.23 kernel headers Dec 27 06:34:43 03Mike Westerhof  07org.openembedded.dev * r1bbdc74a53 10openembedded.git/packages/opkg/ (4 files in 2 dirs): Dec 27 06:34:43 opkg_wget_nogpg: dramatically reduce memory footprint, too dodge OOM killer. Dec 27 06:34:43 - eliminate unnecessary libopkg.so Dec 27 06:34:43 - use vfork() instead of fork() and system() Dec 27 06:34:43 - make specifying of alternate tmpdir actually work. Dec 27 07:58:32 uh Dec 27 07:58:37 I thought vfork was deprecated Dec 27 09:51:00 luke-jr: depends who you talk to, I guess. vfork certainly has its uses. Dec 27 14:43:06 * * OE Bug 4948 has been created by prices(AT)dflytech.com Dec 27 14:43:09 * * openwrt-sdk.conf points to generic-uclibc.conf which doesn't exist Dec 27 14:43:11 * * http://bugs.openembedded.net/show_bug.cgi?id=4948 Dec 27 14:43:41 vfork() is like a vampire; it won't die. I rather suspect that someone will have to create a version of fork() that doesn't copy the entire address space before vfork() can be properly buried. Until then, it will live on... Dec 27 16:42:03 my vfork understanding is Linux basically does vfork with fork ..... Dec 27 16:50:17 They threaten. Dec 27 16:50:21 But not so far. Dec 27 16:53:03 interesting Dec 27 16:53:13 what is the difference? Dec 27 16:56:29 fork() creates a new process that has its own virtual memory mapping, that just happen to map to the same pages as the parent process -- but they are unique page tables and all that. vfork() creates a child that actually shares the parents page tables and stuff -- so a vfork() is highly dangerous if not coded carefully, but a fork() runs afoul of the OOM killer because even though it uses no extra memory (beyond the extra set of page tables) it *could Dec 27 16:56:29 * use extra RAM - and that invokes the wrath of the almighty OOM killer. Dec 27 17:24:12 linux has only fairly recently gained vfork() support in the first place. it would be a bit of a bizarre retrograde step for them to remove it again. Dec 27 17:24:16 oh well, crazy kernel h4x0rs. Dec 27 18:03:48 pb_: I recall reading that fork() was just as efficient as vfork() now Dec 27 18:13:59 luke-jr: It's not, but efficiency is not the real issue in this case; it is the need to dodge the murderous rampage of the OOM killer. Dec 27 18:26:08 >_< Dec 27 18:36:47 mwester: I'm a bit surprised that the OOM killer gets so excited about potentially-overcommitted memory. Is that a new change? Dec 27 18:37:32 I'm fairly sure it never used to do that: if you had /proc/sys/vm/overcommit_memory set to 1, you could happily mmap() several times the amount of actual memory that you had available, so long as you didn't actually dirty the pages. Dec 27 18:37:52 That still works. Dec 27 18:38:11 So why is the fork() case different? Dec 27 18:38:29 But I think that core system utilities essential to the operation of the base image should not require non-standard kernel settings. Dec 27 18:39:31 Ah, I see. You mean you want to make it work even if overcommit_memory is set to zero? Dec 27 18:39:38 That's the default. Dec 27 18:40:08 Yes, indeed. Personally, I always considered setting to one to just be one of those things that you had to do to get a working system. Dec 27 18:40:20 Well, I tend to agree. Dec 27 18:40:34 Not that I think it would be a bad thing if you didn't have to do that, of course. Making the system utilities use vfork() is a fine idea. Dec 27 18:41:16 But, for myself, I was always happy enough to just set that variable to one as part of the startup process and then live with it. :-} Dec 27 18:42:57 Frankly, I wish there was a way to provide a per-executable or at least per-process exception. e.g. I *know* that opkg will never actually modify the parent's memory pages, so there's no danger -- if I could mark it as such, it would save a lot of trouble. Dec 27 18:43:40 I think the intent of the OOM Killer is good, but it's implementation is rather horrid. Dec 27 18:43:59 must run off for a bit, back later. Dec 27 19:45:44 mickeyl: are you familiar with the feedparser module by any chance? Dec 27 20:05:45 hey! how do i create a *.sig file for my openembedded repository Dec 27 20:11:39 03Koen Kooi  07org.openembedded.dev * r36f71557a9 10openembedded.git/packages/gimp/gimp.inc: gimp: add gdk-pixbuf-csource-native to DEPENDS Dec 27 20:11:47 03Koen Kooi  07org.openembedded.dev * r793de93f23 10openembedded.git/packages/linux/ (linux-omap/omap3evm/defconfig linux-omap_git.bb): linux-omap git: update evm defconfig Dec 27 22:15:23 jo kergoth Dec 28 01:36:42 nacht **** ENDING LOGGING AT Sun Dec 28 02:59:57 2008