On 26-Oct-2002 Joe Marcus Clarke wrote:
> On Fri, 2002-10-25 at 14:15, John Baldwin wrote:
>> Well, here's the thing. If libgtop is intended to be used only with live
>> kernels then it might be a better idea to use xvnode's that you get with
>> from the kernel. Alternatively, you could grab the inode and dev number
>> the same way the sysctl handler does:
>>
>> switch (vp->v_type) {
>> case VREG:
>> case VDIR:
>> case VLNK:
>> xvn[n].xv_dev = vp->v_cachedfs;
>> xvn[n].xv_ino = vp->v_cachedid;
>>
>> i.e., you could look at those members of struct vnode instead of trying
>> to dig into the details of a UFS inode structure in v_data. This
>> would remove the need to look at v_tag at all.
>
> I can certainly do it this way, but would it be equivalent to the
> existing code? It doesn't seem like it would be. At least using the
> kvm_read method, we get similar behavior for both -stable and -CURRENT.
> Correct me if I'm wrong, but the current code is looking at UFS inodes,
> where as you're suggesting to look at generic vnodes.
Yes. This means that you don't need to even look at v_tag to see
if it is a UFS vnode or not. What does libgtop want with
device and inode numbers anways? Does it actually do anything
useful with them or does it just print them somewhere? Is a user
going to care if the inode number was obtained from the vnode
or if we groveled in the internals of UFS to find it?
--
John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!" - http://www.FreeBSD.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
