PXE boot an XIP image?

[Konstantin Belousov]

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.