Re: Changing topic (longish), was Re: GGI debate and etc.

Michael Schmitz (schmitzm@uclink4.berkeley.edu)
Thu, 26 Feb 1998 13:55:45 -0800

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. 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 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/ :-)

>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
> ...

As is today. BTW, m68000 and m68k will be able to share the stuff in .../amiga
etc, no need for more than separate .../mm directories.

>drivers
> amiga
> net
> SCSI
> ...
> mac
> net
> SCSI
> ...
> pc
> net
> SCSI
> ...

Please don't do that. Currently, net/block/char/scsi drivers are shared as
much as possible among architectures, and I'd like to see that proceed
further along. I.e. one arch-independent SCC driver, one driver for all
5380 or 53C9x chips,
etc. The IDE driver is the example par excellence there, and I don't expect
any
problems adding IDE support for Mac given a few register addresses.

>making it obvious where to add support for new architectures when
>porting
>and reducing the current cluttering of the /arch/XXXX/ directories and
>files.

The cluttering of drivers/char etc. is a bigger problem for all I can see. And
separating off the arch-dependent parts in separate directories isn't that
big a win. I'd like to get rid of drivers/macintosh but Paul seems to
object strongly
to that :-)

There's a different proposal out to split CPU- and machine dependent parts
into separate include/ subdirectories, and that sound more pressing. If
people want to clean up arch/ and put machine/platform dependent code
elsewhere, please do at least leave the current drivers/ stuff untouched.

Michael

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu