February 2003 - Darwin-kernel

Re: Finding one parent for a vnode born under X
by Quinn 14 Feb '03

14 Feb '03

At 12:15 +0100 14/2/03, Stiphane Sudre wrote: Would there be a way to find 1 vnode parent of a vnode (on any FS)? All of the following is based on my somewhat limited understanding of VFS. Caveat emptor. If the vnode references a directory, you can just VOP_LOOKUP "..". This is, however, subject to vnode locking constraints. For files, I don't think there's a file system independent way. For Macintosh file systems (HFS, HFS Plus, AFP), you can probably doing this by: 1. using VOP_GETATTRLIST with ATTR_CMN_PAROBJID to get the parent's CNID and then 2. using volfs to get the vnode from the CNID. <http://developer.apple.com/qa/qa2001/qa1113.html> This second alternative is a significant binary compatibility liability. It's *definitely* not appropriate to put it in a product that you're going to ship to lots of users. OTOH, it's more compatible than going poking around in v_data. S+E -- Quinn "The Eskimo!" <http://www.apple.com/developer/> Apple Developer Technical Support * Networking, Communications, Hardware _______________________________________________ darwin-kernel mailing list | darwin-kernel(a)lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-kernel Do not post admin requests to the list. They will be ignored.

1 0

Re: Re(5): Baffled
by Eric Long 14 Feb '03

14 Feb '03

> Did you make sure that the entry-point names are defined as extern "C" > ?? They mustn't be mangled so if your source file is C++ then you must > define them with regular C linkage. The module start/stop function definitions reside exclusively in a .c file. I think that particular message refers to the IOKit related code, which descends from IOKit classes. If the OS is looking for my start/stop function names and can't find them, I would expect to see some kind of error noted. It doesn't look to me like it is even trying to find them. It's like it doesn't think there's anything besides the IOKit related code in the kext. The problem occurs even when the kext is owned by root, in group wheel. In remote debugging, I can see all the symbols I expect. If I set breakpoints in my start/stop functions, they never get hit. I've looked at the data in the executable. It has the start/stop function names, unmangled, within it. Very strange. Eric _______________________________________________ darwin-kernel mailing list | darwin-kernel(a)lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-kernel Do not post admin requests to the list. They will be ignored.

1 0

Re(5): Baffled
by Peter Lovell 14 Feb '03

14 Feb '03

Well, the load process looked OK. It shows that there's a start and a stop entry point and it did load, obviously. I noticed the following line ... >kextload: patching C++ code in module /Volumes/Development/Source Code/Aladdin Sources/streamfilter/mac/iclean_kext/build/iCleanSniffer_Debug.kext/ Contents/MacOS/iCleanSniffer_Debug Did you make sure that the entry-point names are defined as extern "C" ?? They mustn't be mangled so if your source file is C++ then you must define them with regular C linkage. As far as permissions and ownership go, it's easiest if you have a build step which sets it correct. Everything needs to be owned by root, group wheel. Permissions should be 755 for folders, 644 for files. The 755 for folders is so a non-priv process can navigate there, which I have to do so that we can verify that the code hasn't been tampered with. If you don't need to navigate then you could use 644 for everything. Regards.....Peter _______________________________________________ darwin-kernel mailing list | darwin-kernel(a)lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-kernel Do not post admin requests to the list. They will be ignored.

1 0

Re: Re(4): Baffled
by Stéphane Sudre 14 Feb '03

14 Feb '03

On Friday, February 14, 2003, at 05:07 PM, Michael Cashwell wrote: To chime in again... Yes, this one happened to me too early on. I should have mentioned it. I ended up using a simple script to "sudo cp -R" the kext from the build location to /System/Library/Extensions/ and that had the side effect of setting the owner and group to root:wheel which seems to be how they need to be set. This was also the easiest location for the system to pick up subordinate dependancies too. In the situation I faced, this was not enough. It looks like that some additional stuff is done when I'm compiling with root. Don't know why. _______________________________________________ darwin-kernel mailing list | darwin-kernel(a)lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-kernel Do not post admin requests to the list. They will be ignored.

1 0

Re: Re(4): Baffled
by Eric Long 14 Feb '03

14 Feb '03

