Re: [uml-user] UML and computing grids

[Erik P. <epa...@cs...>]

On Thu, Apr 04, 2002 at 11:42:05AM -0500, Jeff Dike wrote:
> epa...@cs... said:
> > I'd disagree - if it's not something my process can touch, then it
> > shouldn't be in visible in my address space. It should be perfectly
> > acceptable for any  process to map memory however it wants.  
> 
> Wrong.  Try mapping something into the 0xc0000000 - 0xffffffff range on
> the host and see how far you get.
> 

But 0xc00000->0xffffffff isn't in /proc/maps :)

> > Specifically, what was killing us was the fact that there was this
> > block of memory at 0x5000000 that our process shouldn't touch. One of
> > the things that our codes could do is checkpoint themselves by writing
> > out all of their  memory segments, and restoring them later. There was
> > no way for us to know that 0x5000000 wasn't us and should have been
> > skipped. When we'd restore, we'd overwrite the new 0x500000 with the
> > old 0x500000, which caused bad things to happen.  Just moving UML to
> > the top of memory isn't going to help us any.
> 
> Yes it is.  Try it now, it should work.  UML mappings aren't visible any more.
> 

I will - are there any other differences between an i386 and UML-on-i386 
address spaces that people have to watch out for?

> > Both of those require setting up basically another machine though,
> > with it's own IP (though maybe IP masq'ed).
> 
> Slirp doesn't.  That's kind of the whole point of it.
> 
> > And if I try and open a listen socket on port 1234 in the UML, then it
> > should open a socket  for me on the 7.2 host on port 1234, and totally
> > bypass the UML network stack.
> 
> Which is exactly what slirp does.  Except that it doesn't bypass the UML
> network.  It sits at the bottom and munges packets going in and out.

So is your patch queue visible anywhere? I didn't see the slirp patch in the
patch browser at sourceforge.

-Erik