Re: platform/pc64 will be dropped

["Noah yan" <noah.yan@xxxxxxxxx>]

a platform is only for a cpu and i didnot see a platform that uses two
different cpu. so instead of keeping cpu and platform folder
separately that i donot see benefit of this, how about doing this way,
each cpu architecture has a folder under sys/cpu (or a better name
like sys/arch), e.g. sys/arch/i386 and the sys/cpu/i386/platform
folder for platforms. so if for pc32, we have
sys/arch/i386/platform/pc32. If that makes the folder too deep, just
sys/arch/i386/pc32 for platform sources.

this way, we keep a single cpu/platform-dependent folder instead of two.

For sharing sources between amd64 and i386, i feel not a good idea,
mess around and between two architecture (even similar) is not fun :).

Noah

On 8/23/07, Matthew Dillon <dillon@apollo.backplane.com> wrote:
>
> :I think we need to have something in between:  a CPU specific section of the platform code.
> :
> :So:  ACPI, APIC, 90% of all headers in platform/pc32/include, stuff like that, all of this is the same between pc32/i386 and pc64/amd64.
> :
> :Now.  Different are bits like exception handling, etc.  Basically everything in a .s file or containing inline assembler.
> :
> :So where does us leave this?  We need an intermediate section, which should be "cpu specific platform code".  I think this does make sense.  If somebody has a better idea on how to structure it while avoiding duplication, I'm all ears.  For example, I think having platform specific cpu code seems kind of wrong.
>
>     Something like platform/pccommon/ which the platform/pc32 and
>     platform/pc64 Makefile's just add source files from with .PATH
>     directives and SRCS+=.
>
>     I dont particularly like the idea because I've considered it before,
>     but then again there might not be any other alternative so you are
>     definitely a 'go' for doing something like this if you want.
>
>     For sure we dont want to add any more directives to config/<KERNEL>.
>     We already have three!  The support directory will simply be common
>     code that the primary platform directories include.
>
>     We should have sufficient header file infrastructure in place already
>     to access the platform header files (machine/BLAH) from outside the
>     platform directories.
>
>     In terms of placement, I dont want to add any new subdirectories to
>     /usr/src/sys/.  Even though its a bit polluting of the abstraction,
>     the common support director(ies) should probably go in platform/,
>     e.g. platform/pccommon/.
>
>                                                 -Matt
>
>