September 2009 - Darwin-dev

Re: Sending SCSI commands in Mac OS X
by Terry Lambert 04 Sep '09

04 Sep '09

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com -- Terry On Jul 23, 2009, at 7:04 AM, mlists(a)ugsoft.de wrote: Am 23.07.2009 um 13:26 schrieb Terry Lambert: It states: Uwe _______________________________________________ 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… Sorry, my answer on the driver was incorrect. Apparently some of the documentation on <http://developer.apple.com> is out of date, and the only supported way to access some of these devices is through a user client. I guess the last time I used SCSI tapes on Mac OS X (to read some old QIC tapes on a Blue and White G3), I had installed your company's ES- Backup product <http://www.ugsoft.de> to get device shims and forgot about it! Did you go to <http://developer.apple.com> and read the document "SCSI Architecture Model Device Interface Guide"? "By design, Mac OS X does not allow applications to send SCSI or ATA commands to storage devices unless the application developer also provides an in-kernel device driver that supports the commands." One of the intents if this is to allow the driver to model state for such coomands such that the state if the device is known to the driver at all times. For standard tape devices, you should not need to write your own driver; if you plug the device in, it will show up in /dev, Never seen a tape drive, neither SCSI, FireWire, USB nor FibreChannel connected to Mac OS X 10.2 up to 10.5 which shows up in /dev. What device filename should I look for? and you can at least issue reads, writes, and standard commands, such as causing a rewind, via the device file. For non-standard commands, such as you would use to control loading and unloading tapes in a tape robot, etc., you will need to write an in-kernel driver that knows how to talk to the hardware and subclasses the more generic device (i.e. the IOKit model lets you write only the missing pieces implementing the missing control commands; you don't write a whole driver that implements read/write/etc.). Instead we use SCSITaskDeviceInterface functions from userland as described in Apple's SCSI Architecture Model Device Interface Guide "WorkingWithSAM.pdf" in order to implement a "SCSI pass-thru" functionality. No additional driver required. This email sent to site_archiver(a)lists.apple.com

1 0

Re: Building 10.6' ld64
by William Siegrist 04 Sep '09

04 Sep '09

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com On Sep 4, 2009, at 8:43 AM, Peter O'Gorman wrote: Hello, Thanks -Bill _______________________________________________ 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… Jonas Maebe wrote: ld64 for Mac OS X 10.4 and 10.5 can be built fine by people outside Apple. The one for 10.6 fails to build (on 10.6) because a) mach-o/arm/* is missing (I guess I can copy this from an iPhone SDK) b) libunwind/* is missing (from the errors, it seems as these files should be part of the ld64 project, but they aren't). The relevant files appear to be libunwind/DwarfInstructions.hpp, libunwind/ AddressSpace.hpp and libunwind/Registers.hpp I filed a request for the open source release of the project that provides libunwind/*.h a couple of months ago with opensource(a)apple.com , when I tried to build the ld64 that was released with the iPhone OS 3.0 sources. As with dsymutil and friends, that project is not currently open source. I suggest filing radars, emailing opensource(a)apple.com, etc. I don't know how much good it will do though. The Darwin Team is aware of the request for libunwind. I'll put down another vote for it, so no need to file more radars or emails. This email sent to site_archiver(a)lists.apple.com

1 0

Re: Building 10.6' ld64
by Peter O'Gorman 04 Sep '09

04 Sep '09

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com User-agent: Thunderbird 2.0.0.19 (X11/20090105) Jonas Maebe wrote: > Hello, > > ld64 for Mac OS X 10.4 and 10.5 can be built fine by people outside Apple. > > The one for 10.6 fails to build (on 10.6) because > a) mach-o/arm/* is missing (I guess I can copy this from an iPhone SDK) > b) libunwind/* is missing (from the errors, it seems as these files > should be part of the ld64 project, but they aren't). The relevant files > appear to be libunwind/DwarfInstructions.hpp, libunwind/AddressSpace.hpp > and libunwind/Registers.hpp > I filed a request for the open source release of the project that provides libunwind/*.h a couple of months ago with opensource(a)apple.com, when I tried to build the ld64 that was released with the iPhone OS 3.0 sources. As with dsymutil and friends, that project is not currently open source. I suggest filing radars, emailing opensource(a)apple.com, etc. I don't know how much good it will do though. Peter -- Peter O'Gorman http://pogma.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

Building 10.6' ld64
by Jonas Maebe 04 Sep '09

04 Sep '09

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com User-agent: Internet Messaging Program (IMP) H3 (4.3.4) Hello, ld64 for Mac OS X 10.4 and 10.5 can be built fine by people outside Apple. Thanks, Jonas ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. _______________________________________________ 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… The one for 10.6 fails to build (on 10.6) because a) mach-o/arm/* is missing (I guess I can copy this from an iPhone SDK) b) libunwind/* is missing (from the errors, it seems as these files should be part of the ld64 project, but they aren't). The relevant files appear to be libunwind/DwarfInstructions.hpp, libunwind/AddressSpace.hpp and libunwind/Registers.hpp I'd like to debug it, because it has a problem dealing with routines identified by multiple global symbols if these routines are indirectly reachable from a mod_init/mod_term routine (when moving such code around, ld only moves around the associated symbols that are referred to in the current object file rather than all of them, resulting in random code execution if one of the other symbols is referred from another object file -- yes, I will file a bug report for this). It seems that I can work around the ld bug for the init routines by specifying -no_order_inits, but it doesn't help for the mod_term ones (even though ld does not explicitly reorder them at first sight). If I can debug ld, maybe I can find a workaround for the mod_term routines as well. So can someone give me some hints on where I can find the libunwind and the mach-o/arm files? This email sent to site_archiver(a)lists.apple.com

1 0

[SOLVED] Maximum EA size
by Frank Lahm 04 Sep '09

04 Sep '09

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=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=PNWGfk9iHp9mw64n+QznNAdXiwl73oDzTR2fq9uR2k0=; b=DHP32amEed72C/yBByrPYNGBLyI5nmoeuLgYsc6s40N33FS8l9lt/eZMMrvO9R10pP 5FS5TfH8tETowhzTZNAViueE64gq9OuQYVZyHdUYQrn4zsWUDF1vHvuJ4JD96hh6/51h deczg7JM648dCkeTvwPP8MF0pSQEoPKPhXhe0= Domainkey-signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=k9oaP0OWaPhWypqGqwho+Dppc8fwX7OPi2aI5i6HpMMqMZYs4OSeH+uS+kshAmzo92 7ceK8G6TbjFx7686bnR3/N+DQcrVkh2DdRUtLCcRpq9IIls3whP9Nd0BtQ9QJWBur0rp 4Be4ny1HBhPmwRyTLWTeirDDr4st55hjXrJSU= The mentioned fellow solved this: http://opensource.apple.com/source/xnu/xnu-1228.15.4/bsd/hfs/hfs_xattr.c /* * getmaxinlineattrsize - calculate maximum inline attribute size. * * This yields 3,802 bytes for an 8K node size. */ static size_t getmaxinlineattrsize(struct vnode * attrvp) { struct BTreeInfoRec btinfo; size_t nodesize = ATTRIBUTE_FILE_NODE_SIZE; size_t maxsize; if (attrvp != NULL) { (void) hfs_lock(VTOC(attrvp), HFS_SHARED_LOCK); if (BTGetInformation(VTOF(attrvp), 0, &btinfo) == 0) nodesize = btinfo.nodeSize; hfs_unlock(VTOC(attrvp)); } maxsize = nodesize; maxsize -= sizeof(BTNodeDescriptor); /* minus node descriptor */ maxsize -= 3 * sizeof(u_int16_t); /* minus 3 index slots */ maxsize /= 2; /* 2 key/rec pairs minumum */ maxsize -= sizeof(HFSPlusAttrKey); /* minus maximum key size */ maxsize -= sizeof(HFSPlusAttrData) - 2; /* minus data header */ maxsize &= 0xFFFFFFFE; /* multiple of 2 bytes */ return (maxsize); } ------------------------------------------------------------ http://en.wikipedia.org/wiki/Extended_file_attributes#Mac_OS_X Mac OS X 10.4 and later support extended attributes by making use of the HFS+ filesystem Attributes file B*-tree feature which allows for named forks. Although the named forks in HFS+ support arbitrarily large amounts of data through extents, the OS support for extended attributes only supports inline attributes, limiting their size to that which can fit within a single B*-tree node. Cheers! _______________________________________________ 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

