December 2007 - Darwin-dev - lists.apple.com

Re: hw.cpufamily vs ASP vs machine.h
by David M. Cotter 15 Dec '07

15 Dec '07

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Invoke the system_profiler tool and parse its output; use something like "system_profiler -xml SPHardwareDataType". i am unable to find any API called "system_profiler()" that I can call from my C++ (carbon) program. are you thinking i need to call system("system_profiler -xml SPHardwareDataType") ? if so, where does the output go? how do i get it into a memory buffer? am i supposed to pipe it to a temp file then read that file to parse it? _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com

1 0

raw access to system disk
by Navneet Kumar 15 Dec '07

15 Dec '07

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Thread-index: Acg+8pYRyQdPhMPeTJm6AAFZTtDqlg== _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com

1 0

Identifying CD drives across reboots
by Stephen F. Booth 15 Dec '07

15 Dec '07

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com

1 0

How-to: fcntl + F_PREALLOCATE + F_ALLOCATECONTIG and mmap
by David Hoerl 14 Dec '07

14 Dec '07

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com [For the archives.] You may need these headers: #include <fcntl.h> #include <sys/stat.h> Create a file with open(): open("/tmp/preallocTest", O_RDWR|O_CREAT, S_IRUSR|S_IWUSR); Then setup a fstore_t structure per the fcntl man page: fstore_t fst; So, really, I cannot find any good reason to test the size after this call. Then, how do we know anything happened? Well, look at the sb record: fprintf(stderr, "BLOCKS %d\n", sb.st_blocks ); Yup, lots of disk blocks, awaiting your data! Hope this helps someone out - I could have used it two years ago! David _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This post will hopefully help some other poor soul struggling with how to use this tantilizing feature, given that a deep google search found nothing more than the fcntl man page. Preallocating disk space on OSX / Darwin using fcntl, possibly for use with mmap(). fst.fst_flags = F_ALLOCATECONTIG; // could add F_ALLOCATEALL fst.fst_posmode = F_PEOFPOSMODE; // allocate from EOF (0) fst.fst_offset = 0; // offset relative to the EOF fst.fst_length = desiredSize; fst.fst_bytesalloc = 0; // why not but is not needed ret = fcntl(fd, F_PREALLOCATE, &fst); if(ret == -1) { // read fcntl docs - must test against -1 fprintf(stderr, "failed to expand temp file to size %d (errno %d - %s).\n", imageSize, errno, strerror(errno)); exit(0); } Now, it gets interesting. Unless "desiredSize" is on a block boundary, what you get back will probably be more than you asked for. You are probably doing this as a potential performance enhancer. But if you do the test, expect that the number will most likely be higher than the request, but could be less too. To test for success, you MUST test for "!= -1" (read the fcntl docs), not "!= 0". Now this was the most confusing aspect to me: ret = fstat(fd, &sb); if(ret != 0) { fprintf(stderr, "failed to write to temp file to establish the size.\n"); exit(0); } assert(sb.st_size == 0); succeeds! Also, seeking to the end of the file also shows the file has a 0 length! If you want the file actually allocated (for use with mmap, my application), you can fill it with zeros now by: ret = ftruncate(fd, desiredSize); // NOT fst.fst_bytesAllocated! if(ret != 0) { fprintf(stderr, "failed to write to temp file to establish the size (%d).\n", errno); exit(); } This email sent to site_archiver(a)lists.apple.com

1 0

Re: Is launchd a RAM addict?
by Stephane Sudre 14 Dec '07

14 Dec '07

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com On 14 déc. 07, at 17:43, Dave Zarzycki wrote: No. It looks to be working fine on Leopard. On Panther, I see the same RAM hunger on first launch. _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… launchd was rewritten a few times during the development of Leopard. Does this reproduce on Leopard? This email sent to site_archiver(a)lists.apple.com

1 0

Re: Is launchd a RAM addict?
by Jonas Maebe 14 Dec '07

14 Dec '07

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com On 14 Dec 2007, at 17:52, Shawn Erickson wrote: It may have something to do with working set cache that Mac OS X can maintain. On the first launch of an application no usable cache of the working set exits so it likely loads in more pages then needed when launched the first time (best guess). On secondary launches it has a better picture of the working set needed at launch. Jonas _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… Leopard no longer does this working set caching (resulting in the merry demise of the ever growing /var/vm/app_profiles directories on my nightly compiler regression testing machines). The exact comment with which my radar was closed was: "Engineering has provided the following feedback regarding this issue: There are no application profiles on Leopard. Similar (or better) performance was achieved by using a more flexible read-ahead strategy." This email sent to site_archiver(a)lists.apple.com

