> At 5:11 PM +0100 2/26/98, Mikkel Lauritsen wrote:
> >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.
For the record, let me say that the m68k-nommu tree (based on
plain-vanilla 2.0.33) that we are working on is probationary, and may well
(once some spare time materializes) be folded back into the m68k tree.
> The way it's currently done for m68k is subdirectories in arch/m68k with
> - common code (MMU, CPU)
> - platform specific drivers (Amiga, Atari, Mac) that rely on any of the
> arch dependent code. That's not much these days, and could be transfered
> into drivers/ (after a major keyboard code rewrite?). Look at the
> arch/m68k/...
> subdirs, and you won't find block or char drivers there. Even the video
> stuff has moved to drivers/video/ :-)
IMO, I'm not sure how well the m68k tree will continue to work, as more
m68* ports are created. While many of these machines have definite
similarities, some do not, and may not fit well into the mold. Equally, if
m68k is flexible enough to cope with all of these variants, it suggests
that the code should be folded back into the main tree (as is happening
with fbcon, for an example).
> There's a different proposal out to split CPU- and machine dependent parts
> into separate include/ subdirectories, and that sound more pressing.
Yes, I wouldn't mind this at all.
-- Kenneth Albanowski (kjahds@kjahds.com, CIS: 70705,126)
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu