From owner-freebsd-hackers@FreeBSD.ORG Sun Aug 18 22:18:19 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 5AC931BE for ; Sun, 18 Aug 2013 22:18:19 +0000 (UTC) (envelope-from torek@torek.net) Received: from elf.torek.net (50-73-42-1-utah.hfc.comcastbusiness.net [50.73.42.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 16B2B2FDC for ; Sun, 18 Aug 2013 22:18:18 +0000 (UTC) Received: from elf.torek.net (localhost [127.0.0.1]) by elf.torek.net (8.14.5/8.14.5) with ESMTP id r7IM5BQR062114; Sun, 18 Aug 2013 16:05:11 -0600 (MDT) (envelope-from torek@torek.net) Message-Id: <201308182205.r7IM5BQR062114@elf.torek.net> From: Chris Torek To: Carlos Jacobo Puga Medina Subject: Re: ps_strings In-reply-to: Your message of "Sat, 17 Aug 2013 20:00:55 +0200." Date: Sun, 18 Aug 2013 16:05:11 -0600 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (elf.torek.net [127.0.0.1]); Sun, 18 Aug 2013 16:05:11 -0600 (MDT) Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Aug 2013 22:18:19 -0000 >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