site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com The only exported VNOPS are: _VNOP_BWRITE _VNOP_FSYNC _VNOP_IOCTL _VNOP_READ _VNOP_STRATEGY _VNOP_WRITE -Don On Nov 17, 2005, at 1:06 AM, Marek Kozubal wrote: Hello! nm -pgo /mach_kernel /mach_kernel: 000fb544 T _VNOP_CLOSE /mach_kernel: 000fb410 T _VNOP_OPEN /mach_kernel: 000fbb48 T _VNOP_READ /mach_kernel: 000fbc84 T _VNOP_WRITE So is this a bug? A feature? Thanks! -Marek _______________________________________________ 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/brady%40apple.com _______________________________________________ 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... A file system should not need to call itself via a VNOP call. The VNOP calls are for VFS to call into a file system. File systems should be responsible for locking their inode (fsnode) data. So if a file system calls itself with another VNOP from within a VNOP you end up recursively locking the inode. How did you enter you file system? You should probably be calling your implementation (eg myfs_open() which would probably take a locked inode for input). I have a vfs file system kext I am developing, and I need to call VNOP_OPEN and VNOP_CLOSE within it, (with a VNOP_READ or VNOP_WRITE in between). However, when I try to load my kext, I get a link failure on VNOP_OPEN and VNOP_CLOSE, but VNOP_READ & VNOP_WRITE link fine. They are all listed in /mach_kernel: I link against com.apple.kpi.bsd(8.0.0b1), com.apple.kpi.libkern (8.0.0b1), com.apple.kpi.mach(8.0.0b1). I've tried adding various com.apple.kernel.* and com.apple.kpi.unsupported with no success either. If I link against com.apple.kernel(8.3.0), it works, but this is not a desireable thing to link against. So whats going on here? This is Mac OS X 10.4.3 (8F46). Now I can work around this by using vnode_open(), or calling my vnop_fs_open() and vnop_fs_close () functions directly, but I have a vnode_t and VNOP_OPEN() and VNOP_CLOSE() take a vnode_t. vnode_open() only takes a path, and calling myself directly requires building the vnop_open_args, etc structures (not that that is a big deal.) Also vnode_open() eventually just ends up calling VNOP_OPEN() anyways. This email sent to brady@apple.com This email sent to site_archiver@lists.apple.com