Re: ps_strings

2013-08-18 Thread Super Bisquit
http://forums.freebsd.org/showthread.php?p=228128

http://www.dolphinburger.com/cgi-bin/bsdi-man?proto=1.1query=ps_stringsmsection=5apropos=0


On Sat, Aug 17, 2013 at 2:00 PM, Carlos Jacobo Puga Medina 
cjpug...@gmail.com wrote:

 Hi people,

 Despite I made a request not long ago[1], I'm looking for documentation to
 create the ps_strings structure man page because isn't covered in other man
 page such e.g. execve(2). So, I'm interested to know for what it's
 currently used.

 Any input will be appreciated.

 --CJPM


 [1] http://lists.freebsd.org/pipermail/freebsd-doc/2013-July/022422.html.
 ___
 freebsd-hackers@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
 To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org

___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org


Re: ps_strings

2013-08-18 Thread Fernando ApesteguĂ­a
On Sat, Aug 17, 2013 at 8:00 PM, Carlos Jacobo Puga Medina 
cjpug...@gmail.com wrote:

 Hi people,

 Despite I made a request not long ago[1], I'm looking for documentation to
 create the ps_strings structure man page because isn't covered in other man
 page such e.g. execve(2). So, I'm interested to know for what it's
 currently used.

 Any input will be appreciated.


It is for storing the vectors for program arguments and environment. They
are placed at the top of the process stack. This information is used for
instance, by the ps(1) program via the kvm(3) interface. The same structure
is accesed from the linuxolator (linprocfs.c) to implement the environ
pseudo-file.

In the first case (libkvm interface) a sysctl is used to retrieve that
information. Anyway, both paths end up calling proc_getenvv/proc_getargv in
kern_proc.c. Those are selectors for the function that does the actual
work: get_ps_strings. This function first calls get_proc_vector to copy the
relevant memory area (look for vptr in the case statement) from the
process stack and then it iterates to extract all the strings.

Have a look at the comment in sys/exec.h

All this is probably not needed for the man page, but hey, just my two
cents.





 --CJPM


 [1] http://lists.freebsd.org/pipermail/freebsd-doc/2013-July/022422.html.
 ___
 freebsd-hackers@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
 To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org

___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org


Re: ps_strings

2013-08-18 Thread Chris Torek
Despite I made a request not long ago[1], I'm looking for
documentation to create the ps_strings structure man page because
isn't covered in other man page such e.g.  execve(2). So, I'm
interested to know for what it's currently used.

Nothing.  (Well, backwards compatibility, depending on how far
backwards you go.)

I invented the ps_strings struct a long time ago, about the same
time libkvm was new.

Some background: There was code in ps that would grub around in
the top stack page of each user process and extract the argv
strings.  This code knew how execve() worked inside the kernel
(copying the argv and environment strings into the user stack,
just below the signal trampoline code, and then setting up argv
and envp pointers and invoking the libc/csu start program code
at the entry point).

We moved this grub-around-in-process-stack code to libkvm, but it
was still rather horrible code.

Meanwhile, we had programs like sendmail that would set their
process title by saving, in some secret global variable, the
space where the argv array itself and its strings lived, and
then -- in setproctitle() -- carefully overwrite it.  Of course
there was only as much room there as the kernel provided, based on
the actual strings at execve() time.

I figured this would all be much cleaner if we created a small
data structure, namely ps_strings, to hold the information that
libkvm would extract (and hence, ps would show).  It would be
simpler than the original code, because the ps_strings structure
lived at a fixed, well known user-space virtual address (the same
VA in every process).  Moreover, a user program (like sendmail)
could modify the ps_strings data to point to any other user-space
area: libkvm was smart enough to extract arbitrary data (and
verify the validity of the address too).  This removed the limit
on how large a process title could be.

FreeBSD now, however, uses a per-process p_args field in the
proc structure, with sysctl()s to set and get p_args.  (I had
nothing to do with this new code, but I approve, as if anyone
cares. :-) )  This removes the fixed-virtual-address limitation.
The cost is a bit more kernel code (for the sysctl()s) and this
per-process data, but there is no more messing-about with where
is ps_strings in this memory-layout / emulation etc.  (Meanwhile
libkvm still retrieves the arguments.  It just does it now with
sysctl().)

Chris
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org