Date: Mon, 15 Jun 2015 10:43:50 -0700 From: Don whY <Don.whY@gmx.com> To: Julian Elischer <julian@freebsd.org>, FreeBSD-Hackers Mailing List <freebsd-hackers@freebsd.org> Subject: Re: PXE boot an XIP image? Message-ID: <557F0ED6.7010700@gmx.com> In-Reply-To: <557E4480.6000603@freebsd.org> References: <557C073E.1060702@gmx.com> <557C2BD7.1000104@freebsd.org> <557C844F.1010107@gmx.com> <557E4480.6000603@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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. <frown>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?557F0ED6.7010700>