lkml.org 
[lkml]   [2011]   [Feb]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    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
    >> <sfking@fdwdc.com> 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.

    Thanks
    Greg


    ------------------------------------------------------------------------
    Greg Ungerer -- Principal Engineer EMAIL: gerg@snapgear.com
    SnapGear Group, McAfee PHONE: +61 7 3435 2888
    8 Gardner Close FAX: +61 7 3217 5323
    Milton, QLD, 4064, Australia WEB: http://www.SnapGear.com


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