September 2012 - Darwin-kernel

Re: Question about Samba sharing
by Phil Jordan 29 Sep '12

29 Sep '12

On Sat, Sep 29, 2012 at 2:14 PM, Slava Imameyev <slava.imameev(a)gmail.com> wrote: > 10.7 and 10.8 use the Apple proprietary SMB protocol implementation ( 10.6 > uses the open sourced SMB ) Note that although Samba no longer ships with OSX, you can still build & run it. There are packages for it in both the Homebrew and Macports systems, and there are configuration instructions floating around on the web. I suspect you'll lose the System Preferences/Sharing GUI support, though. phil -- http://philjordan.eu/ - Phil Jordan, software development contractor _______________________________________________ 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: https://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Question about Samba sharing
by Slava Imameyev 29 Sep '12

29 Sep '12

_______________________________________________ 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: https://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists… This email sent to site_archiver(a)lists.apple.com

1 0

Question about Samba sharing
by Sid Moore 28 Sep '12

28 Sep '12

Hi, guys. I have a non-HFS volume that can be reshared to SMB-clients on OS X 10.6. But when upgraded to 10.7 or 10.8, no SMB client can access this share. I believe this volume supports many features such as EA/ACL/RSRC/.. Anybody could help me to give out a reason or method to resolve this? Thanks! .. Sid Moore _______________________________________________ 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: https://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Scsi exclusive access weird behavior
by Phil Jordan 27 Sep '12

27 Sep '12

Hi Antoine, On Wed, Sep 26, 2012 at 6:23 PM, Antoine Missout <antoine.missout(a)metakine.com> wrote: > Assume a DVD in the drive and mounted. > > When I get exclusive access via SCSITaskDeviceInterface->ObtainExclusiveAccess after unmounting it, and then later I release it via ReleaseExclusiveAccess, the OS will remount it as expected. > > However, if the display is locked while ReleaseExclusiveAccess is called, the DVD will get ejected instead of remounted. I suspect this behaviour is down to the Disk Arbitration system - it assigns inserted media (or newly unclaimed media) to the currently logged-in user and tries to mount as that user. When the display is locked, that counts as no user being logged in, hence no mount happens. > How can I avoid this ? I'm not exactly sure - if you have any kind of user space element to your driver, I'd try adding disk arbitration awareness to that and get it to grab the media (DADiskClaim()), or maybe eject approval is more appropriate in your case (DARegisterDiskEjectApprovalCallback()). I guess the question is also what you actually want to happen - mount the media when the user logs back in? Should it be owned by a specific user or should another user get it in the case of user switching? Hope that helps to get you started. phil -- http://philjordan.eu/ - Phil Jordan, software development contractor _______________________________________________ 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: https://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists… This email sent to site_archiver(a)lists.apple.com

1 0

Scsi exclusive access weird behavior
by Antoine Missout 26 Sep '12

26 Sep '12

Hi, Assume a DVD in the drive and mounted. When I get exclusive access via SCSITaskDeviceInterface->ObtainExclusiveAccess after unmounting it, and then later I release it via ReleaseExclusiveAccess, the OS will remount it as expected. However, if the display is locked while ReleaseExclusiveAccess is called, the DVD will get ejected instead of remounted. How can I avoid this ? Thanks, Antoine _______________________________________________ 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: https://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists… This email sent to site_archiver(a)lists.apple.com

1 0

Determine the number of logical CPUs
by Timothy Standing 24 Sep '12

24 Sep '12

I am adding a multithreaded class to SoftRAID kext and want to allocate one thread per logical CPU (i.e. 2 threads per core if HyperThreading is present). How can I determine the number of logical CPUs present? I know I can search through the IORegistry for objects of type IOACPIPlatformDevice and look for the one with the highest processor-number value and then add 1 to that value. I just thought there might be some easier way. Thanks, Tim Standing SoftRAID LLC _______________________________________________ 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: https://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Suppressing LC_DATA_IN_CODE and LC_FUNCTION_STARTS load commands in kexts
by Phil Jordan 22 Sep '12

22 Sep '12

Update: I have filed this bug as rdar://12353507 Let me know if I can be of any further assistance. phil _______________________________________________ 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: https://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Suppressing LC_DATA_IN_CODE and LC_FUNCTION_STARTS load commands in kexts
by Phil Jordan 21 Sep '12

21 Sep '12

Hi Shantonu, Thanks for the quick reply! On Fri, Sep 21, 2012 at 10:06 PM, Shantonu Sen <ssen(a)apple.com> wrote: > Are you sure you are building with -mmacosx-version-min=10.7? 10.6 actually, though I've just tried with 10.7 and that doesn't help either. (Neither does switching between the 10.8 and 10.7 base SDKs, or between clang 4.1 and GCC-llvm) It's very reproducible: - create a new I/O Kit kext project - change deployment target to 10.7 or below - Architectures to 32/64-bit Intel - either set "Build Active Architecture Only" to "No" or just build the 32-bit version. Even this minimal kext will have the two rogue segments: LC_FUNCTION_STARTS is 8 bytes in this case, LC_DATA_IN_CODE zero, as in my case. Doesn't matter if XCode 4.5 is running on Lion or Mountain Lion. > What is your full link line for your i386 kext? XCode tells me the linker command line is: "/Applications/Xcode 4.5.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang++" -arch i386 -isysroot "/Applications/Xcode 4.5.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk" -L/Users/phillip/Library/Developer/Xcode/DerivedData/ssdcache-hcwibjofejcnjvgtslhyzwfqkkty/Build/Products/Debug -F/Users/phillip/Library/Developer/Xcode/DerivedData/ssdcache-hcwibjofejcnjvgtslhyzwfqkkty/Build/Products/Debug -filelist /Users/phillip/Library/Developer/Xcode/DerivedData/ssdcache-hcwibjofejcnjvgtslhyzwfqkkty/Build/Intermediates/ssdcache.build/Debug/ssdcache.build/Objects-normal/i386/ssdcache.LinkFileList -mmacosx-version-min=10.6 -Xlinker -no_function_starts -Xlinker -kext -nostdlib -lkmodc++ /Users/phillip/Library/Developer/Xcode/DerivedData/ssdcache-hcwibjofejcnjvgtslhyzwfqkkty/Build/Intermediates/ssdcache.build/Debug/ssdcache.build/Objects-normal/i386/ssdcache_info.o -lkmod -lcc_kext -o /Users/phillip/Library/Developer/Xcode/DerivedData/ssdcache-hcwibjofejcnjvgtslhyzwfqkkty/Build/Intermediates/ssdcache.build/Debug/ssdcache.build/Objects-normal/i386/ssdcache The "-Xlinker -no_function_starts" is not normally there, of course. Thanks, phil _______________________________________________ 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: https://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Suppressing LC_DATA_IN_CODE and LC_FUNCTION_STARTS load commands in kexts
by Shantonu Sen 21 Sep '12

