Re: [Xen-devel] [PATCH 10/11] rump kernels: Handle rumpxen host in configure

[Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>]

Ian Campbell writes ("Re: [Xen-devel] [PATCH 10/11] rump kernels: Handle 
rumpxen host in configure"):
> On Mon, 2014-06-30 at 16:52 +0100, Ian Jackson wrote:
> > Support
> >    ./configure --host=i386-rumpxen-netbsd
> 
> Are things happy without some sort of update to config.{sub,guess,blah}?
> Debian keep having to update those for a new arch. Maybe that's for when
> --host isn't used though?

Yes, they don't need updating.  This is one reason to choose this
rather than (eg) i386-unknown-rumpxen.

Indeed, earlier I had this exchange with the rumpkernel folks:

  Justin Cormack writes:
  > I think i386-unknown-rumpxen is probably more correct, as it is not
  > strictly netbsd even if it is netbsd like.

  I have two counterarguments to that.

  Firstly, that causes config.sub to fail with:
    checking host system type... Invalid configuration
       `i386-unknown-rumpxen': system `rumpxen' not recognized
  We need something that will work with existing configure scripts.
  Now `i386-rumpxen-none' would work, but:

  Secondly, the point of this is to cause a configure script of a naive
  userland program (which is what we are trying to compile) to do the
  right thing.  The rumpuserxen application environment is much more
  like NetBSD than anything else.  It has a NetBSD libc and a good
  number of the NetBSD system calls.

  If a program is choosing between multiple implementation/interfaces to
  try to use, then if it chooses NetBSD there is a good chance that it
  will build and even a hope that it will work.

  "none" is much less accurate.


> Why i386-* and not x86_64-*?

There's no particular reason why I mentioned that rather than the
other in the commit message.  I think it ought to work with either.

Should I mention both ?  I haven't tested x86_64, although if and when
I plumb this new stuff into osstest that will end up being tested.

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel