Re: VNOP_OPEN/VNOP_CLOSE linking issue
Re: VNOP_OPEN/VNOP_CLOSE linking issue
- Subject: Re: VNOP_OPEN/VNOP_CLOSE linking issue
- From: Marek Kozubal <email@hidden>
- Date: Thu, 17 Nov 2005 15:06:30 -0500 (EST)
On Thu, 17 Nov 2005, Don Brady wrote:
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.
Ah, this is different than pre-Tiger worked, as the VOP_ functions assumed
locked states were already set for them. Clearly the VNOP_'s aren't a
direct replacement for VOP_...
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'm in getxattr() and I am trying to read the resource fork off the disk,
I need to call OPEN & CLOSE to setup some state, and can't just call
VNOP_READ on the vnode directly like HFS does.
Knowing this, I'll build the vnop_*_desc for open and close and call
myself directly.
Thanks
-Marek
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden