From owner-freebsd-hackers@FreeBSD.ORG Tue Jun 16 04:38:39 2015 Return-Path: Delivered-To: freebsd-hackers@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F41C944E for ; Tue, 16 Jun 2015 04:38:38 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id C04D2654 for ; Tue, 16 Jun 2015 04:38:38 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from Julian-MBP3.local (50-196-156-133-static.hfc.comcastbusiness.net [50.196.156.133]) (authenticated bits=0) by vps1.elischer.org (8.14.9/8.14.9) with ESMTP id t5G4cVGS092449 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 15 Jun 2015 21:38:35 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <557FA842.7060803@freebsd.org> Date: Tue, 16 Jun 2015 12:38:26 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Konstantin Belousov CC: Don whY , FreeBSD-Hackers Mailing List Subject: Re: PXE boot an XIP image? References: <557C073E.1060702@gmx.com> <557C2BD7.1000104@freebsd.org> <557C844F.1010107@gmx.com> <557E4480.6000603@freebsd.org> <557F0ED6.7010700@gmx.com> <557F91C4.8080602@freebsd.org> <20150616040208.GG2080@kib.kiev.ua> In-Reply-To: <20150616040208.GG2080@kib.kiev.ua> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2015 04:38:39 -0000 On 6/16/15 12:02 PM, Konstantin Belousov wrote: > On Tue, Jun 16, 2015 at 11:02:28AM +0800, Julian Elischer wrote: >> On 6/16/15 1:43 AM, Don whY wrote: >>> I was looking for more of a "hack" to exploit existing >>> characteristics in a >>> novel way -- in much the same way that crunchgen can be considered a >>> "hack". >>> >>>> Others may chime in if there is work underway already but I don't >>>> recall >>>> hearing about such. >>> I don't think it is easily accomplished. >>> >>> The way I see it, you need a hack to allow you to transfer all of the >>> appropriate binaries into RAM *as* process images (or something >>> similar). >>> Then, you need a way of invoking each, as needed (i.e., some *portion* >>> of that RAM-based image). Finally, you need a way to ensure that you >>> don't start duplicating TEXT in the process (else you've defeated >>> your purpose). >>> >> >>> E.g., if you fork the single, combined (crunchgen'd) image each time >>> you >>> want to start a new process (run a new command embedded within that >>> image), you can share the TEXT -- but, you now end up duplicating *all* >>> of the DATA segment (including requirements for "other" commands folded >>> into that image). >> If you had an image activator that loaded the text pages from the >> filesystem >> using page sharing, (possibly a tmpfs variant) you'd achieve what you >> want in >> the text segment, but as you say you'd still need data copying. >>> You'd have to almost be converting each individual executable into its >>> own little .so (and the modules that it requires into still other >>> .so's) >>> just so you could get that finer-grained "load/execute" capability of >>> individual "programs" without the excess DATA segment costs. >>> >>> [And, at the same time, you'd have to arrange to fault all of these >>> .so's into memory at IPL so they were present when/if needed] >>> >>> I just can't see a trick to work-around this basic "load/execute" >>> assumption >>> inherent in UN*X and other "desktop" OS's. >> I think the two parts of the equation are: >> and image activator that loads the text segment by sharing >> and a matching filesystem that has an interface by which pages of a file >> can be available on a refcounted basis to the VM. >> given those two things it maybe able to have only no shared data >> taking up extra space on execute. >> >> For me it wouldn't be worth the extra work, but I could imagine some >> very small machines where it may be an advantage. >> > Our tmpfs(5) provides the in-place execution capability, assuming the image > has correctly aligned segments. cool.. but I guess you'd have to load it up from the net before you could use it. Is this documented anywhere?