Andreas Kupries | 7 Jul 21:37
Picon

Re: GSoC ShlibMemLoad

> On Mon, Jul 7, 2008 at 5:28 AM, Andreas Kupries <akupries@...> wrote:
>
> [...]
>
> >> Because I have already studied this whole code for quite a long time
> >> and have not came up with any solution I am thinking of writing an
> >> email to John Polstra who is an author of the rtld for
> >> FreeBSD. Maybe he will be able to help out. Do you think it is a
> >> good idea?
> >
> > Yes. Getting the help of (one of) the original authors of some code is
> > (in my opinion) a good idea. He should know the intricacies of the
> > code.
>
> As Daniel intends to contact John Polstra from FreeBSD I think that it
> would be easier to work with him if Daniel installs FreeBSD and will
> convey his experiments (and work with John) in this enviroment. I
> would recommend installing FreeBSD on separate machine or in some kind
> of virtual enviroment like VMware or VirtualBox to make simultaneous
> testing easy (such a FreeBSD installation could run in runlevel 3
> without graphical console to limit resources requirements).

I have no big opinion here. I have never worked with FreeBSD, so I have no
idea how much effort it will be to set it up.

An image for some virtual machine is likely the easiest way to go for that.

A quick google for 'freebsd vmware image' gave me

	http://people.freebsd.org/~matusita/VMware/
and	http://www.thoughtpolice.co.uk/vmware/
	(scroll down the second for freebsd).

And there could be more.

However, will Daniel's machine have the cpu-power needed to host both the
freebsd image and his main system ?
Also, how much time will we lose by such a switch?

> >From high level perspective what we need is support in OS dynamic
> linker to link with some libraries loaded by our program into memory
> from some virtual filesystem specific to application (ex. starkit for
> Tcl). Such feature can benefit not only Tcl, but also others who think
> about single file deployments. As far as I understand MacOSX already
> has got this functionality and other OS-es lack it. We currently try
> to emulate it in Linux using code from FreeBSD. But maybe first we
> should try to make it work in FreeBSD. FreeBSD folks can even maybe
> add such capability as a system call (keep in mind that FreeBSD and
> MacOSX shares some source code and maybe it could be also helpful).
> Concerning Linux we decided to emulate loading dynlibs from memory
> using FreeBSD code (due to licensing issues with GPL vs BSD). But
> maybe we shall also contact Linux/glibc developers about including
> proposed functionality in OS/glibc.

In general I would welcome it if the various operating systems would support
loading from memory out of the box with a (semi-)standard system call like
dlopenmem() or some such. For now I would go with our work on emulating this
and then use the concrete code coming out of the project to give the
proposal more weight.

> I don't know how we are going to handle Solaris and other platforms
> that Tcl is known to run fine. It is certainly beyond scope of Daniels
> Google Summer of Code project. But first we have to think also about
> Microsoft Windows where starkit/starpack deployments will benefit
> users the most. I have no idea how can we achieve it on Windows - I
> don't think we can convince/help Microsoft to add such functionality
> :-(.

Solaris and other unixes, except the oldest (*), are all based on ELF. We
should be able to use the project results for them as well. windows uses PE
and/or COFF if I remember correctly, that would need a separate branch, yes.
And I agree that MS is likely not receptive to such a proposal.

--
	Andreas Kupries <andreask@...>
	Developer @ http://www.ActiveState.com
	Tel: +1 778-786-1122

-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08

Gmane