Re: Changing topic (longish), was Re: GGI debate and etc.

Ben Collins (
Thu, 26 Feb 1998 11:54:49 -0500 (EST)

This may be a dumb question, but this seemed like the best time to bring
it up. I am wondering if there is currently a way to 'cross-compile' a

For instance (and the pre-requesite of a gcc that is capable of cross
compiling is a given) if on my PC I wanted to compile a kernel for a
PowerMac, is this already possible? If not then working that capability
into this 'proposed' restructuring of the source tree would make real

On Thu, 26 Feb 1998, Mikkel Lauritsen wrote:

> wrote:
> > Bill Broadhurst <> writes:
> >
> > > Besides, the code is in the tree whether it's compiled or not. THAT's
> > > to what I object.
> >
> > Any reason you can't just rm(1) it? And use cvs to update your tree -
> > last time I looked it wouldn't create new directories unless you told it
> > to.
> >
> > Perhaps it's time to make the kernel *source* more modular?
> [Delurk]
> Well, that's something that I've been thinking about for a while now, at
> least concerning the structure of the source for the different architec-
> tures Linux supports.
> The various m68k-nommu ports that surface now IMHO make it obvious that
> the present idea of having the architecture define only the CPU type is
> insufficient and creates too much clutter in the source tree. Both the
> Amiga and Mac ports (and possibly others - Sun?) have different CPUs
> with
> the same support hardware, so my suggestion would be to have two
> architec-
> ture flags; one that defines the CPU and one that defines the "surroun-
> dings" (yes, I really need to come up with a better term, but I hope you
> get the idea). As examples, this would describe an Amiga 500 as (Amiga,
> 68000) and an Amiga 3000 as (Amiga,68030) allowing them to share drivers
> for graphics hardware etc. even though their CPU's are different. This
> could very well also be the case for 68k/PPC Mac.
> Most of what is currently found in the arch/XXXX/ directories like low
> level assembly functions for mmu handling, memcpy etc. would go into a
> CPU specific directory, and drivers for other arch specific hardware
> would go into a directory with the same structure as the current drivers
> directory.
> The whole idea behind this restructuring is to create a source tree
> looking like
> 8086 (for ELKS)
> alpha
> arm
> i386 (and higher)
> m68000
> m68030 (and higher)
> mips
> ...
> drivers
> amiga
> net
> ...
> mac
> net
> ...
> pc
> net
> ...
> ...
> common (for all archs)
> net
> ...
> making it obvious where to add support for new architectures when
> porting
> and reducing the current cluttering of the /arch/XXXX/ directories and
> files.
> It should also make it easier to remove the parts of the source tree
> that
> one does not use. Today for example some drivers for acorn and mac are
> kept
> in the /drivers directory and some are in the /arch/XXXX/ directories
> making it difficult to determine what one can safely remove.
> I realize that this would be a major restructuring task, but I think
> it's
> necessary and postponing only makes the task larger when new ports are
> done.
> Comments and/or questions are very welcome
> Mikkel Lauritsen,
> - speaking for himself, not his employer
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to