Mikkel> The various m68k-nommu ports that surface now IMHO make it
Mikkel> obvious that the present idea of having the architecture
Mikkel> define only the CPU type is insufficient and creates too much
Mikkel> clutter in the source tree.
[snip]
Mikkel> As examples,
Mikkel> this would describe an Amiga 500 as (Amiga, 68000) and an
Mikkel> Amiga 3000 as (Amiga,68030) allowing them to share drivers for
Mikkel> graphics hardware etc. even though their CPU's are
Mikkel> different. This could very well also be the case for 68k/PPC
Mikkel> Mac.
The non-MMU ports have only a limit number of things in common when it
comes to the CPU-hardware specific stuff, because a large part of
include/asm-<foo> defines things like MMU structures, file formats,
syscall things etc. Therefore it makes sense to treat the non-MMU
ports as seperate architectures, similar to how we have sparc and
sparc64. Sharing drivers is a totally different matter however.
Mikkel> Most of what is currently found in the arch/XXXX/ directories
Mikkel> like low level assembly functions for mmu handling, memcpy
Mikkel> etc. would go into a CPU specific directory, and drivers for
Mikkel> other arch specific hardware would go into a directory with
Mikkel> the same structure as the current drivers directory.
memcpy() and others will differ depending on the CPU etc. take the 68020+
as an example. These CPUs have instructions used in the functions
which are not available in the 680[01]0.
Mikkel> The whole idea behind this restructuring is to create a source
Mikkel> tree looking like
Mikkel> CPU 8086 (for ELKS) alpha arm i386 (and higher) m68000 m68030
Mikkel> (and higher) mips ... drivers amiga net SCSI ... mac net
Mikkel> SCSI ... pc net SCSI ... ... common (for all archs) net
Mikkel> SCSI ...
I really dislike this idea which I belive will result in a large
amount of duplicated code. Ie. many of the same chips are used in the
different machines, for instance we got quite a few NCR53C9x based
SCSI controllers for the Amiga, the same chip-family used in most Suns
and also in other machines. I prefer (whenever possible) to have
generic drivers for the chips and then leave the glue code (probing,
special DMA engine handling and similar) and machine specific files.
Mikkel> It should also make it easier to remove the parts of the
Mikkel> source tree that one does not use. Today for example some
Mikkel> drivers for acorn and mac are kept in the /drivers directory
Mikkel> and some are in the /arch/XXXX/ directories making it
Mikkel> difficult to determine what one can safely remove.
I hope most of the contesnts of these two directories will go away
over time and be merged with the stuff in net,scsi,char etc.
Jes
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu