site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com ... -- Terry _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.a... On Jul 23, 2008, at 6:22 PM, Greg wrote: On Jul 23, 2008, at 8:47 PM, Terry Lambert wrote: If you had NMI'ed the machine and done two machine debugging, it would have been clear from the stack traces you posted that the unmount was blocked by the vnode being held on the device. I did do this, however I wasn't able to get any stack trace, and therefore wasn't able to post it to the list. It just hanged on "continuing", and entering debug mode just showed me the stack trace for the debug-mode thing itself. Perhaps I could have played around with GDB more, but at the time it had not occurred to me to try to jump to other threads (and I did not remember the commands to do that..) The command is "showallstacks". It won't exist unless you load the "kgmacros" package into gdb, as described at: <http://developer.apple.com/documentation/Darwin/Conceptual/KEXTConcept/KEXTC...
As to why vnode_lookup() is not well documented: we don't want you doing file I/O from your KEXT. It's fine to not want people to do file I/O from a KEXT, but if you're going to provide the functions for doing so, at least provide a note in the header along the lines of, "Use of these functions is strongly discouraged because ____. Use at your own risk." Otherwise, you might get people posting to the mailing list asking for help using them... and that's just annoying! ;-) The function is not provided for that purpose; the original purpose of the function being provided was to allow a mount point relookup and verification by vnode pointer for network file system clients to support mount -u. It is also internally used to obtain a vnode pointer that is held persistently for a long time when implementing shadow directories for support extended attributes on file systems that do not support them natively. In general, if you search the mailing list archives, you are going to find a large number of posts explaining why kernel level file I/O is an incredibly bad idea. Most of the related posts will tell you how to better do what it is you are trying to do. This email sent to site_archiver@lists.apple.com