1 0

Re: Is launchd a RAM addict?
by Shawn Erickson 14 Dec '07

14 Dec '07

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=puvx57yRzBjgqn2o27sySNNtgKdiUnY3LR6FZlZuWiQ=; b=JX3CoBlIlsjAp1jH2Bg/VaDzfdmOrt8uXn2FxNJkLiL/Aq0JxRSfB67/942v1kVHuRS87uFBz89snMlJ5U+sTbHTPyS10sHNkJUWPNnlNk6oqyuZUssuGOxaHMqQMluKVu3wwSCarlGTcDcCL8nN22SwaPcw6+oFsqDyWEXNRds= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Kt9TiwWEOhny/7bQTVTH2XPIjPIVdzTALvNy6j6Ch3pDGCBM+jZ5IOv8/dHBjfn3OB7MPL4j4Ix9kHhfkPDt0zeBIlMun9y3XfZIv6WMGfn7I5/KaJMbJbDMGs19EdG5fVQO25Wz8CEo5qTVe9QSYXna4DOyFW9T1wvI/VbK5Q4= On Dec 14, 2007 2:50 AM, Stephane Sudre <ssudre(a)intego.com> wrote: > OK, I think I've found what happens. > > I don't know why but the first time you launch an executable on Mac OS > X (10.4.11), it eats more memory than on further launches. > > Here is what I'm seeing: > > I've built a Cocoa application (but I can see that with a Foundation > tool too) > > I copy this application (this copy of the application has never been > launched) to another location. > > I open this application through 'open' for instance (it could be done > with a LaunchDaemon script for a Foundation tool). > > => The application eats 12 MB of RAM. > > I kill the application and launch it again > > => It eats 3-4 MB of RAM > > I kill it and launch it again and again > > -> It eats 3-4 MB of RAM > > I delete the application and replace it with the never launched copy. I > launch it > > => It eats 12 MB of RAM > > I kill it and launch it again > > => It eats 3-4 MB of RAM. > > > I hope the pattern is obvious now. It may have something to do with working set cache that Mac OS X can maintain. On the first launch of an application no usable cache of the working set exits so it likely loads in more pages then needed when launched the first time (best guess). On secondary launches it has a better picture of the working set needed at launch. Of course countless other things can also play into this... -Shawn _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Is launchd a RAM addict?
by Dave Zarzycki 14 Dec '07

14 Dec '07

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com On Dec 14, 2007, at 2:50 AM, Stephane Sudre wrote: OK, I think I've found what happens. Here is what I'm seeing: => The application eats 12 MB of RAM. I kill the application and launch it again => It eats 3-4 MB of RAM I kill it and launch it again and again -> It eats 3-4 MB of RAM => It eats 12 MB of RAM I kill it and launch it again => It eats 3-4 MB of RAM. I hope the pattern is obvious now. On 27 nov. 07, at 19:12, Dave Zarzycki wrote: I'd start with the following tools: leaks heap vmmap Good luck, davez On Nov 27, 2007, at 8:14 AM, Stéphane wrote: Mac OS X 10.4.11: According to Activity Monitor: - The process launched by launchd takes 4 MB of Real Memory - The process launched by launchd takes 1.3 MB of Real Memory _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/zarzycki%40apple.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… launchd was rewritten a few times during the development of Leopard. Does this reproduce on Leopard? I don't know why but the first time you launch an executable on Mac OS X (10.4.11), it eats more memory than on further launches. I've built a Cocoa application (but I can see that with a Foundation tool too) I copy this application (this copy of the application has never been launched) to another location. I open this application through 'open' for instance (it could be done with a LaunchDaemon script for a Foundation tool). I delete the application and replace it with the never launched copy. I launch it I would be interesting to know why the first launch of an application takes more RAM. I though about prebinding but this doesn't sound reasonable. You'll need to run our various memory introspection tools on your program to understand what is going on. I have a process that is launched by launchd. It's set as RunAtLoad = true I have almost exactly the same version of this process launched by a StartupItem (the differences are in strings where a figure is replaced by another). If I kill the process launched by launchd, it's automatically restarted and it takes 1.3 MB of Real Memory. Of course since even startup items are launched via launchd - but later - it makes me wonder why a delayed launch claims less memory than an early one. This email sent to zarzycki(a)apple.com This email sent to site_archiver(a)lists.apple.com