21 Sep '12

Are you sure you are building with -mmacosx-version-min=10.7? What is your full link line for your i386 kext? Shantonu On Sep 21, 2012, at 12:27 PM, Phil Jordan <lists(a)philjordan.eu> wrote: > Hi, > > I've been having weird issues with my kexts and booting recently and > only just figured out what's going on from a system log line I get > upon touching /SLE: > > com.apple.kextcache: kxld[com.ssdcache.driver.SSDCache]: The Mach-O > file is malformed: Invalid segment type in MH_OBJECT kext: 38. > > This causes the kext not to be prelinked. > > > I've traced this output to a line in init_from_final_linked_image() in > /xnu/libkern/kxld/kxld_object.c: > kxld_log(kKxldLogLinking, kKxldLogErr, kKxldLogMalformedMachO > "Invalid segment type in MH_KEXT_BUNDLE kext: %u.", cmd_hdr->cmd) > > Decimal 38 is 0x26 hex, and according to loader.h this means > LC_FUNCTION_STARTS. Lo and behold, according to "otool -arch i386 -lv" > the i386 part of my kext does indeed have such a segment (the x86_64 > one does not). > > It turns out that the Mountain Lion kxld will actually accept > LC_FUNCTION_STARTS segments (though lacking an i386 kernel, it's > actually irrelevant) but 10.7.x and earlier don't like it. (the > difference between versions is pretty obvious in the switch block > surrounding the above code) It further turns out that this segment > wasn't generated by XCode 4.4.1's linker, but XCode 4.5's adds it for > some reason. I'll file a relevant bug as soon as Radar comes back up. > > > So for now, I'm looking for a work-around other than going back to XCode 4.4.1: > > Googling around a bit, I managed to find the linker flag > -no_function_starts, which gets rid of LC_FUNCTION_STARTS, but then I > get the same kxld system log line as before, though this time with > number 41 aka 0x29 aka LC_DATA_IN_CODE. This segment is whopping 0 > bytes long, so it's obviously important! > > I've been unable to find a linker flag that gets rid of it - how do I > suppress that command being generated, or is there a way to strip it > afterwards? > > Thanks, > phil > > -- > http://philjordan.eu/ - Phil Jordan, software development contractor > _______________________________________________ > 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: > https://lists.apple.com/mailman/options/darwin-kernel/ssen%40apple.com > > This email sent to ssen(a)apple.com _______________________________________________ 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: https://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists… This email sent to site_archiver(a)lists.apple.com

1 0

Suppressing LC_DATA_IN_CODE and LC_FUNCTION_STARTS load commands in kexts
by Phil Jordan 21 Sep '12

21 Sep '12

Hi, I've been having weird issues with my kexts and booting recently and only just figured out what's going on from a system log line I get upon touching /SLE: com.apple.kextcache: kxld[com.ssdcache.driver.SSDCache]: The Mach-O file is malformed: Invalid segment type in MH_OBJECT kext: 38. This causes the kext not to be prelinked. I've traced this output to a line in init_from_final_linked_image() in /xnu/libkern/kxld/kxld_object.c: kxld_log(kKxldLogLinking, kKxldLogErr, kKxldLogMalformedMachO "Invalid segment type in MH_KEXT_BUNDLE kext: %u.", cmd_hdr->cmd) Decimal 38 is 0x26 hex, and according to loader.h this means LC_FUNCTION_STARTS. Lo and behold, according to "otool -arch i386 -lv" the i386 part of my kext does indeed have such a segment (the x86_64 one does not). It turns out that the Mountain Lion kxld will actually accept LC_FUNCTION_STARTS segments (though lacking an i386 kernel, it's actually irrelevant) but 10.7.x and earlier don't like it. (the difference between versions is pretty obvious in the switch block surrounding the above code) It further turns out that this segment wasn't generated by XCode 4.4.1's linker, but XCode 4.5's adds it for some reason. I'll file a relevant bug as soon as Radar comes back up. So for now, I'm looking for a work-around other than going back to XCode 4.4.1: Googling around a bit, I managed to find the linker flag -no_function_starts, which gets rid of LC_FUNCTION_STARTS, but then I get the same kxld system log line as before, though this time with number 41 aka 0x29 aka LC_DATA_IN_CODE. This segment is whopping 0 bytes long, so it's obviously important! I've been unable to find a linker flag that gets rid of it - how do I suppress that command being generated, or is there a way to strip it afterwards? Thanks, phil -- http://philjordan.eu/ - Phil Jordan, software development contractor _______________________________________________ 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: https://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists… This email sent to site_archiver(a)lists.apple.com

1 0