linux-kernel - Re: merge of m68knommu and m68k arch branches?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 18 Feb 2011 22:01:53 +1000
From:	Greg Ungerer <gerg@...pgear.com>
To:	Sam Ravnborg <sam@...nborg.org>
CC:	Linux/m68k <linux-m68k@...r.kernel.org>,
	Linux Kernel Development <linux-kernel@...r.kernel.org>,
	Steven King <sfking00@...oo.com>,
	uClinux development list <uclinux-dev@...inux.org>,
	Greg Ungerer <gerg@...inux.org>,
	Greg Ungerer <gregungerer@...tnet.com.au>
Subject: Re: 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@...dc.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@...pgear.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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/