Messages in this thread | | | Date | Thu, 26 Feb 1998 11:54:49 -0500 (EST) | From | Ben Collins <> | Subject | Re: 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
| |