linux-mips-fnet
[Top] [All Lists]

Re: The great namespace debate (was NAPS in DECStation)

To: linux-mips@fnet.fr
Subject: Re: The great namespace debate (was NAPS in DECStation)
From: paul@suite.sw.oz.au (Paul Antoine)
Date: Tue, 7 May 1996 21:34:50 +1000 (EST)
In-reply-to: <199605061415.QAA03349@informatik.uni-koblenz.de> from "Systemkennung Linux" at May 6, 96 04:13:08 pm
Organization: Softway Pty Ltd
Hi folks,

Ralf wrote:

> Well, so I herewith declare the discussion about the directory structure
> to be opened.  How about organizing the tree as follows:
> 
>    arch/mips/kernel           generic part of the kernel.
>    arch/mips/lib
>    arch/mips/mm
>    arch/mips/mips1            ISA dependent code
>    arch/mips/mips2
>    arch/mips/mips3
>    arch/mips/mips4
>    arch/mips/decstation
>    arch/mips/decstation/boot
>    arch/mips/decstation/mips1 machine and cpu specific code
>    arch/mips/decstation/mips3
>    arch/mips/deskstation
>    arch/mips/magnum
>    arch/mips/magnum/boot
>    arch/mips/magnum/mips1     special magnum & cpu specific code
>    arch/mips/magnum/mips3     
> 
> As you see there are two levels of directories with CPU specific code.  We
> might search them via VPATH in Makefiles;  code in the machine & model
> specific dirs will be found first and therefore has higher precedence than
> the generic code.
> 
> Opinions?

Hmmm... I hope we don't need another level to the hierarchy...<sigh>

e.g.:

        arch/mips/dec/kernel
        arch/mips/dec/pmax
        arch/mips/dec/kmin
        arch/mips/arc/kernel
        arch/mips/arc/magnum
        arch/mips/arc/olivetti
        arch/mips/mips/kernel
        arch/mips/mips/magnum

...I'm not sure but my brain isn't functioning well enough to say
specifically why... and it therefore may be the completely unnecessary
fabrication of a tired mind.

> I'd like to burry the feature structure.  The structure is already almost
> one screen page of code and it will get at least three or four times as
> big; there will also be aditional CPU dependencies and submodel dependencies.
> We should go back to plain and boring variables pointing to function or so.
> Given a reasonable organisation this will be better managable than that
> stoneage time 68k-ism struct feature.

O.K.   I can live with that :-)

> > as the new config code is now in C rather than assembler. <yay!>
> 
> Yes, we're getting ol'...

Hmmpfhhh... speak for yourself! <the joke is that I'm older than Ralf :->

Call me old if you wish - I just feel it's silly to code in assembler 
just for the pain of it... :-)

Paul
_______________________________________________________________________________
Paul M. Antoine,                                        Net: paul@sw.oz.au
Softway Pty Ltd                                         WWW: www.softway.com.au
PO Box 305, Strawberry Hills, NSW 2012, Australia       Tel: +61 2 698 2322
Level 2, 79 Myrtle St, Chippendale, NSW 2008, Australia Fax: +61 2 699 9174

"It is the lack of acceptance of diversity which threatens to 
 destroy society, NOT the free expression of it." - Me.

<Prev in Thread] Current Thread [Next in Thread>