[Gllug] Kernel compile taking forever...!

[Jack Bertram]

* Nix <nix at esperi.org.uk> [050202 00:45]:
> On Tue, 1 Feb 2005, Jack Bertram murmured woefully:
> > So I thought I would get this system working properly and then try
> > an AMD64 installation on a new partition.
> 
> I'd use a chroot ;)

Hmmm.  What do you mean? - the rest of your email seems to suggest that
you don't need a chroot.

Surely I can't run 64bit code without a 64bit kernel, and I can't run
one of those in a chroot.

I suppose I could install AMD64 and set up a 32-bit chroot, but what is
a 32-bit chroot?  Could I then run OO.o?

> Once you hit userspace, the 32- and 64-bit stuff is basically separate
> universes. They split apart down inside the kernel, where an indirection
> layer transforms 32-bit system call into the kernel's native 64-bit
> ones, and all the code above that inherits that `bitness'.
> 
> So you need separate userspaces, pretty much: the filesystem is shared,
> and interprocess communication can reach across the divide, but each
> process is either 32- or 64-bit, never a mixture.

These seems to suggest that they're completely compatible as long as
programs don't use assembler?
 
> (I've got a mixed 32 and 64-bit SPARC/Linux userspace here: unlike on
> AMD64, there are significant speed costs in compiling stuff as 64-bit on
> UltraSPARC, so the majority of my userspace is 32-bit. The XEmacs I'm
> typing this mail in is 64-bit, though.)

64-bit code runs slower on an UltraSPARC than 32-bit code?

j
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
URL: <http://mailman.lug.org.uk/pipermail/gllug/attachments/20050202/db32c982/attachment.pgp>
-------------- next part --------------
-- 
Gllug mailing list  -  Gllug at gllug.org.uk
http://lists.gllug.org.uk/mailman/listinfo/gllug