Alfred Perlstein wrote:
> On Sun, 15 Aug 1999, John Polstra wrote:
>>
>> 1. I have a pointer to a vnode and I want to get the corresponding
>> dev_t and inode number. Is there a non-sleazy way to do that other
>> than calling vn_stat?
>
> use vn_todev from "vfs_subr.c" ~line 2970 of 2976 if you just
> need the dev_t.
Thanks. I didn't make it clear in my question, but I want the dev_t
of the filesystem containing the file (st_dev rather than st_rdev).
> but you may wind up needing the GETATTR call for the inode lookup.
OK.
>> 2. The first action of vn_stat is to call VOP_GETATTR. VOP_GETATTR(9)
>> says, "The file should not be locked on entry." But when stat calls
>> vn_stat, the vnode is locked. Which is correct -- or doesn't it
>> matter?
>
> the lookup at the begininngin of the stat() call's side-effect is to
> lock the vnode it returns but kern/vnode.src seems to indicate
> that the vnode's locking state doesn't matter...
Ah, good. That helps.
> so does the various states that vnodes are in when called from
> vfs_syscalls, such as the lseek syscall.
Yes, and fstat doesn't lock it either.
> it's slighly confusing, if the vnode is locked for "access" calls
> why is it not locked for attribute calls?
I'm confused too. :-)
John
---
John Polstra [EMAIL PROTECTED]
John D. Polstra & Co., Inc. Seattle, Washington USA
"No matter how cynical I get, I just can't keep up." -- Nora Ephron
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message