linux-mips
[Top] [All Lists]

Re: Userland loader / run time loader

To: linux@cthulhu.engr.sgi.com
Subject: Re: Userland loader / run time loader
From: "William J. Earl" <wje@fir.engr.sgi.com>
Date: Mon, 16 Jun 1997 10:33:59 -0700
In-reply-to: <199706140312.WAA17152@athena.nuclecu.unam.mx>
References: <Pine.LNX.3.95.970613194626.15021G-100000@lager.engsoc.carleton.ca> <199706140312.WAA17152@athena.nuclecu.unam.mx>
Sender: owner-linux@cthulhu.engr.sgi.com
Miguel de Icaza writes:
 > 
 > > To address the needs of us lowly folk who have fewer than 2 MIPS boxes[1],
 > > which endian are we going to be supporting first?  It would be _very_
 > > pleasant to be able to run all these binaries that Ralf has prepared. 
 > 
 > Some time ago, someone mentioned that making the kernel support both
 > big endian and little endian binaries in RISC/os consumed too much of
 > their time. 
 >
 > The time we will spend trying to get this bloating hack into the
 > kernel could be easily spent on some more productive things.  

     I reported on the RISC/os experience.  It wasn't so much that it
took too much time, but rather that it was hard to support on the SVR3
kernel interface, due to the messy definition of the streams interface
at the system call level.  It is much easier if you can assume only
dynamically linked binaries, as in SVR4, and you can do much (although
not all) of the work in user mode, and much of the rest of the work
can happen as a side-effect of copyin/copyout.

 > I will put together a root file system and a bunch of rpms soonish
 > (ie, that is, as soon as I boot my Indy into Linux).

     That is clearly more expedient than trying to do bi-endian binary
support.  Once the source-level endian issues are resolved (and most
should already be resolved in any GNU sources), having both litte-
and big-endian binaries and file systems is fairly simple.


<Prev in Thread] Current Thread [Next in Thread>