method_exchangeImplementations problem
by Donnie Lee 04 Sep '09

04 Sep '09

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:mime-version:received:date:message-id:subject :from:to:content-type; bh=U87TGhVgwfvCO4joQ+EWjXr/ohbbXKYRv9/Y+x7qRWc=; b=PBgjI5AD1Wpt855R6pfXlyFGV5gloNWk8xfwH5YQtBFeor23KfBHM8mj4syhLKEVzS PLZTuh6yJD+/cf+NefTwqTKMKD774gcwTtjlkCUF9fTlThC1EQZd3uqgG1z79e93TA21 ZBufs1uGgoSfeZZWjrgbPOftmiDaOT9FKasDw= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=c/BLEi+69/3P2QG7r9UIKv+9X2UzkhQQbWOLtr0r0SaikB8aGz2WdmoyO9W0b8iOkb HH66BtUvxHoxnqgsRS1851ByXMixXWqG0ePW4rnyfsMqc75HBUnkoYqsfidZG4kym+4Y bl6VM1T1UDllb2XS2yP6k1rvKSYFu3he4kGOw= Hello! I'd like to override delegate functions in Cocoa app. They are in Class1 and Class2 (which is an instance of Class1). I get these classes via objc_getClass(). Then I coded two functions and add them to classes using class_addMethod(). Then I called method_exchangeImplementations() for both of them. Replaced delegate for Class1 works fine. But replaced delegate for Class2 don't work. It starts working only for new instances of Class1 (and Class2 as Class1 instance variable), but don't work for original instance. How to make it work? PS: First I tried to use categories to override these delegates, but for x86_64 linker don't link it as "lazy bound", even with "-undefined dynamic_lookup" (i386 do it fine). Am I right that its impossible to use categories anymore? Thanks in advance, Donnie. _______________________________________________ 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

Maximum EA size
by Frank Lahm 04 Sep '09

04 Sep '09

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=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=1NvY5iMQVvbATaubT9105HwNmHyOYTOD7C/SH8F8Olo=; b=XQWNmJG7aPbvUgiaPpuHjXgy3huUnEU67iZWjro5je2X0wisdnUNEv5byiLTov83Cc rfzzp8h/gEIYKMyJnsrFiCEqypjrVByzTwpMHo1bd6mwm6xSBs6qpFJOgA3CWhs3SpUp OOfVASyGhn65miD/1q9RWWMVQphRX2727rfmk= Domainkey-signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=YNWvIs02lAHGWrkKdKSEE6JCzyGoe/FlkDvkuTnFZLnnPk7NqNNF1vjhXL5TCfRr0Y iKaiP/bOEdDK81VmWUZ2ABduZy1mJJLoXkaMR6bi7z0GB4uCgJVQGdLZ+JKOP71sskwy fl/ej1JUiP/NLZJaFPHGk/vn3ON3kUduWb43s= Hi list, I'm one of the Netatalk developers. We're in the process of implementing EA support. Earlier this year I implemented EA support using native ZFS EAs as a backend, still in the 10.5 timeframe. I tested for the greatest possible EA size (for non ressource forks obviously) with a small programm that drove setxattr with files on a local HFS+ like this: ---8<--- #include <unistd.h> #include <sys/xattr.h> #include <stdio.h> #include <stdlib.h> #include <string.h> #include <errno.h> int main(int argc, char **argv) { int ret; size_t size; char *buf; if (argc != 4) { printf("Usage: nattr <filename> <EAname> <size>\n"); exit(EXIT_FAILURE); } size = strtoul(argv[3], NULL, 10); if ( ! (buf = malloc(size)) ) { perror("malloc"); exit(EXIT_FAILURE); } ret = setxattr(argv[1], argv[2], buf, size, 0, XATTR_CREATE); if (ret && errno == EEXIST) ret = setxattr(argv[1], argv[2], buf, size, 0, XATTR_REPLACE); if (ret) printf("setxattr error: %s.errno: %u\n", strerror(errno), errno ); return ret; } ---8<--- This gave me 3802. In 10.6 I still get the same result. 3803 results in E2BIG. But: a fellow developer turned up sth. in xnu which seem to suggest that some layers in xnu regard the maximum size as: > http://opensource.apple.com/source/xnu/xnu-1228.15.4/bsd/hfs/hfs_xattr.c > > #define HFS_MAXATTRIBUTESIZE (128 * 1024) > > > http://opensource.apple.com/source/xnu/xnu-1228.15.4/bsd/vfs/vfs_xattr.c > > #define ATTR_MAX_SIZE (128*1024) /* 128K maximum attribute data size */ Better safe then sorry, so can anybody tell us what is a reliable maximum size ? Thanks! -Frank _______________________________________________ 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

