From owner-freebsd-hackers@FreeBSD.ORG Tue Jun 16 03:02:40 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 CB7507E0 for ; Tue, 16 Jun 2015 03:02:40 +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 88AA3D2B for ; Tue, 16 Jun 2015 03:02:39 +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 t5G32Y3D092049 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 15 Jun 2015 20:02:37 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <557F91C4.8080602@freebsd.org> Date: Tue, 16 Jun 2015 11:02:28 +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: 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> In-Reply-To: <557F0ED6.7010700@gmx.com> 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 03:02:40 -0000 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. > >