From owner-freebsd-hackers@FreeBSD.ORG Mon Jun 15 17:43:45 2015 Return-Path: Delivered-To: freebsd-hackers@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 326EF91B; Mon, 15 Jun 2015 17:43:45 +0000 (UTC) (envelope-from Don.whY@gmx.com) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C7A81B5; Mon, 15 Jun 2015 17:43:44 +0000 (UTC) (envelope-from Don.whY@gmx.com) Received: from [192.168.1.115] ([67.212.197.98]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0LguAU-1ZP5LC482w-00oFj3; Mon, 15 Jun 2015 19:43:37 +0200 Message-ID: <557F0ED6.7010700@gmx.com> Date: Mon, 15 Jun 2015 10:43:50 -0700 From: Don whY User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: Julian Elischer , 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> In-Reply-To: <557E4480.6000603@freebsd.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:zM+8s73mRhHxQG7AcG5i4FU+Gm9d1I/n7hje90dAtx0W1whfG/x j8lOfG8XfYOpeEqyvVujKG7qDY6xAC7wBB2DBudv9RAYA+mGZozrajCv9xn8rlxdTxb5csA SWIjxuCIPtv72M4BqTVFsciATEHiKuHdx9qyTEelz67ACqWdPd0fFJ0ZQO76G9hBrRgRjbz zu7K1zKGicv5SoxjgVC4w== X-UI-Out-Filterresults: notjunk:1;V01:K0:ST7W5C+ecKo=:PEs81FJp+Tr6HTtaveScmp HQGthlwxqC382ob26t4SDKjr3CC+Txww3OrOVoiS3uZBlKVTjSIxkSJltzI2WozCDB59KoKbL weLObi+8ADT/smFyoyoEzJGuhopZoCxMtvM0/YqImMJcdt6cRu1VXnCaw+cZ9kyiVh3fg5Y35 UwwIMnvBfyKpMW6RecVpbz0F2fhVP/dpOPOdrkuRron7+eg/Bv4ZtQnrL3PJJcc24p7H5LvM1 sND/wpZl8KDmcdNxgH8/xLwHByf1MxNjUqFUqj4qDVgBZR9OQy4WtH7/Nby1zo90uw40YQD9p s9t5D4ZRhhYpUtodb+gKYeATtQb0t3D18d3hf7acC6ln7RwP1ABdeV6VsBHfRDdPjLIVd/LhE y0Psa7PkxvNlNZnHrfnFmIm4AqDfyDQCQtztFYYvMYkWqGkMf8N3G5soYl6wpV3GbedwgnFmH l2ygkRpYwd8nflJ2g+AUAbWPSOkUbozMB0uyu2vPBg3ajhEnZZlkmlHbw2g9nodCoi8K/2n2I 09/ViPbdxWRnz+Tm1n1kGdeN5OximV92PHTyGGhOkIDv43r5mpsdT9CttAYUCEixoVRtd7hyn bxLEndKeEHOM3+r9t2/XV8LOr7CPSzldOWaVyLh0v4FsDm2xyOWLqcGJSMZ68sSe24PB1vgg+ 6bYWWGl0bRF8JVehapsGSuVmCESToPR3fwZ8dF/phMai07AHw7w9h961JzRlguks7k2g= 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: Mon, 15 Jun 2015 17:43:45 -0000 On 6/14/2015 8:20 PM, Julian Elischer wrote: > On 6/14/15 3:28 AM, Don whY wrote: >> On 6/13/2015 6:10 AM, Julian Elischer wrote: >>> On 6/13/15 6:34 PM, Don whY wrote: >>> >>>> I'd like to PXE boot a kernel then fetch (any choice of protocol) >>>> a *single* image to load into RAM thereafter not requiring any >>>> access to external media to operate. I.e., as if the image >>>> had resided in the device all along. >>> >>> what do you mean by "single"? any PXE boot is by definition a number of >>> transactions. >> >> Load kernel, load *an* executable, CUT NETWORK CORD. Thereafter, behave >> as if the device was operating from built-in FLASH. >> >>> The regular PXE boot code from FreeBSD is capable of loading a kernel and a >>> matching ram filesystem, which when executed, will boot up as a running >>> system and not touch any medium. I haven't done it for a while but at >>> one stage there used to be a suitable memory filesystem on one fo the boot >>> media. >>> (that may no longer be true) >> >> A memory filesystem is not the same as XIP. You'd have *two* copies of >> anything that is executing in RAM at any given time: the one stored >> in the filesystem and the one that is executing in process memory. > you didn't explain clearly you wanted "execute in place" (XIP) (or if you did you > didn't explain what it means becasue I only figured it out from your other > email). Sorry, "PXE boot an XIP image" was the best way I could describe my intent. :< Note that loading the kernel is exactly what I'm trying to do -- but with a good chunk of userland, too! (i.e., the kernel is loaded at boot into *memory*, not into a "filesystem" and begins executing -- AS IF it was operating out of FLASH) > As far as I know there is no facility for that. It's an interesting concept.. > You could probably start from tmpfs and add a 'preloaded image' feature and > a vfs layer that uses a copy-on-write getpages entrypoint. But I think it's > going to be > you doing much of the work. You may need a special image activator to handle > the loading. 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). 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.