[uml-devel] porting uml to Hurd

[uml-devel] porting uml to Hurd

[Constantine Kousoulos]

Hello!

i'm interested in porting uml to GNU/Hurd. Since uml is just 
"another process" (or many processes), in theory, it could be 
ported to Hurd's user space. Uml's architecture would remain i386.

Can you supply me with more info (docs, urls, directions to source 
code, etc) on what needs to be done in order to accomplish the 
port? Technical details would really help me discover if uml can 
actually be ported to the Hurd.


Thanks,
Constantine



-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] porting uml to Hurd

[Jeff Dike]

On Thu, Dec 14, 2006 at 02:25:23PM +0200, Constantine Kousoulos wrote:
> Can you supply me with more info (docs, urls, directions to source 
> code, etc) on what needs to be done in order to accomplish the 
> port? Technical details would really help me discover if uml can 
> actually be ported to the Hurd.

There's no documentation to speak of wrt to an OS port.  There is some
outdated architecture porting information at
http://user-mode-linux.sourceforge.net/arch-port.html, some of which
is relevant.

Here's a little list off the top of my head, for a skas-like mode  -
	interception and nullification of another process system calls
	ability to change memory mappings of another process
	interception and nullification of signals received by another
process

If you can handle those, you are probably in good shape.

If you can't do the second two, then a tt-like mode might be possible,
where you map the UML kernel into every UML process address space.
Then those become trivial since "the other process" is a UML process.
However, in this case, there are other nasty tricks needed, like
making sure that the host processes have different address spaces, but
the UML portions are shared.  The kernel data obviously needs to be
shared across all processes.

Look at the interface declared in arch/um/include/os.h and defined in
arch/um/os-Linux/.  It's probably unnecessarily wide at this point,
and contains Linux-isms which shouldn't be there, but that's my
current stab at an OS abstraction interface.

				Jeff
-- 
Work email - jdike at linux dot intel dot com

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] porting uml to Hurd

[Erik Paulson]

On Wed, Dec 20, 2006 at 01:08:30PM -0500, Jeff Dike wrote:
> 
<...>
> There's no documentation to speak of wrt to an OS port.  There is some
> outdated architecture porting information at
> http://user-mode-linux.sourceforge.net/arch-port.html, some of which
> is relevant.
> 
> Here's a little list off the top of my head, for a skas-like mode  -
> 	interception and nullification of another process system calls
> 	ability to change memory mappings of another process
> 	interception and nullification of signals received by another
> process
> 
> If you can handle those, you are probably in good shape.
> 
> If you can't do the second two, then a tt-like mode might be possible,

What are the options for an OS that can't intercept system calls? On Darwin
(the BSD part of MacOS X) there is no PTRACE_SYSCALL - Apple's stance on
intercepting system calls is 'use dynamic loader hacks'. They also appear
to use sysenter for system calls (and I think int80 in some places too)

Modifying memory is easy on MacOS, in fact it's a lot easier than on Linux.

For system calls, past apporaches have been to patch the MacOS host kernel:
http://www.citi.umich.edu/u/provos/systrace/macosx.html

I suppose a MacOS UML could do some binary translation looking for Linux
system calls too.

For a good overview of some of the MacOS functionality, see:
http://uninformed.org/?v=4&a=3&t=sumry

-Erik


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel