[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