From owner-freebsd-hackers@FreeBSD.ORG Tue Jun 16 04:02:15 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 BA108D46; Tue, 16 Jun 2015 04:02:15 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5ADE7CAD; Tue, 16 Jun 2015 04:02:15 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id t5G429LU015201 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 16 Jun 2015 07:02:09 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua t5G429LU015201 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id t5G4288H015200; Tue, 16 Jun 2015 07:02:08 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 16 Jun 2015 07:02:08 +0300 From: Konstantin Belousov To: Julian Elischer Cc: Don whY , FreeBSD-Hackers Mailing List Subject: Re: PXE boot an XIP image? Message-ID: <20150616040208.GG2080@kib.kiev.ua> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <557F91C4.8080602@freebsd.org> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home 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:02:15 -0000 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.