1 0

Re: Is launchd a RAM addict?
by Stephane Sudre 14 Dec '07

14 Dec '07

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com OK, I think I've found what happens. Here is what I'm seeing: => The application eats 12 MB of RAM. I kill the application and launch it again => It eats 3-4 MB of RAM I kill it and launch it again and again -> It eats 3-4 MB of RAM => It eats 12 MB of RAM I kill it and launch it again => It eats 3-4 MB of RAM. I hope the pattern is obvious now. On 27 nov. 07, at 19:12, Dave Zarzycki wrote: I'd start with the following tools: leaks heap vmmap Good luck, davez On Nov 27, 2007, at 8:14 AM, Stéphane wrote: Mac OS X 10.4.11: According to Activity Monitor: - The process launched by launchd takes 4 MB of Real Memory - The process launched by launchd takes 1.3 MB of Real Memory _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/zarzycki%40apple.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… I don't know why but the first time you launch an executable on Mac OS X (10.4.11), it eats more memory than on further launches. I've built a Cocoa application (but I can see that with a Foundation tool too) I copy this application (this copy of the application has never been launched) to another location. I open this application through 'open' for instance (it could be done with a LaunchDaemon script for a Foundation tool). I delete the application and replace it with the never launched copy. I launch it I would be interesting to know why the first launch of an application takes more RAM. I though about prebinding but this doesn't sound reasonable. You'll need to run our various memory introspection tools on your program to understand what is going on. I have a process that is launched by launchd. It's set as RunAtLoad = true I have almost exactly the same version of this process launched by a StartupItem (the differences are in strings where a figure is replaced by another). If I kill the process launched by launchd, it's automatically restarted and it takes 1.3 MB of Real Memory. Of course since even startup items are launched via launchd - but later - it makes me wonder why a delayed launch claims less memory than an early one. This email sent to zarzycki(a)apple.com This email sent to site_archiver(a)lists.apple.com

1 0

Re: link(2) allows directory hard links, man page says otherwise
by Mike Frysinger 13 Dec '07

13 Dec '07

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=6vQBccL+imJKZIdIwkOXQefaOD28PeqN4eGZHErkrsU=; b=haQsZU65VI3RgMXEtQ+cB98Ocpd7FqFPd0vM0ddRUCX/vt5GistEIGxpm26HXExdixIOFzZu++EVljMIpqmeQeFtZU0kDndOxEFaqhc8uX5V34ErLwRnwrHI1spLhJGUYIzaodq7brau0xmSeloNcREr5pnFW4GO5BKubxgs8ug= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=R4sEdIiHwwy3Cj0xd2Iwkj1qZ8SfNlZeqls2jFIwkP6sHv9dbnGxBcX4Vfk4Sij/mEwZeLAmYtdZQ8UcJiV/8sM2ZfYFlNmWEmsCKBc72tEEWIfB9nr/8DcYgWjlhKFgaJ2p2xSYEMne782QrdaxfbXWtCEuh0srYdujAgx7MuY= On Dec 12, 2007 7:41 PM, Rosyna <rosyna(a)unsanity.com> wrote: > This is true. And directory hard links are a concept I do not like for > various reasons. So, I was really pleased when people at WWDC and > other places repeatedly said (or strongly implied) Time Machine used a > private function to make directory hard links, that this SPI would not > be exposed, and developers should not be making directory hard links. > > But alas, if some developer has code that depends on link() failing > with EPERM for a directory (they don't check the path first), their > code will magically start working on HFS+ on 10.5. > > My hope was that time machine would call some super private function > (like hfs_super_private_link) that exposes hfs_vnop_link() to do its > dirty deeds that no one else could, should, or can call. > > It's not my intention to ever intentionally create directory hard links. i dont know what you're coding, but if you plan for it to be POSIX compatible, your feelings on directory hard links are irrelevant as POSIX specifically marks the capability as implementation defined. if you're just writing an OS X application, then i guess you can take it out on the apple guys. i dont mind ;). -mike _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com

1 0