PF Firewall/Snow Leopard
by z3r0_f4ct0r＠mac.com 04 Sep '09

04 Sep '09

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com PF http://www.openbsd.org/faq/pf/ Thanks, Juan _______________________________________________ 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… By any chance is the PF firewall in Snow Leopard? I haven't found anything online regarding it. I know its been ported over from OpenBSD to FreeBSD, but I'm not to sure if its in Snow Leopard yet. This email sent to site_archiver(a)lists.apple.com

1 0

Re: Error when compiling blocks code in Snow Leopard
by Nico Schmidt 03 Sep '09

03 Sep '09

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com On 03.09.2009, at 23:42, Terry Lambert wrote: Actually the following code fails to compile with the same message: typedef void (^dispatch_block_t)(); class Foo { void Bar() { dispatch_block_t b = ^{ int i = 1; }; } }; while the following with an explicit scope for i works: typedef void (^dispatch_block_t)(); class Foo { void Bar() { dispatch_block_t b = ^{ int ::i = 1; }; } }; Any thoughts? Nico _______________________________________________ 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… On Sep 3, 2009, at 1:48 PM, Greg Parker wrote: On Sep 3, 2009, at 1:40 PM, Terry Lambert wrote: The C++ standard limits the scope of variables declared like you are declaring 'i' (as a for-init-statement, technically) to the for itself, rather than extending to the end of the enclosing scope. This is a standards related change in behaviour from traditional C++/g++, which, while not permitted by the standard, is how old compilers tended to be implemented, not having an explicit indicator for interior scope ends in their parse tree representation. There's nothing wrong with his `for` scope here; he didn't use `i` at all, much less use it out of scope. A block-local variable in a C ++ method fails the same way with no loop at all: Then perhaps my observation about the compiler option that causes this to happen in C code as well will be helpful in identifying a root cause in the C++ compiler? -- Terry block.cpp: In function ‘void __Bar_block_invoke_1(void*)’: block.cpp:7: error: ‘int Foo::i’ is not a static member of ‘class Foo’ This email sent to site_archiver(a)lists.apple.com

1 0

Re: Error when compiling blocks code in Snow Leopard
by Terry Lambert 03 Sep '09

03 Sep '09

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com -- Terry _______________________________________________ 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… On Sep 3, 2009, at 1:48 PM, Greg Parker wrote: On Sep 3, 2009, at 1:40 PM, Terry Lambert wrote: The C++ standard limits the scope of variables declared like you are declaring 'i' (as a for-init-statement, technically) to the for itself, rather than extending to the end of the enclosing scope. This is a standards related change in behaviour from traditional C+ +/g++, which, while not permitted by the standard, is how old compilers tended to be implemented, not having an explicit indicator for interior scope ends in their parse tree representation. There's nothing wrong with his `for` scope here; he didn't use `i` at all, much less use it out of scope. A block-local variable in a C+ + method fails the same way with no loop at all: Then perhaps my observation about the compiler option that causes this to happen in C code as well will be helpful in identifying a root cause in the C++ compiler? This email sent to site_archiver(a)lists.apple.com

1 0