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