Processes' FIBs

[Julian Elischer]

On 1/13/12 4:27 AM, Kostik Belousov wrote:
> On Thu, Jan 12, 2012 at 10:44:51PM -0800, Julian Elischer wrote:
>> On 1/12/12 6:04 AM, Oliver Fromme wrote:
>>> Bjoern A. Zeeb wrote:
>>>   >   On 11. Jan 2012, at 15:06 , Oliver Fromme wrote:
>>>   >   >   I'm currently looking at the source code of ps, but adding
>>>   >   >   a field for the FIB isn't as trivial as I thought because
>>>   >   >   ps only sees struct kinfo_proc (via sysctl kern.proc.*)
>>>   >   >   which doesn't contain the FIB.  procstat does the same.
>>>   >   >
>>>   >   >   I'm currently trying to write a patch that copies p_fibnum
>>>   >   >   from struct proc to struct kinfo_proc (just like p_nice,
>>>   >   >   for example).  Does that make sense?  If so, does the patch
>>>   >   >   below look reasonable?  (I've made it on a stable/8 system,
>>>   >   >   but it should apply to 9 and 10, too.)
>>>   >
>>>   >   I am not sure it makes too much sense in ps.  It might make sense in
>>>   >   sockstat maybe?
>>>
>>> Well, every process has a default FIB number (p_fibnum in
>>> struct proc).  It is a property of the process, just like
>>> the nice value for example.  So I think it makes sense for
>>> ps to be able to display it if the user asks for it.  This
>>> is the piece of information that I need.
>>>
>>> On the other hand, sockstat displays open sockets only.
>>> Of course, an internet socket has a FIB number associated
>>> with it, too, so sockstat could display it.  But that
>>> would be a completely different piece of information,
>>> and it wouldn't solve the actual problem that I'm currently
>>> facing.
>>>
>> I hadn't considered that a process would want to see the fib of another.
>> but of course it makes sense.
>> I see no problem the the attached patch except that it doesn't fix the
>> man page for ps and setfib(2) or setfib(8) (or is it 1?)
>>
>> etc.
>> if there are no objections, I can add this when it has been polished..
> The patch misses compat32 bits and breaks compat32 ps/top.

I guess that would be "polishing" :-)
>>> Best regards
>>>    Oliver
>>>
>>> --- ./sys/sys/user.h.orig	2011-07-12 14:23:54.000000000 +0200
>>> +++ ./sys/sys/user.h	2012-01-11 15:35:50.000000000 +0100
>>> @@ -83,7 +83,7 @@
>>>    * it in two places: function fill_kinfo_proc in sys/kern/kern_proc.c and
>>>    * function kvm_proclist in lib/libkvm/kvm_proc.c .
>>>    */
>>> -#define	KI_NSPARE_INT	9
>>> +#define	KI_NSPARE_INT	8
>>>   #define	KI_NSPARE_LONG	12
>>>   #define	KI_NSPARE_PTR	6
>>>
>>> @@ -177,6 +177,7 @@
>>>   	 */
>>>   	char	ki_sparestrings[68];	/* spare string space */
>>>   	int	ki_spareints[KI_NSPARE_INT];	/* spare room for growth */
>>> +	int	ki_fibnum;		/* Default FIB number */
>>>   	u_int	ki_cr_flags;		/* Credential flags */
>>>   	int	ki_jid;			/* Process jail ID */
>>>   	int	ki_numthreads;		/* XXXKSE number of threads in total
>>>   	*/
>>> --- ./sys/kern/kern_proc.c.orig	2011-07-12 14:19:26.000000000 +0200
>>> +++ ./sys/kern/kern_proc.c	2012-01-11 15:36:22.000000000 +0100
>>> @@ -775,6 +775,7 @@
>>>   	kp->ki_swtime = (ticks - p->p_swtick) / hz;
>>>   	kp->ki_pid = p->p_pid;
>>>   	kp->ki_nice = p->p_nice;
>>> +	kp->ki_fibnum = p->p_fibnum;
>>>   	PROC_SLOCK(p);
>>>   	rufetch(p,&kp->ki_rusage);
>>>   	kp->ki_runtime = cputick2usec(p->p_rux.rux_runtime);
>>> --- ./bin/ps/keyword.c.orig	2011-07-12 13:42:48.000000000 +0200
>>> +++ ./bin/ps/keyword.c	2012-01-11 15:44:27.000000000 +0100
>>> @@ -90,6 +90,7 @@
>>>   		NULL, 0},
>>>   	{"etime", "ELAPSED", NULL, USER, elapsed, NULL, 12, 0, CHAR, NULL,
>>>   	0},
>>>   	{"f", "F", NULL, 0, kvar, NULL, 8, KOFF(ki_flag), INT, "x", 0},
>>> +	{"fib", "FIB", NULL, 0, kvar, NULL, 2, KOFF(ki_fibnum), INT, "d", 0},
>>>   	{"flags", "", "f", 0, NULL, NULL, 0, 0, CHAR, NULL, 0},
>>>   	{"ignored", "", "sigignore", 0, NULL, NULL, 0, 0, CHAR, NULL, 0},
>>>   	{"inblk", "INBLK", NULL, USER, rvar, NULL, 4, ROFF(ru_inblock), LONG,
>>> _______________________________________________
>>> freebsd-hackers at freebsd.org mailing list
>>> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
>>> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe at freebsd.org"
>>>
>> _______________________________________________
>> freebsd-net at freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-net
>> To unsubscribe, send any mail to "freebsd-net-unsubscribe at freebsd.org"