lkml.org 
[lkml]   [1998]   [Feb]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Changing topic (longish), was Re: GGI debate and etc.
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
kernel.

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
sense.

On Thu, 26 Feb 1998, Mikkel Lauritsen wrote:

> ketil@ii.uib.no wrote:
>
> > Bill Broadhurst <bbroad@CX492564-a.dt1.sdca.home.com> 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
>
> CPU
> 8086 (for ELKS)
> alpha
> arm
> i386 (and higher)
> m68000
> m68030 (and higher)
> mips
> ...
> drivers
> amiga
> net
> SCSI
> ...
> mac
> net
> SCSI
> ...
> pc
> net
> SCSI
> ...
> ...
> common (for all archs)
> net
> SCSI
> ...
>
> 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, ml@thevisionfactory.com
> - speaking for himself, not his employer
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.rutgers.edu
>


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu

\
 
 \ /
  Last update: 2005-03-22 13:41    [W:0.074 / U:0.628 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site