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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Fri, 18 Feb 2011 08:44:01 +0100
From:	Sam Ravnborg <sam@...nborg.org>
To:	Greg Ungerer <gerg@...pgear.com>
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?

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.

> 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?

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.

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

	Sam
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