Re: libgtop port and v_tag changes
On 29-Oct-2002 Joe Marcus Clarke wrote: On Mon, 2002-10-28 at 16:37, John Baldwin wrote: On 28-Oct-2002 Joe Marcus Clarke wrote: On Mon, 2002-10-28 at 16:27, John Baldwin wrote: On 28-Oct-2002 Terry Lambert wrote: John Baldwin wrote: I mean, do you know what libgtop is used for? It's used to draw little applets that display load averages and other silly system monitor stuff in small spaces in GUI's. It seems to work quite happily w/o any inode numbers or dev_t's for non-UFS filesystems. I just don't see why some little graphical applet displaying a load average or disk usage or ethernet device usage needs the inode number and dev_t of vnode's in the kernel. I mean, geez. To build little applets that activate a flashing red light when certain files are written? Why do you need the inode number to do that. Just kqueue on the file itself using a regular fd, and in that case you can stat(2) the file if you really need the i-node number. You don't need to use libkvm to actually go read the kernel to find this info! You're probably right. But without waiting to re-architect libgtop, I think the immediate problem needs to be fixed. Shall I just commit my original patch that uses libkvm? Use v_cachedid and v_cachedfs for all VREG vnodes. Then you don't need to even go near v_tag. This is fewer kvm_read()'s. If stable has the v_cachedid then it should be using that instead of reading in UFS inodes as well. This look okay? Yep, thanks. :) -- 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
Re: libgtop port and v_tag changes
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
Re: libgtop port and v_tag changes
John Baldwin wrote: 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? The user will, if they try to use find -inum to identify the file name associated with it, since the vnode number is useless for this purpose, and the inode number is not... particularly if the information is being obtained from a log file. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: libgtop port and v_tag changes
On Mon, 28 Oct 2002, Terry Lambert wrote: John Baldwin wrote: 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? The user will, if they try to use find -inum to identify the file name associated with it, since the vnode number is useless for this purpose, and the inode number is not... particularly if the information is being obtained from a log file. Terry is right. It needs to be the same inode number that is reported by stat and getdirents. It's unfortunate that you can't do a getattr or stat based on the address of the vnode. I have actually used and relied on this behavior in the past. Not specifically with gtop though. Cheers, Jeff To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: libgtop port and v_tag changes
On 28-Oct-2002 Terry Lambert wrote: John Baldwin wrote: 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? The user will, if they try to use find -inum to identify the file name associated with it, since the vnode number is useless for this purpose, and the inode number is not... particularly if the information is being obtained from a log file. Erm, the v_cachedid is a cache of the inode number we get from VOP_GETATTR(). In the case of ufs it is the inode number. Really though, does anyone that uses 'libgtop' (please, let's get our priorities straight here) actually _use_ this? Sheesh, does anyone actually _use_ libgtop against kernel core dumps? If not then it shouldn't be groveling around in the kernel fondling implementation details. Instead, it should be using stat(2), or at the worst using a sysctl to get xvnode structures. -- 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
Re: libgtop port and v_tag changes
On 28-Oct-2002 Jeff Roberson wrote:
On Mon, 28 Oct 2002, Terry Lambert wrote:
John Baldwin wrote:
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?
The user will, if they try to use find -inum to identify the
file name associated with it, since the vnode number is useless
for this purpose, and the inode number is not... particularly
if the information is being obtained from a log file.
Terry is right. It needs to be the same inode number that is reported by
stat and getdirents. It's unfortunate that you can't do a getattr or stat
based on the address of the vnode. I have actually used and relied on this
behavior in the past. Not specifically with gtop though.
if ((error = VOP_GETATTR(vp, vap, cred, td)) == 0) {
vp-v_cachedfs = vap-va_fsid;
vp-v_cachedid = vap-va_fileid;
}
and the only other place it is set:
vap = vattr;
error = VOP_GETATTR(vp, vap, active_cred, td);
if (error)
return (error);
vp-v_cachedfs = vap-va_fsid;
vp-v_cachedid = vap-va_fileid;
--
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
Re: libgtop port and v_tag changes
On Mon, 28 Oct 2002, John Baldwin wrote:
Terry is right. It needs to be the same inode number that is reported by
stat and getdirents. It's unfortunate that you can't do a getattr or stat
based on the address of the vnode. I have actually used and relied on this
behavior in the past. Not specifically with gtop though.
if ((error = VOP_GETATTR(vp, vap, cred, td)) == 0) {
vp-v_cachedfs = vap-va_fsid;
vp-v_cachedid = vap-va_fileid;
}
and the only other place it is set:
vap = vattr;
error = VOP_GETATTR(vp, vap, active_cred, td);
if (error)
return (error);
vp-v_cachedfs = vap-va_fsid;
vp-v_cachedid = vap-va_fileid;
Oh, right you are. I was thinking of v_id. The cachedfs/id have been
added recently.
Cheers,
Jeff
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: libgtop port and v_tag changes
On 28-Oct-2002 John Baldwin wrote: On 28-Oct-2002 Terry Lambert wrote: John Baldwin wrote: 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? The user will, if they try to use find -inum to identify the file name associated with it, since the vnode number is useless for this purpose, and the inode number is not... particularly if the information is being obtained from a log file. Erm, the v_cachedid is a cache of the inode number we get from VOP_GETATTR(). In the case of ufs it is the inode number. Really though, does anyone that uses 'libgtop' (please, let's get our priorities straight here) actually _use_ this? Sheesh, does anyone actually _use_ libgtop against kernel core dumps? If not then it shouldn't be groveling around in the kernel fondling implementation details. Instead, it should be using stat(2), or at the worst using a sysctl to get xvnode structures. I mean, do you know what libgtop is used for? It's used to draw little applets that display load averages and other silly system monitor stuff in small spaces in GUI's. It seems to work quite happily w/o any inode numbers or dev_t's for non-UFS filesystems. I just don't see why some little graphical applet displaying a load average or disk usage or ethernet device usage needs the inode number and dev_t of vnode's in the kernel. I mean, geez. -- 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
Re: libgtop port and v_tag changes
John Baldwin wrote: Sheesh, does anyone actually _use_ libgtop against kernel core dumps? If not then it shouldn't be groveling around in the kernel fondling implementation details. Instead, it should be using stat(2), or at the worst using a sysctl to get xvnode structures. As an alternative suggestion, how about moving away from having only data interfaces for useful information, so this is never an issue, ever again? -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: libgtop port and v_tag changes
John Baldwin wrote: I mean, do you know what libgtop is used for? It's used to draw little applets that display load averages and other silly system monitor stuff in small spaces in GUI's. It seems to work quite happily w/o any inode numbers or dev_t's for non-UFS filesystems. I just don't see why some little graphical applet displaying a load average or disk usage or ethernet device usage needs the inode number and dev_t of vnode's in the kernel. I mean, geez. To build little applets that activate a flashing red light when certain files are written? -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: libgtop port and v_tag changes
On 28-Oct-2002 Terry Lambert wrote: John Baldwin wrote: I mean, do you know what libgtop is used for? It's used to draw little applets that display load averages and other silly system monitor stuff in small spaces in GUI's. It seems to work quite happily w/o any inode numbers or dev_t's for non-UFS filesystems. I just don't see why some little graphical applet displaying a load average or disk usage or ethernet device usage needs the inode number and dev_t of vnode's in the kernel. I mean, geez. To build little applets that activate a flashing red light when certain files are written? Why do you need the inode number to do that. Just kqueue on the file itself using a regular fd, and in that case you can stat(2) the file if you really need the i-node number. You don't need to use libkvm to actually go read the kernel to find this info! -- 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
Re: libgtop port and v_tag changes
On Mon, 2002-10-28 at 16:27, John Baldwin wrote: On 28-Oct-2002 Terry Lambert wrote: John Baldwin wrote: I mean, do you know what libgtop is used for? It's used to draw little applets that display load averages and other silly system monitor stuff in small spaces in GUI's. It seems to work quite happily w/o any inode numbers or dev_t's for non-UFS filesystems. I just don't see why some little graphical applet displaying a load average or disk usage or ethernet device usage needs the inode number and dev_t of vnode's in the kernel. I mean, geez. To build little applets that activate a flashing red light when certain files are written? Why do you need the inode number to do that. Just kqueue on the file itself using a regular fd, and in that case you can stat(2) the file if you really need the i-node number. You don't need to use libkvm to actually go read the kernel to find this info! You're probably right. But without waiting to re-architect libgtop, I think the immediate problem needs to be fixed. Shall I just commit my original patch that uses libkvm? Joe -- PGP Key : http://www.marcuscom.com/pgp.asc To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: libgtop port and v_tag changes
On 28-Oct-2002 Joe Marcus Clarke wrote: On Mon, 2002-10-28 at 16:27, John Baldwin wrote: On 28-Oct-2002 Terry Lambert wrote: John Baldwin wrote: I mean, do you know what libgtop is used for? It's used to draw little applets that display load averages and other silly system monitor stuff in small spaces in GUI's. It seems to work quite happily w/o any inode numbers or dev_t's for non-UFS filesystems. I just don't see why some little graphical applet displaying a load average or disk usage or ethernet device usage needs the inode number and dev_t of vnode's in the kernel. I mean, geez. To build little applets that activate a flashing red light when certain files are written? Why do you need the inode number to do that. Just kqueue on the file itself using a regular fd, and in that case you can stat(2) the file if you really need the i-node number. You don't need to use libkvm to actually go read the kernel to find this info! You're probably right. But without waiting to re-architect libgtop, I think the immediate problem needs to be fixed. Shall I just commit my original patch that uses libkvm? Use v_cachedid and v_cachedfs for all VREG vnodes. Then you don't need to even go near v_tag. This is fewer kvm_read()'s. If stable has the v_cachedid then it should be using that instead of reading in UFS inodes as well. -- 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
Re: libgtop port and v_tag changes
On Mon, 2002-10-28 at 16:37, John Baldwin wrote: On 28-Oct-2002 Joe Marcus Clarke wrote: On Mon, 2002-10-28 at 16:27, John Baldwin wrote: On 28-Oct-2002 Terry Lambert wrote: John Baldwin wrote: I mean, do you know what libgtop is used for? It's used to draw little applets that display load averages and other silly system monitor stuff in small spaces in GUI's. It seems to work quite happily w/o any inode numbers or dev_t's for non-UFS filesystems. I just don't see why some little graphical applet displaying a load average or disk usage or ethernet device usage needs the inode number and dev_t of vnode's in the kernel. I mean, geez. To build little applets that activate a flashing red light when certain files are written? Why do you need the inode number to do that. Just kqueue on the file itself using a regular fd, and in that case you can stat(2) the file if you really need the i-node number. You don't need to use libkvm to actually go read the kernel to find this info! You're probably right. But without waiting to re-architect libgtop, I think the immediate problem needs to be fixed. Shall I just commit my original patch that uses libkvm? Use v_cachedid and v_cachedfs for all VREG vnodes. Then you don't need to even go near v_tag. This is fewer kvm_read()'s. If stable has the v_cachedid then it should be using that instead of reading in UFS inodes as well. -stable doesn't have those members :-(. So the ifdef's would need to remain. Joe -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ -- PGP Key : http://www.marcuscom.com/pgp.asc To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: libgtop port and v_tag changes
On Mon, 28 Oct 2002, John Baldwin wrote: On 28-Oct-2002 Joe Marcus Clarke wrote: You're probably right. But without waiting to re-architect libgtop, I think the immediate problem needs to be fixed. Shall I just commit my original patch that uses libkvm? Use v_cachedid and v_cachedfs for all VREG vnodes. Then you don't need to even go near v_tag. This is fewer kvm_read()'s. If stable has the v_cachedid then it should be using that instead of reading in UFS inodes as well. I plan to go through and fix fstat(1) to be a better example once I have a little time. It's lower on my priority list than the SCSI stuff though. -Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: libgtop port and v_tag changes
John Baldwin wrote: To build little applets that activate a flashing red light when certain files are written? Why do you need the inode number to do that. Just kqueue on the file itself using a regular fd, and in that case you can stat(2) the file if you really need the i-node number. You don't need to use libkvm to actually go read the kernel to find this info! Maybe they have to check a SYSV message queue at the same time, but can't use a blocking kqueue call because my System V message queue kqueue patches were never committed. 8-). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: libgtop port and v_tag changes
On Mon, 2002-10-28 at 16:37, John Baldwin wrote:
On 28-Oct-2002 Joe Marcus Clarke wrote:
On Mon, 2002-10-28 at 16:27, John Baldwin wrote:
On 28-Oct-2002 Terry Lambert wrote:
John Baldwin wrote:
I mean, do you know what libgtop is used for? It's used to draw
little applets that display load averages and other silly system
monitor stuff in small spaces in GUI's. It seems to work quite
happily w/o any inode numbers or dev_t's for non-UFS filesystems.
I just don't see why some little graphical applet displaying a load
average or disk usage or ethernet device usage needs the inode
number and dev_t of vnode's in the kernel. I mean, geez.
To build little applets that activate a flashing red light when
certain files are written?
Why do you need the inode number to do that. Just kqueue on the
file itself using a regular fd, and in that case you can stat(2)
the file if you really need the i-node number. You don't need
to use libkvm to actually go read the kernel to find this info!
You're probably right. But without waiting to re-architect libgtop, I
think the immediate problem needs to be fixed. Shall I just commit my
original patch that uses libkvm?
Use v_cachedid and v_cachedfs for all VREG vnodes. Then you don't
need to even go near v_tag. This is fewer kvm_read()'s. If stable
has the v_cachedid then it should be using that instead of reading
in UFS inodes as well.
This look okay?
Joe
--
John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/
Power Users Use the Power to Serve! - http://www.FreeBSD.org/
--
PGP Key : http://www.marcuscom.com/pgp.asc
--- procmap.c.orig Mon Jun 10 17:34:42 2002
+++ procmap.c Sat Oct 26 01:20:26 2002
@@ -33,7 +33,11 @@
#include sys/proc.h
#include sys/resource.h
#include vm/vm_object.h
+#if (__FreeBSD_version = 400011)
+#include vm/vm.h
+#else
#include vm/vm_prot.h
+#endif
#include vm/vm_map.h
#include sys/vnode.h
@@ -91,8 +95,9 @@
glibtop_map_entry *maps;
#if defined __FreeBSD__
struct vnode vnode;
+#if __FreeBSD_version 500039
struct inode inode;
- struct mount mount;
+#endif
#endif
int count, i = 0;
int update = 0;
@@ -114,7 +119,11 @@
/* Now we get the memory maps. */
if (kvm_read (server-machine.kd,
+#if (__FreeBSD_version = 500013)
+ (unsigned long) pinfo [0].ki_vmspace,
+#else
(unsigned long) pinfo [0].kp_proc.p_vmspace,
+#endif
(char *) vmspace, sizeof (vmspace)) != sizeof (vmspace))
glibtop_error_io_r (server, kvm_read (vmspace));
@@ -244,6 +253,15 @@
vnode, sizeof (vnode)) != sizeof (vnode))
glibtop_error_io_r (server, kvm_read (vnode));
+#if __FreeBSD_version = 500039
+ switch (vnode.v_type) {
+ case VREG:
+ maps [i-1].inode = vnode.v_cachedid;
+ maps [i-1].device = vnode.v_cachedfs;
+ default:
+ continue;
+ }
+#else
if ((vnode.v_type != VREG) || (vnode.v_tag != VT_UFS) ||
!vnode.v_data) continue;
@@ -252,13 +270,9 @@
inode, sizeof (inode)) != sizeof (inode))
glibtop_error_io_r (server, kvm_read (inode));
- if (kvm_read (server-machine.kd,
- (unsigned long) vnode.v_mount,
- mount, sizeof (mount)) != sizeof (mount))
- glibtop_error_io_r (server, kvm_read (mount));
-
maps [i-1].inode = inode.i_number;
maps [i-1].device = inode.i_dev;
+#endif
#endif
} while (entry.next != first);
Re: libgtop port and v_tag changes
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.
Joe
--
John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/
Power Users Use the Power to Serve! - http://www.FreeBSD.org/
--
PGP Key : http://www.marcuscom.com/pgp.asc
signature.asc
Description: This is a digitally signed message part
Re: libgtop port and v_tag changes
On 24 Oct 2002, Joe Marcus Clarke wrote: I committed my patch to libgtop and libgtop2 a while ago. It should work on both -CURRENT, not so -CURRENT, and -stable. Checkout patch-ah in libgtop/files. Works like a champ on -CURRENT from Monday. Thanks for taking care of that. -Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: libgtop port and v_tag changes
On 25-Oct-2002 Joe Marcus Clarke wrote: On Thu, 2002-10-24 at 19:13, Nate Lawson wrote: On Thu, 24 Oct 2002, John Baldwin wrote: Speaking of v_tag, can you fix the devel/libgtop port on current? This is the patch I used to get it building the other day: cat patch-sysdeps_freebsd_procmap.c --- sysdeps/freebsd/procmap.c.orig Tue Oct 15 20:00:35 2002 +++ sysdeps/freebsd/procmap.c Tue Oct 15 20:05:54 2002 @@ -251,6 +251,7 @@ vnode, sizeof (vnode)) != sizeof (vnode)) glibtop_error_io_r (server, kvm_read (vnode)); +#if __FreeBSD_version 50 if ((vnode.v_type != VREG) || (vnode.v_tag != VT_UFS) || !vnode.v_data) continue; @@ -261,6 +262,7 @@ maps [i-1].inode = inode.i_number; maps [i-1].device = inode.i_dev; +#endif #endif } while (entry.next != first); -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ I assume Joe has a better version he planned to commit as referenced by this email: [EMAIL PROTECTED] I like his patch better because it still handles the non CURRENT case. Joe? I committed my patch to libgtop and libgtop2 a while ago. It should work on both -CURRENT, not so -CURRENT, and -stable. Checkout patch-ah in libgtop/files. Works like a champ on -CURRENT from Monday. It does?! v_tag is a pointer to kernel memory, you can't read that from userland! You would get a SIGSEGV and die as soon as you do the 'strcmp()'. That's why I #ifdef'd the whole chunk out. Also, just for the record, my code didn't break the non CURRENT case. :) -- 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
Re: libgtop port and v_tag changes
On Fri, 25 Oct 2002, Joe Marcus Clarke wrote: On Fri, 25 Oct 2002, John Baldwin wrote: It does?! v_tag is a pointer to kernel memory, you can't read that from userland! You would get a SIGSEGV and die as soon as you do the 'strcmp()'. That's why I #ifdef'd the whole chunk out. Also, just for the record, my code didn't break the non CURRENT case. :) Sorry, mispoke. Your code didn't fix the CURRENT case. :) Gak! If Julian didn't pound kvm_read into my head before, I've got it now. Sure, it compiles, buth then what :-}. Thanks for the pointer. Attached is a patch to libgtop2, but should be similar if not identical to what's needed for libgtop. Let me know if this looks a little better. Thanks. Joe For another working and tested example, see rev 1.45 of fstat.c (usr.bin/fstat). -Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: libgtop port and v_tag changes
On 25-Oct-2002 Joe Marcus Clarke wrote:
On Fri, 25 Oct 2002, John Baldwin wrote:
On 25-Oct-2002 Joe Marcus Clarke wrote:
On Thu, 2002-10-24 at 19:13, Nate Lawson wrote:
On Thu, 24 Oct 2002, John Baldwin wrote:
Speaking of v_tag, can you fix the devel/libgtop port on current?
This is the patch I used to get it building the other day:
cat patch-sysdeps_freebsd_procmap.c
--- sysdeps/freebsd/procmap.c.orig Tue Oct 15 20:00:35 2002
+++ sysdeps/freebsd/procmap.c Tue Oct 15 20:05:54 2002
@@ -251,6 +251,7 @@
vnode, sizeof (vnode)) != sizeof (vnode))
glibtop_error_io_r (server, kvm_read (vnode));
+#if __FreeBSD_version 50
if ((vnode.v_type != VREG) || (vnode.v_tag != VT_UFS) ||
!vnode.v_data) continue;
@@ -261,6 +262,7 @@
maps [i-1].inode = inode.i_number;
maps [i-1].device = inode.i_dev;
+#endif
#endif
} while (entry.next != first);
--
John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/
Power Users Use the Power to Serve! - http://www.FreeBSD.org/
I assume Joe has a better version he planned to commit as referenced by
this email:
[EMAIL PROTECTED]
I like his patch better because it still handles the non CURRENT case.
Joe?
I committed my patch to libgtop and libgtop2 a while ago. It should
work on both -CURRENT, not so -CURRENT, and -stable. Checkout patch-ah
in libgtop/files. Works like a champ on -CURRENT from Monday.
It does?! v_tag is a pointer to kernel memory, you can't read that
from userland! You would get a SIGSEGV and die as soon as you do the
'strcmp()'. That's why I #ifdef'd the whole chunk out. Also, just for
the record, my code didn't break the non CURRENT case. :)
Gak! If Julian didn't pound kvm_read into my head before, I've got it
now. Sure, it compiles, buth then what :-}. Thanks for the pointer.
Attached is a patch to libgtop2, but should be similar if not identical to
what's needed for libgtop. Let me know if this looks a little better.
Thanks.
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.
--
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
libgtop port and v_tag changes
On Thu, 24 Oct 2002, John Baldwin wrote: Speaking of v_tag, can you fix the devel/libgtop port on current? This is the patch I used to get it building the other day: cat patch-sysdeps_freebsd_procmap.c --- sysdeps/freebsd/procmap.c.orig Tue Oct 15 20:00:35 2002 +++ sysdeps/freebsd/procmap.c Tue Oct 15 20:05:54 2002 @@ -251,6 +251,7 @@ vnode, sizeof (vnode)) != sizeof (vnode)) glibtop_error_io_r (server, kvm_read (vnode)); +#if __FreeBSD_version 50 if ((vnode.v_type != VREG) || (vnode.v_tag != VT_UFS) || !vnode.v_data) continue; @@ -261,6 +262,7 @@ maps [i-1].inode = inode.i_number; maps [i-1].device = inode.i_dev; +#endif #endif } while (entry.next != first); -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ I assume Joe has a better version he planned to commit as referenced by this email: [EMAIL PROTECTED] I like his patch better because it still handles the non CURRENT case. Joe? -Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: libgtop port and v_tag changes
On Thu, 2002-10-24 at 19:13, Nate Lawson wrote: On Thu, 24 Oct 2002, John Baldwin wrote: Speaking of v_tag, can you fix the devel/libgtop port on current? This is the patch I used to get it building the other day: cat patch-sysdeps_freebsd_procmap.c --- sysdeps/freebsd/procmap.c.orig Tue Oct 15 20:00:35 2002 +++ sysdeps/freebsd/procmap.c Tue Oct 15 20:05:54 2002 @@ -251,6 +251,7 @@ vnode, sizeof (vnode)) != sizeof (vnode)) glibtop_error_io_r (server, kvm_read (vnode)); +#if __FreeBSD_version 50 if ((vnode.v_type != VREG) || (vnode.v_tag != VT_UFS) || !vnode.v_data) continue; @@ -261,6 +262,7 @@ maps [i-1].inode = inode.i_number; maps [i-1].device = inode.i_dev; +#endif #endif } while (entry.next != first); -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ I assume Joe has a better version he planned to commit as referenced by this email: [EMAIL PROTECTED] I like his patch better because it still handles the non CURRENT case. Joe? I committed my patch to libgtop and libgtop2 a while ago. It should work on both -CURRENT, not so -CURRENT, and -stable. Checkout patch-ah in libgtop/files. Works like a champ on -CURRENT from Monday. Joe -Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message -- PGP Key : http://www.marcuscom.com/pgp.asc signature.asc Description: This is a digitally signed message part
