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

Re: AMD64 port

From: "Noah yan" <noah.yan@xxxxxxxxx>
Date: Wed, 18 Jul 2007 10:14:51 -0500


under platform/pc32/, what do you mean to have a i386 folder and all
the source files in the folder, the are cpu-specific codes under


On 7/16/07, Matthew Dillon <dillon@apollo.backplane.com> wrote:

::However, there is not much point in that unless you also build some libraries, at least libgcc.a. And for those we'd need the right kernel headers. :: ::Plus, what's the gain? I can see the use on a 64 bit system, however. :: ::cheers :: simon : : It looks like just creating a subdirectory for each architecture : would be sufficient, e.g. /usr/lib/gcc34/i386/libgcc.a instead of : /usr/lib/gcc34/libgcc.a. : : But that sort of change is not something I'd want to do for this : release, it would have to be post-release.

    Again, post-release, if we want to create a multi-target environment,
    we need to come up with a solution to /usr/lib, /usr/libexec, /usr/bin,
    /usr/sbin, /bin, /sbin, and so forth.  Even /usr/pkg/{bin,lib,libexec,sbin}
    could use the scheme.

    Maybe after this release is the time to finally use our varsym

    I was thinking having /usr/lib_i386, /usr/lib_amd64, etc and then
    making /usr/lib a varsym which points to the correct architecture.
    We would then do something similar for everything else.  /bin, /sbin,
    /usr/bin, /usr/sbin, /usr/libexec, /usr/pkg/{bin,lib,libexec,sbin}.

    It would be possible to maintain all the standard, expected places
    and yet still support multiple architecture targets.

                                        Matthew Dillon

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