Mike, Peter, Stiphane, Thanks for the feedback. I'm not sure if I was clear about the state of things. To clarify, my kext appears to be loaded as if nothing is wrong. Attached is a log of the results from using kextload -v 6, followed by kextstat. I don't see anything that sheds light on things in that log. When the extension loads, I expect to see this: Feb 12 11:13:00 Gonzo mach_kernel: iCleanSniffer_module_start entered Feb 12 11:13:00 Gonzo mach_kernel: ALHI_URLParser_Init Feb 12 11:13:00 Gonzo mach_kernel: iCleanSniffer pffindproto found TCP Feb 12 11:13:00 Gonzo mach_kernel: ICSnDriverShim::init() Feb 12 11:13:00 Gonzo mach_kernel: ICSnDriverShim::probe() Feb 12 11:13:00 Gonzo mach_kernel: ICSnDriverShim::start() Instead, I'm seeing this: Feb 12 11:13:00 Gonzo mach_kernel: ICSnDriverShim::init() Feb 12 11:13:00 Gonzo mach_kernel: ICSnDriverShim::probe() Feb 12 11:13:00 Gonzo mach_kernel: ICSnDriverShim::start() The module start function never gets called. I can purposely put code in their to cause a panic, without effect. Regarding root/wheel, when the kext loads, it gets flagged for not having root/wheel as the owner/group, and an alert appears to warn about it, it asks whether to cancel, use, or fix. I select use. This has been my standard practice all along, without problems, until now. Here's some of the important project settings: buildSettings = { FRAMEWORK_SEARCH_PATHS = ""; HEADER_SEARCH_PATHS = "///src"; INSTALL_PATH = "$(SYSTEM_LIBRARY_DIR)/Extensions"; KERNEL_MODULE = YES; LIBRARY_SEARCH_PATHS = /usr/lib/gcc/darwin/3.1; MODULE_IOKIT = YES; MODULE_NAME = com.aladdinsys.nke.iCleanSniffer; MODULE_START = iCSniffer_start; MODULE_STOP = iCSniffer_stop; MODULE_VERSION = 1.0.0; OPTIMIZATION_CFLAGS = "-O0"; OTHER_REZFLAGS = ""; PREFIX_HEADER = src/MacKEXT.Debug.prefix.h; PRODUCT_NAME = iCleanSniffer_Debug; SECTORDER_FLAGS = ""; WARNING_CFLAGS = "-Wmost -Wno-four-char-constants -Wno-unknown-pragmas"; WRAPPER_EXTENSION = kext; }; <!DOCTYPE plist PUBLIC \"-//Apple Computer//DTD PLIST 1.0//EN\" \"http://www.apple.com/DTDs/PropertyList-1.0.dtd\"> <plist version=\"1.0\"> <dict> <key>CFBundleDevelopmentRegion</key> <string>English</string> <key>CFBundleExecutable</key> <string>iCleanSniffer_Debug</string> <key>CFBundleGetInfoString</key> <string>iClean version 6.0a3, Copyright ,) 2002-2003 Aladdin Systems.</string> <key>CFBundleIconFile</key> <string></string> <key>CFBundleIdentifier</key> <string>com.aladdinsys.nke.iCleanSniffer</string> <key>CFBundleInfoDictionaryVersion</key> <string>6.0</string> <key>CFBundleName</key> <string>iCleanSniffer</string> <key>CFBundlePackageType</key> <string>KEXT</string> <key>CFBundleShortVersionString</key> <string>6.0a3</string> <key>CFBundleSignature</key> <string>????</string> <key>CFBundleVersion</key> <string>1.0.0</string> <key>IOKitPersonalities</key> <dict> <key>ICSnClientInterface</key> <dict> <key>CFBundleIdentifier</key> <string>com.aladdinsys.nke.iCleanSniffer</string> <key>IOClass</key> <string>com_aladdinsys_ICSnDriverShim</string> <key>IOProviderClass</key> <string>IOResources</string> <key>IOResourceMatch</key> <string>IOKit</string> <key>IOUserClientClass</key> <string>com_aladdinsys_ICSnClientInterface</string> </dict> </dict> <key>OSBundleLibraries</key> <dict> <key>com.apple.kernel.bsd</key> <string>1.1</string> <key>com.apple.kernel.iokit</key> <string>1.1</string> <key>com.apple.kernel.libkern</key> <string>1.1</string> <key>com.apple.kernel.mach</key> <string>1.1</string> </dict> </dict> </plist> Thanks again for chiming in. I'll test to see if setting privileges to root/wheel has any effect, but I don't think it is a factor in this problem. Eric [demime 0.98b removed an attachment of type multipart/appledouble] _______________________________________________ darwin-kernel mailing list | darwin-kernel(a)lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-kernel Do not post admin requests to the list. They will be ignored.

1 0

Re(4): Baffled
by Michael Cashwell 14 Feb '03

14 Feb '03

To chime in again... Yes, this one happened to me too early on. I should have mentioned it. I ended up using a simple script to "sudo cp -R" the kext from the build location to /System/Library/Extensions/ and that had the side effect of setting the owner and group to root:wheel which seems to be how they need to be set. This was also the easiest location for the system to pick up subordinate dependancies too. -Mike On Friday, February 14, 2003, at 10:40 AM, Stiphane Sudre wrote: On Friday, February 14, 2003, at 03:55 PM, Peter Lovell wrote: Hi Eric, Mike's suggestion is a good one. I'll also suggest that you go back to your build process and check that carefully. I've had several occasions where I was able to build the kext with warnings but no errors and it wouldn't load. Just for completeness, also check the plist and other packaging things (ownership, permissions, etc etc). It could be that they were OK in the old build folder but haven't been recreated correctly. I would expect these to at least give you an error upon kextload, but you never know. Another potential cause I once faced. Not building the Kext with the root account prevented my kernel from working. _______________________________________________ darwin-kernel mailing list | darwin-kernel(a)lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-kernel Do not post admin requests to the list. They will be ignored. _______________________________________________ darwin-kernel mailing list | darwin-kernel(a)lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-kernel Do not post admin requests to the list. They will be ignored.

1 0

Re: Re(3): Baffled
by Stéphane Sudre 14 Feb '03

14 Feb '03

On Friday, February 14, 2003, at 03:55 PM, Peter Lovell wrote: Hi Eric, Mike's suggestion is a good one. I'll also suggest that you go back to your build process and check that carefully. I've had several occasions where I was able to build the kext with warnings but no errors and it wouldn't load. Just for completeness, also check the plist and other packaging things (ownership, permissions, etc etc). It could be that they were OK in the old build folder but haven't been recreated correctly. I would expect these to at least give you an error upon kextload, but you never know. Another potential cause I once faced. Not building the Kext with the root account prevented my kernel from working. _______________________________________________ darwin-kernel mailing list | darwin-kernel(a)lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-kernel Do not post admin requests to the list. They will be ignored.

1 0

Re(3): Baffled
by Peter Lovell 14 Feb '03

14 Feb '03

Hi Eric, Mike's suggestion is a good one. I'll also suggest that you go back to your build process and check that carefully. I've had several occasions where I was able to build the kext with warnings but no errors and it wouldn't load. Just for completeness, also check the plist and other packaging things (ownership, permissions, etc etc). It could be that they were OK in the old build folder but haven't been recreated correctly. I would expect these to at least give you an error upon kextload, but you never know. Regards.....Peter On Thursday, February 13, 2003, at 10:08 PM, Michael Cashwell wrote: Greetings, I ran into something like this a while back (my KEXT silently not loading). My case wasn't that I'd tossed the build directory. I can't completely remember the details but I think I had the start and stop functions not exported properly. In any case, I do remember that I figured it out by adding "-v 6" to the kextload command. This causes it to generate a verbose log of the load attempt. If there is a missing function or dependency problem this should expose it. Try this and if you're still stuck post the results. (I also always ran a tail -f on the system.log file.) Best regards, Mike On Thursday, February 13, 2003, at 07:26 PM, Eric Long wrote: Hi, I've encountered a bizarre problem that has me completely baffled. Maybe someone knows what's going on... I have a network kernel extension that I've been working on for the last few months. It has loaded, spit out messages to the system log, and unloaded all as expected for all that time, until today. For reasons I can't begin to imagine, now when I load the kext, I get no errors reported, but The kext MODULE_START and MODULE_STOP functions never get called. I can't come up with any change that I have made that could cause this to break, except that I tossed my build folder, to force a complete rebuild without remnants from the past. I'm using Project Builder 2.1 on 10.2.3 (and 10.2.4). I even tried checking out a previously tagged version that was known to work properly. I get the same problem with it. It's like there was something in that old build folder that made things ok, that's now gone. The kext includes a client interface implemented through an IOKit personality. That all seems to work fine. It's just the NKE side of things that's not happening. Any thoughts? Eric Long ______________________________________________________________________ _____ Macintosh Software Engineer Aladdin Systems, Inc. http://www.aladdinsys.com 245 Westridge Drive, Watsonville, CA 95076 (831) 761-6200 x628 _______________________________________________ darwin-kernel mailing list | darwin-kernel(a)lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-kernel Do not post admin requests to the list. They will be ignored. _______________________________________________ darwin-kernel mailing list | darwin-kernel(a)lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-kernel Do not post admin requests to the list. They will be ignored. _______________________________________________ darwin-kernel mailing list | darwin-kernel(a)lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-kernel Do not post admin requests to the list. They will be ignored.

1 0

Re: Finding one parent for a vnode born under X
by George André 14 Feb '03

14 Feb '03

Stiphane, Usually parent information is stored in the vnodes private information, which ofcourse, is private and different in layout between FS. George. Stiphane Sudre wrote: Would there be a way to find 1 vnode parent of a vnode (on any FS)? The headers and "The Design and Implementation of the 4.4 BSD OS" are saying no. _______________________________________________ darwin-kernel mailing list | darwin-kernel(a)lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-kernel Do not post admin requests to the list. They will be ignored. _______________________________________________ darwin-kernel mailing list | darwin-kernel(a)lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-kernel Do not post admin requests to the list. They will be ignored.

1 0

Finding one parent for a vnode born under X
by Stéphane Sudre 14 Feb '03

14 Feb '03

Would there be a way to find 1 vnode parent of a vnode (on any FS)? The headers and "The Design and Implementation of the 4.4 BSD OS" are saying no. _______________________________________________ darwin-kernel mailing list | darwin-kernel(a)lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-kernel Do not post admin requests to the list. They will be ignored.

1 0