Date: Sun, 15 Jan 2012 19:38:49 -0800 From: Julian Elischer <julian@freebsd.org> To: Kostik Belousov <kostikbel@gmail.com> Cc: freebsd-hackers@freebsd.org, "Paul A. Procacci" <pprocacci@datapipe.com>, Oliver Fromme <olli@lurza.secnetix.de>, Oliver Fromme <olli@fromme.com>, freebsd-net@freebsd.org Subject: Re: Processes' FIBs Message-ID: <4F139BC9.6030805@freebsd.org> In-Reply-To: <20120113122749.GG31224@deviant.kiev.zoral.com.ua> References: <201201121404.q0CE4ItN066102@lurza.secnetix.de> <4F0FD2E3.1060607@freebsd.org> <20120113122749.GG31224@deviant.kiev.zoral.com.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
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@freebsd.org mailing list
>>> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
>>> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"
>>>
>> _______________________________________________
>> freebsd-net@freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-net
>> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4F139BC9.6030805>