April 2008 - Darwin-kernel - lists.apple.com

Re: Version of dynamic library
by Graham J Lee 11 Apr '08

11 Apr '08

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Hi, Thanks, Graham. _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… On 11 Apr 2008, at 14:13, anukriti_shrimal wrote: Now, my problem is that for all fat_arch structs, I am getting cpu_type = 0 or 3. But the header file mach/machine.h doen't define 3 or 0 to be valid types. My machine is having cpu_type = 7 (x86) and cpu_subtype = 4. Since these don't match, I m unable to proceed further. I can only guess that you're doing it wrong :-(. I've written code to investigate the content of Mach-O and Mach fat files, and getting the CPU type information just works. Here are some snippits (some error- checking and tracing code removed). Getting this into a state where you could use the code is left as an exercise for the reader... - (NSArray *)architectureStrings { GLInstanceMethodEntryLog(@"finding architectures"); int i; NSMutableArray *strings = [NSMutableArray array]; for (i = 0; i < header.nfat_arch; i++) { struct fat_arch arch = eachFatArch[i]; NSString *string = MachArchitectureForCpu(arch.cputype, arch.cpusubtype); [strings addObject: string]; } GLInstanceMethodExitLog(@"copying and returning %@", strings); return [[strings copy] autorelease]; } - (id)initWithPath: (NSString *)fatFile { GLInstanceMethodEntryLog(@"instantiating with path: %@", fatFile); self = [super init]; if (self) { int fd, bytesRead, fatArchesToRead, i; NSFileManager *fm = [NSFileManager defaultManager]; char *cPath = (char *)[fm fileSystemRepresentationWithPath: fatFile]; //read the Fat header in fd = open(cPath, O_RDONLY); bytesRead = read(fd, &header, sizeof(struct fat_header)); // do some byteswap header.magic = NSSwapBigIntToHost(header.magic); if (header.magic != FAT_MAGIC) { GLInstanceMethodExitLog(@"this isn't a Fat file!"); close(fd); return nil; } header.nfat_arch = NSSwapBigIntToHost(header.nfat_arch); // read the fat_arch headers in fatArchesToRead = header.nfat_arch * sizeof(struct fat_arch); eachFatArch = malloc(fatArchesToRead); bytesRead = read(fd, eachFatArch, fatArchesToRead); close(fd); // do something with the fat_arch headers } return self; } This email sent to site_archiver(a)lists.apple.com

1 0

Re: Network stack/ethernet driver issues
by William Kucharski 11 Apr '08

11 Apr '08

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com User-agent: Thunderbird 2.0.0.12 (X11/20080228) Michael Cashwell wrote: Well, there's a grey area here between what is "correct" and what is allowed. William Kucharski _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… I'd just run across the "UDP == throw-away" mindset in William's post in other contexts (mainly sysadmins configuring routers) and wanted to point out that it's not really correct in all cases. If a particular router or system wanted to pass (being silly here) one UDP packet per hour, it could and wouldn't be violating any of the rules of IP networking. That doesn't mean it's a bad idea to drop those packets, but it's not technically incorrect behavior to do so. In this particular case, the fact that ring buffer overflow messages are being generated seems indicative that the behavior is not what was intended by the driver authors. The fact that Linux does not display a similar error when run on the same hardware seems to back up this point, but at the same time we don't know what Mac OS X's priorities are when it comes to maintaining isochronous system events. It may have perfectly good reasons it believes it's OK to let the ring buffer overflow. Nevertheless, the fact that so much CPU is being consumed to process the UDP packets is pretty much evidence to me that something isn't working the way it was designed, or putting a Mac OS X box on any busy network segment would be enough to bring it to its knees. (Stupid trivia fact: Did you know that dealing with network interrupts is an OLD Mac problem? Back in 1988, putting a Mac II (68020 + PMMU) running A/UX 1.0 or 1.1 on a busy Ethernet network would cause the Mac to first choke then shut off its Ethernet card entirely as it just couldn't handle the traffic properly.) This email sent to site_archiver(a)lists.apple.com

1 0

RE: Version of dynamic library
by anukriti_shrimal 11 Apr '08

11 Apr '08

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Thread-index: AcibuBGAxp1zMtrtSyKlUMY8Qg6HjQAHAHhQ I need to display the version information for the list of libraries(full path) given to me as an input without using any tool(like otool, lipo etc.). This is my project requirement. Thanks for the information. It has really proved useful. But I m stuck again. The approach that I m following is that I read all the fat_arch structs from the library.Then for each struct I try to match its cpu_type and cpu_subtype with my system's cpu_type and cpu_subtype. If they match, I'll retrieve the Mach-O header from the file using that fat_arch struct. Now, my problem is that for all fat_arch structs, I am getting cpu_type = 0 or 3. But the header file mach/machine.h doen't define 3 or 0 to be valid types. My machine is having cpu_type = 7 (x86) and cpu_subtype = 4. Since these don't match, I m unable to proceed further. Kindly help. -----Original Message----- From: darwin-kernel-bounces+anukriti_shrimal=persistent.co.in(a)lists.apple.com [mailto:darwin-kernel-bounces+anukriti_shrimal=persistent.co.in@lists.apple. com] On Behalf Of Quinn Sent: Friday, April 11, 2008 3:09 PM To: darwin-kernel(a)lists.apple.com Subject: RE: Version of dynamic library At 14:45 +0530 11/4/08, anukriti_shrimal wrote: >Well, when I read the fat_header, it gives following values: > > magic = 3199925962, (bebafeca) > nfat_arch = 0 >Since the no. of fat_archs is 0, how can I determine the version number in >this case. A value of zero for fat_archs is very unlikely. You're doing something wrong in your read code. Here's a typical example of a fat header: $ hexdump -n 8 /usr/lib/libSystem.dylib 0000000 ca fe ba be 00 00 00 04 Remember that fat headers are always big endian. >My high level goal is to find the version of the dynamic library when I m >given its full path. That's just a restatement of your original question. I was asking about /why/ you're trying to get this information. If I can understand what you're trying to do, I may be able to suggest a better approach (where "better" means "less code for you to write"). S+E -- Quinn "The Eskimo!" <http://www.apple.com/developer/> Apple Developer Relations, Developer Technical Support, Core OS/Hardware _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/anukriti_shrimal%40pers istent.co.in This email sent to anukriti_shrimal(a)persistent.co.in _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Network stack/ethernet driver issues
by Michael Cashwell 11 Apr '08

11 Apr '08

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com On Apr 11, 2008, at 1:12 AM, Justin C. Walker wrote: On Apr 10, 2008, at 10:35 , Michael Cashwell wrote: On Apr 10, 2008, at 11:44 AM, Justin C. Walker wrote: In terms of any code at issue for rimas' problem, yes. -Mike _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… You are correct that an ethernet driver does not have permission to drop one kind of packet over another, I don't think you are correct in your implication that it cares about network-layer packet types Did I imply it does? I didn't intend to. You did say that the driver should not have "more permission" to drop UDP over TCP packets. I don't know of any driver that pays attention to IP frame type (in particular because they can't always tell; as you say, fragmentation is fun). OK, that was only in reference to an implication that I took from William's post that the loss was OK simply because the data were UDP even if it was happening in the driver. We are pretty clearly in violent agreement here. I don't think TCP/UDP or QoS is involved in rimas' problem. That really does look like a driver issue. I don't think so, although I suppose it's worth looking at. The driver can only do so much; it's part of a bucket brigade, and if it doesn't have buffers, that's it for the outgoing packets. The driver has no clue where the packets come from; it's just all bits to it. I'm thinking in the area of the driver not servicing the hardware often enough and the loss actually occurs in the Ethernet controller hardware. But I'd see that as a driver issue since servicing the hardware is its job. It may just be a buffer reservation problem though. Assuming that someone's data is less important just because they used UDP is flawed. I don't think there is any assumption regarding that except in the UDP code, where it's assumed that if there's no space for the packet, it's OK to drop it. I'd just run across the "UDP == throw-away" mindset in William's post in other contexts (mainly sysadmins configuring routers) and wanted to point out that it's not really correct in all cases. This email sent to site_archiver(a)lists.apple.com

1 0

RE: Version of dynamic library
by Quinn 11 Apr '08

11 Apr '08

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Well, when I read the fat_header, it gives following values: magic = 3199925962, (bebafeca) nfat_arch = 0 Since the no. of fat_archs is 0, how can I determine the version number in this case. $ hexdump -n 8 /usr/lib/libSystem.dylib 0000000 ca fe ba be 00 00 00 04 Remember that fat headers are always big endian. My high level goal is to find the version of the dynamic library when I m given its full path. S+E -- Quinn "The Eskimo!" <http://www.apple.com/developer/> Apple Developer Relations, Developer Technical Support, Core OS/Hardware _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… At 14:45 +0530 11/4/08, anukriti_shrimal wrote: A value of zero for fat_archs is very unlikely. You're doing something wrong in your read code. Here's a typical example of a fat header: That's just a restatement of your original question. I was asking about /why/ you're trying to get this information. If I can understand what you're trying to do, I may be able to suggest a better approach (where "better" means "less code for you to write"). This email sent to site_archiver(a)lists.apple.com

1 0

RE: Version of dynamic library
by anukriti_shrimal 11 Apr '08

11 Apr '08

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Thread-index: Acibs1ZWOvnqIgggRuOB2+Vurdc7ZAAAGo/g Hi, Well, when I read the fat_header, it gives following values: magic = 3199925962, (bebafeca) nfat_arch = 0 Since the no. of fat_archs is 0, how can I determine the version number in this case. My high level goal is to find the version of the dynamic library when I m given its full path. Regards, Anukriti -----Original Message----- From: darwin-kernel-bounces+anukriti_shrimal=persistent.co.in(a)lists.apple.com [mailto:darwin-kernel-bounces+anukriti_shrimal=persistent.co.in@lists.apple. com] On Behalf Of Quinn Sent: Friday, April 11, 2008 2:33 PM To: darwin-kernel(a)lists.apple.com Subject: RE: Version of dynamic library At 12:20 +0530 11/4/08, anukriti_shrimal wrote: >How can I get the version in such files? You have to parse the fat header to find the architecture you're interested in, and then look up the version number in that specific architecture. The fat header is not very complex; see <mach-o/fat.h> for the details. What's your high-level goal here? There are typically better ways to manage version numbering that to go grovelling around in the image. S+E -- Quinn "The Eskimo!" <http://www.apple.com/developer/> Apple Developer Relations, Developer Technical Support, Core OS/Hardware _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/anukriti_shrimal%40pers istent.co.in This email sent to anukriti_shrimal(a)persistent.co.in _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

RE: Version of dynamic library
by Quinn 11 Apr '08

11 Apr '08

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com S+E -- Quinn "The Eskimo!" <http://www.apple.com/developer/> Apple Developer Relations, Developer Technical Support, Core OS/Hardware _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… At 12:20 +0530 11/4/08, anukriti_shrimal wrote: How can I get the version in such files? You have to parse the fat header to find the architecture you're interested in, and then look up the version number in that specific architecture. The fat header is not very complex; see <mach-o/fat.h> for the details. What's your high-level goal here? There are typically better ways to manage version numbering that to go grovelling around in the image. This email sent to site_archiver(a)lists.apple.com

1 0

RE: Version of dynamic library
by anukriti_shrimal 11 Apr '08

11 Apr '08

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Thread-index: AcibI/lfAffI40rZRf6lDa0cr+DfSAAe9L9g Thanks for the reply. I have found that the first four bytes of the file determines its magic number. When I tested this with my library files, I found that the magic number is 0xbebafeca. This stands for FAT_CIGAM. I suppose, this means, the file contains FAT header. But this header doesn't contain the version info of the library. How can I get the version in such files? Regards, Anukriti -----Original Message----- From: mm w [mailto:openspecies@gmail.com] Sent: Thursday, April 10, 2008 9:31 PM To: anukriti_shrimal Cc: darwin-kernel(a)lists.apple.com Subject: Re: Version of dynamic library Hi if you want a good example you can get it from lipo.c a part of odc tools (a long time ago maintened by Shantonu) I think your problem come from that you don't test if you have a fat binary or not and which arch is stored (if 1) if you wont be able to get the src (odc) on the Internet let me know Cheers! On Thu, Apr 10, 2008 at 3:36 AM, anukriti_shrimal <anukriti_shrimal(a)persistent.co.in> wrote: > > > > > Hi All, > > > > I am currently working on Mac Os x 10.4.7 > > I am trying to retrieve the version of a dynamic library (.dylib) from its > full path. > > > > While investigating source code of dyld, I found that the mach_header or > mach_header_64 contains the version information. > > So, I tried to get the mach_header from the file contents. > > But I was unable to do so. > > > > Can anyone help me in this regard, > > Is there some other way to accomplish the same task, > > > > Thanks in advance, > > Princess > > > > > > > _______________________________________________ > Do not post admin requests to the list. They will be ignored. > Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) > Help/Unsubscribe/Update your Subscription: > > http://lists.apple.com/mailman/options/darwin-kernel/openspecies%40gmail.com > > This email sent to openspecies(a)gmail.com > -- -mmw _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Network stack/ethernet driver issues
by Justin C. Walker 11 Apr '08

11 Apr '08

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com On Apr 10, 2008, at 11:44 AM, Justin C. Walker wrote: On Apr 10, 2008, at 06:45 , Michael Cashwell wrote: Fragmentation is fun. :-) You are certainly correct, but the driver isn't involved in that. Justin -- Justin C. Walker, Curmudgeon-At-Large Institute for the Absorption of Federal Funds -------- If you're not confused, You're not paying attention -------- _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… On Apr 10, 2008, at 10:35 , Michael Cashwell wrote: The point in rimas' case is that just because the data are UDP does not give the Ethernet driver more permission to drop them than if they were TCP [corrected] nor does it mean they are less important. You are correct that an ethernet driver does not have permission to drop one kind of packet over another, I don't think you are correct in your implication that it cares about network-layer packet types Did I imply it does? I didn't intend to. You did say that the driver should not have "more permission" to drop UDP over TCP packets. I don't know of any driver that pays attention to IP frame type (in particular because they can't always tell; as you say, fragmentation is fun). : these are all one to the driver (it's possible for the driver to obey QOS indicators of some type, but it can't know about the IP frame type: in particular, it may not know that a particular packet is in fact (part of) a UDP frame). After all, it's ethernet. Even if the packet gets to the media layer, there's no guarantee that (a) it will make it out the door; or (b) even if it gets out the door, it may not survive the trip across the local link :-}). I don't think TCP/UDP or QoS is involved in rimas' problem. That really does look like a driver issue. I don't think so, although I suppose it's worth looking at. The driver can only do so much; it's part of a bucket brigade, and if it doesn't have buffers, that's it for the outgoing packets. The driver has no clue where the packets come from; it's just all bits to it. My point was only to underscore that there are different dimensions to the question of what delivery characteristics are most important. If you're transferring live video having data arrive late is no different from it not arrive at all. In fact, if "late" requires retries and resends (and this consumed even more bandwidth and resources) only to just be dropped anyway then late is actually worse than not at all. Assuming that someone's data is less important just because they used UDP is flawed. I don't think there is any assumption regarding that except in the UDP code, where it's assumed that if there's no space for the packet, it's OK to drop it. This email sent to site_archiver(a)lists.apple.com

1 0

Re: Network stack/ethernet driver issues
by Andrew Gallatin 10 Apr '08

10 Apr '08

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com rimas(a)cnmat.berkeley.edu writes: > Hi Chuck, > > Thanks for the advice. However, there is no option to modify the ring > buffer size in the info.plist file. Also, the AppleYukon2 driver is not Strange, there is such an option in the Yukon and Yukon2 drivers in 10.4.11: % grep RxRingSize /System/Library/Extensions//IONetworkingFamily.kext/Contents/PlugIns/AppleYukon*.kext/Contents/Info.plist | wc -l 15 You may want to check to see if link level flow control is enabled on your switch, and on the sender. You can tell if the mac has negotiated it via ifconfig: # ifconfig en0 | grep active media: autoselect (100baseTX <full-duplex,flow-control>) status: active You also might want to check to see how many mbuf / cluster allocation failurs have happened via netstat -m. Last, to be certain nothing is dropped in the host, check netstat -spudp and look for drops due to full socket buffers. Cheers, Drew _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0