Date: Tue, 16 Jun 2015 12:38:26 +0800 From: Julian Elischer <julian@freebsd.org> To: Konstantin Belousov <kostikbel@gmail.com> Cc: Don whY <Don.whY@gmx.com>, FreeBSD-Hackers Mailing List <freebsd-hackers@freebsd.org> Subject: Re: PXE boot an XIP image? Message-ID: <557FA842.7060803@freebsd.org> In-Reply-To: <20150616040208.GG2080@kib.kiev.ua> 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> <20150616040208.GG2080@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
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?
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?557FA842.7060803>