<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-toradex.git/arch/m68k/Kconfig.debug, branch tegra</title>
<subtitle>Linux kernel for Apalis and Colibri modules</subtitle>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/'/>
<entry>
<title>m68k: merge m68k and m68knommu arch directories</title>
<updated>2011-03-25T04:05:13+00:00</updated>
<author>
<name>Greg Ungerer</name>
<email>gerg@uclinux.org</email>
</author>
<published>2011-03-22T03:39:27+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=66d857b08b8c3ed5c72c361f863cce77d2a978d7'/>
<id>66d857b08b8c3ed5c72c361f863cce77d2a978d7</id>
<content type='text'>
There is a lot of common code that could be shared between the m68k
and m68knommu arch branches. It makes sense to merge the two branches
into a single directory structure so that we can more easily share
that common code.

This is a brute force merge, based on a script from Stephen King
&lt;sfking@fdwdc.com&gt;, which was originally written by Arnd Bergmann
&lt;arnd@arndb.de&gt;.

&gt; The script was inspired by the script Sam Ravnborg used to merge the
&gt; includes from m68knommu. For those files common to both arches but
&gt; differing in content, the m68k version of the file is renamed to
&gt; &lt;file&gt;_mm.&lt;ext&gt; and the m68knommu version of the file is moved into the
&gt; corresponding m68k directory and renamed &lt;file&gt;_no.&lt;ext&gt; and a small
&gt; wrapper file &lt;file&gt;.&lt;ext&gt; is used to select between the two version. Files
&gt; that are common to both but don't differ are removed from the m68knommu
&gt; tree and files and directories that are unique to the m68knommu tree are
&gt; moved to the m68k tree. Finally, the arch/m68knommu tree is removed.
&gt;
&gt; To select between the the versions of the files, the wrapper uses
&gt;
&gt; #ifdef CONFIG_MMU
&gt; #include &lt;file&gt;_mm.&lt;ext&gt;
&gt; #else
&gt; #include &lt;file&gt;_no.&lt;ext&gt;
&gt; #endif

On top of this file merge I have done a simplistic merge of m68k and
m68knommu Kconfig, which primarily attempts to keep existing options and
menus in place. Other than a handful of options being moved it produces
identical .config outputs on m68k and m68knommu targets I tested it on.

With this in place there is now quite a bit of scope for merge cleanups
in future patches.

Signed-off-by: Greg Ungerer &lt;gerg@uclinux.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
There is a lot of common code that could be shared between the m68k
and m68knommu arch branches. It makes sense to merge the two branches
into a single directory structure so that we can more easily share
that common code.

This is a brute force merge, based on a script from Stephen King
&lt;sfking@fdwdc.com&gt;, which was originally written by Arnd Bergmann
&lt;arnd@arndb.de&gt;.

&gt; The script was inspired by the script Sam Ravnborg used to merge the
&gt; includes from m68knommu. For those files common to both arches but
&gt; differing in content, the m68k version of the file is renamed to
&gt; &lt;file&gt;_mm.&lt;ext&gt; and the m68knommu version of the file is moved into the
&gt; corresponding m68k directory and renamed &lt;file&gt;_no.&lt;ext&gt; and a small
&gt; wrapper file &lt;file&gt;.&lt;ext&gt; is used to select between the two version. Files
&gt; that are common to both but don't differ are removed from the m68knommu
&gt; tree and files and directories that are unique to the m68knommu tree are
&gt; moved to the m68k tree. Finally, the arch/m68knommu tree is removed.
&gt;
&gt; To select between the the versions of the files, the wrapper uses
&gt;
&gt; #ifdef CONFIG_MMU
&gt; #include &lt;file&gt;_mm.&lt;ext&gt;
&gt; #else
&gt; #include &lt;file&gt;_no.&lt;ext&gt;
&gt; #endif

On top of this file merge I have done a simplistic merge of m68k and
m68knommu Kconfig, which primarily attempts to keep existing options and
menus in place. Other than a handful of options being moved it produces
identical .config outputs on m68k and m68knommu targets I tested it on.

With this in place there is now quite a bit of scope for merge cleanups
in future patches.

Signed-off-by: Greg Ungerer &lt;gerg@uclinux.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Linux-2.6.12-rc2</title>
<updated>2005-04-16T22:20:36+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@ppc970.osdl.org</email>
</author>
<published>2005-04-16T22:20:36+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=1da177e4c3f41524e886b7f1b8a0c1fc7321cac2'/>
<id>1da177e4c3f41524e886b7f1b8a0c1fc7321cac2</id>
<content type='text'>
Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.

Let it rip!
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.

Let it rip!
</pre>
</div>
</content>
</entry>
</feed>
