Date: Mon, 21 Feb 2005 19:17:35 -0800 (PST) From: Doug White <dwhite@gumbysoft.com> To: Pascal Hofstee <caelian@gmail.com> Cc: FreeBSD Current <freebsd-current@freebsd.org> Subject: Re: GNUstep and libkvm Message-ID: <20050221191111.R89025@carver.gumbysoft.com> In-Reply-To: <d8a0b76205022013507a810723@mail.gmail.com> References: <d8a0b76205022013507a810723@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 20 Feb 2005, Pascal Hofstee wrote: > A while ago i initiated a thread on hackers@ requesting additional > information regarding a known issue with the gnustep-gui port "needing > /proc" even when gnustep-base itself (which in turn is used by -gui) > was compiled without procfs support. > > The results of my findings can be found in the following list-archive entries: > > http://www.mail-archive.com/freebsd-hackers@freebsd.org/msg49357.html > http://www.mail-archive.com/freebsd-hackers@freebsd.org/msg49577.html > > Short summary is the kvm_getargv function seems to trigger a kvm_uread > call when the length of "command + argumentlist" exceeds the value of > kern.ps_arg_cache_limit. > > This kvm_uread call is responsible for the observed /proc groveling. > I had hoped to acquire some additional information on how to properlly > debug libkvm in GDB and if this /proc dependency is intended behavior. You could just read the code :-) libkvm is a userspace library, source is in src/lib/libkvm. > To me personally (though i am not a kernel hacker) it doens't really > make sense to have libkvm (which is intended to be a 'replacement' for > /proc to my understanding) intenrally depend on the same system it's > trying to 'replace', though I noticed from the manpages that the > kvm_getargv function doesn't really belong in libkvm. libkvm is actually "legacy"; /proc came after it, but we've been moving away from requiring procfs since its skilled at opening security holes. libkvm originally needed to grovel in /dev/kmem and much of that has migrated to using special-purpose sysctls. > Can anybody at least either confirm wether or not this is > - intended behavior > - a bug and a proper PR should likely be created ps(1) sets up some flags to avoid needing it on -CURRENT and RELENG_5; you might reference that for how to use the sysctl to read the ps information. There is some information that is only available via /proc, though; the process environment is an easy example (and ps throws an error if you specify -e and procfs isn't available). -- Doug White | FreeBSD: The Power to Serve dwhite@gumbysoft.com | www.FreeBSD.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050221191111.R89025>