Date: Tue, 16 Jun 2015 07:02:08 +0300 From: Konstantin Belousov <kostikbel@gmail.com> To: Julian Elischer <julian@freebsd.org> Cc: Don whY <Don.whY@gmx.com>, FreeBSD-Hackers Mailing List <freebsd-hackers@freebsd.org> Subject: Re: PXE boot an XIP image? Message-ID: <20150616040208.GG2080@kib.kiev.ua> In-Reply-To: <557F91C4.8080602@freebsd.org> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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. <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. > Our tmpfs(5) provides the in-place execution capability, assuming the image has correctly aligned segments.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20150616040208.GG2080>