ps_strings
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"
ps_strings
First, I want to thank Super Bisquit, Fernando and Chris for their inputs. Second, the ps_strings struct remains in use to report information about the running process back to the user and operating system, and as such enriches the content of the FreeBSD kernel, so it's worth create this man page. However, I'll consult this with a member of the doc team so that everything is in order. Attentively --CJPM ___ 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
http://forums.freebsd.org/showthread.php?p=228128 http://www.dolphinburger.com/cgi-bin/bsdi-man?proto=1.1&query=ps_strings&msection=5&apropos=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
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
>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"
Re: ps_strings
On Sun, Aug 18, 2013 at 04:05:11PM -0600, Chris Torek wrote: > 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().) Yes, p_args caches the arguments, but not always. Right now, kernel does not cache arguments if the string is longer than 256 bytes. Look for ps_arg_cache_limit in kern_exec.c. setproctitle() always informs the kernel with sysctl and sets the pointers in ps_strings. kern.proc.args sysctl first tries the p_args, and falls back to reading ps_strings and following the pointers if p_args is NULL. pgpfNuTdP710t.pgp Description: PGP signature
Re: ps_strings
>Yes, p_args caches the arguments, but not always. Right now, kernel >does not cache arguments if the string is longer than 256 bytes. Look >for ps_arg_cache_limit in kern_exec.c. > >setproctitle() always informs the kernel with sysctl and sets the >pointers in ps_strings. kern.proc.args sysctl first tries the p_args, >and falls back to reading ps_strings and following the pointers if >p_args is NULL. Ah, that's what I get for scanning through years of updates too fast. :-) This seems a bit of a "worst of both worlds": there's now some extra kernel code for poking through the ps_strings and the pointer-vectors (this code is no longer in libkvm at all -- that was where I looked first and found the sysctl), for the "no p_args" case. It seems like perhaps there could just be a sysctl to return the ps_strings address, and leave the "follow argv pointers" code in libkvm, if there is to be code for that. (The kernel saves a bit of time for the presumably-usual "p_args not NULL" case, and finding the location of the ps_strings structure when it *is* used is automatically correct. So that part is a straight-up improvement, at least.) Not that big a deal either way, but it does seem as though there should be documentation for ps_strings. 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"
Re: ps_strings
First, I want to thank Super Bisquit, Fernando and Chris for their inputs. Second, the ps_strings struct remains in use to report information about the running process back to the user and operating system, and as such enriches the content of the FreeBSD kernel, so it's worth create this man page. However, I'll consult this with a member of the doc team so that everything is in order. Attentively --CJPM 2013/8/19 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"
Re: ps_strings
On Mon, Aug 19, 2013 at 06:49:55PM -0600, Chris Torek wrote: > >Yes, p_args caches the arguments, but not always. Right now, kernel > >does not cache arguments if the string is longer than 256 bytes. Look > >for ps_arg_cache_limit in kern_exec.c. > > > >setproctitle() always informs the kernel with sysctl and sets the > >pointers in ps_strings. kern.proc.args sysctl first tries the p_args, > >and falls back to reading ps_strings and following the pointers if > >p_args is NULL. > > Ah, that's what I get for scanning through years of updates too fast. > :-) > > This seems a bit of a "worst of both worlds": there's now some > extra kernel code for poking through the ps_strings and the > pointer-vectors (this code is no longer in libkvm at all -- > that was where I looked first and found the sysctl), for the "no > p_args" case. It seems like perhaps there could just be a sysctl > to return the ps_strings address, and leave the "follow argv > pointers" code in libkvm, if there is to be code for that. There is a demand for other things besides arguments, e.g. environment, and most important for the debuggers, ELF aux vector. Also, moving this code to libkvm would mean that mismatched ABIs cannot be easily supported, like 64bit binary trying to get 32bit binary information. I would say that the current placement fullfill its goals. > > (The kernel saves a bit of time for the presumably-usual "p_args > not NULL" case, and finding the location of the ps_strings > structure when it *is* used is automatically correct. So that > part is a straight-up improvement, at least.) > > Not that big a deal either way, but it does seem as though there > should be documentation for ps_strings. > > Chris pgpeki4CRh2uH.pgp Description: PGP signature
