PXE boot an XIP image?

[Julian Elischer]

On 6/16/15 12:02 PM, Konstantin Belousov wrote:
> 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.
cool.. but I guess you'd have to load it up from the net before you 
could use it.
Is this documented anywhere?