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

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