Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 31 Jan 2001 02:29:17 +0900 (JST)
From:      Hajimu UMEMOTO <ume@mahoroba.org>
To:        kris@obsecurity.org
Cc:        cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org
Subject:   Re: cvs commit: ports/sysutils/gkrellm Makefile distinfo
Message-ID:  <20010131.022917.85414014.ume@mahoroba.org>
In-Reply-To: <20010130085013.B51965@xor.obsecurity.org>
References:  <200101301206.f0UC6xw19361@freefall.freebsd.org> <20010130085013.B51965@xor.obsecurity.org>

next in thread | previous in thread | raw e-mail | index | archive | help
Hi,

>>>>> On Tue, 30 Jan 2001 08:50:13 -0800
>>>>> Kris Kennaway <kris@obsecurity.org> said:

>   If linprocfs is available, this version works with no extra kmem
>   privilege under 5.0-CURRENT.  In this time, since we cannot obtain
>   swap information by safety way, when gkrellm cannot access kmem,
>   gkrellm tries to use linprocfs for swap information.

kris> Argh, the slippery slope begins!

Actually, I don't want to use linprocfs.  However, I believe secure is
important than don't use linprocfs.  Please attention that GKrellM is
GTK+ apps.  It's still workaround.  Once swap information can be
obtained via safety way, I'll wipe out using linprocfs.

kris> We need to make this information available via regular procfs (you
kris> sure it's not already?) Native applications *should not* need to use
kris> linprocfs.

Linux's /proc is far from BSD's /proc.  It is rather close to kernfs.
I think making /proc closer to Linux's /proc is not good idea.  The
lacking information are ksw_used and ksw_total of struct kvm_swap
obtained via kvm_getswapinfo().  I wonder these can be obtained via
sysctl().

--
Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan
ume@mahoroba.org  ume@bisd.hitachi.co.jp  ume@{,jp.}FreeBSD.org
http://www.imasy.org/~ume/


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010131.022917.85414014.ume>