[lkml]   [2011]   [Feb]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: merge of m68knommu and m68k arch branches?
    Hi Sam,

    On 18/02/11 17:44, Sam Ravnborg wrote:
    > On Fri, Feb 18, 2011 at 10:07:25AM +1000, Greg Ungerer wrote:
    >> Hi All,
    >> I would like to put up for discussion a merge of the m68knommu and
    >> m68k arch branches.
    >> Attached is a script and patch that does a kind of brute force
    >> simplistic merge of the directories and files. (Thanks to Stephen King
    >> <> for the initial version of this script, and to
    >> Sam Ravnborg for the m68k includes merge script this was based on).
    >> Nothing outside of the arch/m68k and arch/m68knommu directories is
    >> touched, and in the end there is no more arch/m68knommu. To apply you
    >> simply run the script from the top of a current kernel git tree (I used
    >> 2.6.38-rc5 for testing) and then apply the patch.
    > The initial version of said script was created by Arnd IIRC.

    Apologies to Arnd then :-)

    >> Thoughts?
    > When we merged x86, sh and sparc in the past this has in all
    > cases helped sharing coe between the 32 and 64 bit variants.
    > There has in all cases been some code-chrunch in the beginning,
    > but the result has been good.
    > What as often caused some troubles has been how to configure
    > the individual architectures.
    > We have for eaxample:
    > make ARCH=x86, make ARCH=i386, make ARCH=x86_64 today.
    > Likewise for sparc we have:
    > make ARCH=sparc, make ARCH=sparc32, make ARCH=sparc64
    > So you need to consider how to deal with this for m68k.
    > Maybe MMU is just an option so you only have ARCH=m68k in the end?

    That is what I have currently done. CONFIG_MMU is selectable,
    and there is no longer a separate ARCH=m68knommu, only ARCH=m68k.
    I am fine with that, but I am interested in what opinion others
    have on this.

    > You do not touch upon the maintenance of the merged trees.
    > Today there is different maintainers for the two archs.
    > To have a transparent flow the better solution is likely that
    > all m68k* patches go via one of your trees so we do not
    > have two trees that deal with m68k upstream.

    Yeah, I had much thought to this yet.

    > I assume we will sort it all out naturally and I hope that
    > we soon will have m68k and m68knommu merged!

    That would be my take on it ;-)
    I am happy to charge ahead and let the maintenance/flow work
    itself out.


    Greg Ungerer -- Principal Engineer EMAIL:
    SnapGear Group, McAfee PHONE: +61 7 3435 2888
    8 Gardner Close FAX: +61 7 3217 5323
    Milton, QLD, 4064, Australia WEB:

     \ /
      Last update: 2011-02-18 13:07    [W:0.058 / U:6.900 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site