gt; RAM (each process gets its own private copy of the C library), but lets me
> execute files across a netmsg TCP/IP session.
>
> I think the next logical step is to get it to attempt an mmap, and only
> fall back if that doesn't work.
You might also want to consider making the mma
I've figured out why the patched exec server didn't work with mmap, and
just opened a bug on it, with a fix attached.
So now I've got a working, mmap-less exec server that burns a lot of extra
RAM (each process gets its own private copy of the C library), but lets me
execute files
Aloha -
I've gotten 'netmsg' to the point where files in the mounted, remote
filesystem can be executed on the local machine. This isn't remote
execution - it's just copying the files to the local machine and executing
them there. Nothing more than what you'd ex
On Tue, Aug 23, 2016 at 11:45 PM, Brent W. Baccala
wrote:
>
> Any ideas why this basic sequence wouldn't work?
>
>node = file_name_lookup("/lib/ld.so", O_RDONLY, 0)
>io_map(node, &rdobj, &wrobj)
>/* create control and objname with send/receive rights on both */
>memory_object_init
On Tue, Aug 23, 2016 at 2:12 AM, Richard Braun wrote:
>
> > It's got a lot of problems. No authentication handoff; everything the
> > client requests happens with the permissions of the server. exec'ing a
> > file doesn't work; the last RPC before the hang is memory_object_init.
> > emacs doesn
On Mon, Aug 22, 2016 at 04:40:58PM -1000, Brent W. Baccala wrote:
> I've gotten a basic netmsg server/translator running that relays Mach
> messages across a TCP/IP connection.
>
> The code is available at g...@github.com:BrentBaccala/netmsg.git
That's great.
> It
Aloha -
I've gotten a basic netmsg server/translator running that relays Mach
messages across a TCP/IP connection.
The code is available at g...@github.com:BrentBaccala/netmsg.git
Basic usage:
netmsg -s (server)
settrans -a node netmsg localhost (client)
It's got a lot of pro
