DragonFly kernel List (threaded) for 2007-08
DragonFly BSD
DragonFly kernel List (threaded) for 2007-08
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: platform/pc64 will be dropped

From: "Noah yan" <noah.yan@xxxxxxxxx>
Date: Thu, 23 Aug 2007 16:14:03 -0500

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


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

[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]