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
<[email protected]> 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.
This results in a tree that builds and runs on m68knommu targets that
I tested, and at least builds with seemingly no change on m68k targets
(I have not actually tested anything on a real m68k target). Configuring
kernels results in the .config files containing the same option sets
(though a few options appear in a different place/order).
Inside of the new arch/m68k is a little messy in the kernel and mm
directories. There is plenty of scope for cleanup and merge on the
files in here - but I want to leave that for follow up patches after
this initial directory merge. As a data point, when we merged the
m68k and m68knommu include files we had something like 70 or 80
duplicate but separate files, after some cleanups that is now down to
10. Ongoing cleanup will merge some of these remaining ones as well.
Thoughts?
Regards
Greg
------------------------------------------------------------------------
Greg Ungerer -- Principal Engineer EMAIL: [email protected]
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
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
> <[email protected]> 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
On Fri, Feb 18, 2011 at 01:07, Greg Ungerer <[email protected]> wrote:
> 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
> <[email protected]> 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.
Initial feedback:
--- a/arch/m68k/Makefile
+++ b/arch/m68k/Makefile
@@ -1,5 +1,5 @@
ifdef CONFIG_MMU
-include arch/m68k/Makefile_mm
+include $(srctree)/arch/m68k/Makefile_mm
else
-include arch/m68k/Makefile_no
+include $(srctree)/arch/m68k/Makefile_no
endif
Don't you need to add "# CONFIG_MMU is not set" to all m68knommu
defconfig files?
Building...
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
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
>> <[email protected]> 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: [email protected]
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
On Fri, Feb 18, 2011 at 12:27, Geert Uytterhoeven <[email protected]> wrote:
> On Fri, Feb 18, 2011 at 01:07, Greg Ungerer <[email protected]> wrote:
>> 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
>> <[email protected]> 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.
>
> Building...
Builds fine (all test configs), runs on ARAnyM.
Let's go ahead?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Hi Geert,
On 19/02/11 01:24, Geert Uytterhoeven wrote:
> On Fri, Feb 18, 2011 at 12:27, Geert Uytterhoeven<[email protected]> wrote:
>> On Fri, Feb 18, 2011 at 01:07, Greg Ungerer<[email protected]> wrote:
>>> 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
>>> <[email protected]> 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.
>>
>> Building...
>
> Builds fine (all test configs), runs on ARAnyM.
>
> Let's go ahead?
What sort of timing do you think makes sense?
Is for 2.6.39 too soon?
Regards
Greg
------------------------------------------------------------------------
Greg Ungerer -- Principal Engineer EMAIL: [email protected]
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
On Fri, Feb 18, 2011 at 23:12, Greg Ungerer <[email protected]> wrote:
> On 19/02/11 01:24, Geert Uytterhoeven wrote:
>> On Fri, Feb 18, 2011 at 12:27, Geert Uytterhoeven<[email protected]>
>> wrote:
>>>
>>> On Fri, Feb 18, 2011 at 01:07, Greg Ungerer<[email protected]> wrote:
>>>>
>>>> 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
>>>> <[email protected]> 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.
>>>
>>> Building...
>>
>> Builds fine (all test configs), runs on ARAnyM.
>>
>> Let's go ahead?
>
> What sort of timing do you think makes sense?
> Is for 2.6.39 too soon?
Personally, I don't mind. 2.6.39 is OK for me. I guess the safest way
is to let Linus
execute the script? Before or after the merge window?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Hi Geert,
On 19/02/11 18:39, Geert Uytterhoeven wrote:
> On Fri, Feb 18, 2011 at 23:12, Greg Ungerer<[email protected]> wrote:
>> On 19/02/11 01:24, Geert Uytterhoeven wrote:
>>> On Fri, Feb 18, 2011 at 12:27, Geert Uytterhoeven<[email protected]>
>>> wrote:
>>>>
>>>> On Fri, Feb 18, 2011 at 01:07, Greg Ungerer<[email protected]> wrote:
>>>>>
>>>>> 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
>>>>> <[email protected]> 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.
>>>>
>>>> Building...
>>>
>>> Builds fine (all test configs), runs on ARAnyM.
>>>
>>> Let's go ahead?
>>
>> What sort of timing do you think makes sense?
>> Is for 2.6.39 too soon?
>
> Personally, I don't mind. 2.6.39 is OK for me. I guess the safest way
> is to let Linus
> execute the script? Before or after the merge window?
Well I was going to construct the merge as a single git commit
(which is equivalent to running this script and applying the patch).
Linus would then just pull this.
The best timing for me is near the end of the merge window.
That way we can both get in any other changes first.
Regards
Greg
------------------------------------------------------------------------
Greg Ungerer -- Principal Engineer EMAIL: [email protected]
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
On Mon, Feb 21, 2011 at 00:53, Greg Ungerer <[email protected]> wrote:
> On 19/02/11 18:39, Geert Uytterhoeven wrote:
>>
>> On Fri, Feb 18, 2011 at 23:12, Greg Ungerer<[email protected]> wrote:
>>>
>>> On 19/02/11 01:24, Geert Uytterhoeven wrote:
>>>>
>>>> On Fri, Feb 18, 2011 at 12:27, Geert Uytterhoeven<[email protected]>
>>>> wrote:
>>>>>
>>>>> On Fri, Feb 18, 2011 at 01:07, Greg Ungerer<[email protected]>
>>>>> wrote:
>>>>>>
>>>>>> 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
>>>>>> <[email protected]> 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.
>>>>>
>>>>> Building...
>>>>
>>>> Builds fine (all test configs), runs on ARAnyM.
>>>>
>>>> Let's go ahead?
>>>
>>> What sort of timing do you think makes sense?
>>> Is for 2.6.39 too soon?
>>
>> Personally, I don't mind. 2.6.39 is OK for me. I guess the safest way
>> is to let Linus
>> execute the script? Before or after the merge window?
>
> Well I was going to construct the merge as a single git commit
> (which is equivalent to running this script and applying the patch).
> Linus would then just pull this.
>
> The best timing for me is near the end of the merge window.
> That way we can both get in any other changes first.
Sounds like a plan, OK!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
On Fri, 18 Feb 2011, Greg Ungerer wrote:
> Inside of the new arch/m68k is a little messy in the kernel and mm
> directories. There is plenty of scope for cleanup and merge on the
> files in here - but I want to leave that for follow up patches after
> this initial directory merge. As a data point, when we merged the
> m68k and m68knommu include files we had something like 70 or 80
> duplicate but separate files, after some cleanups that is now down to
> 10. Ongoing cleanup will merge some of these remaining ones as well.
>
> Thoughts?
Hmm, how are you going to deal with the fact, that m68knommu uses
genirq, m68k not? I guess there are some more points like this
(clockevents, clocksource ...)
Is there a plan to move m68k to the generic facilities as well ?
Thanks,
tglx
On Friday 18 February 2011 13:01:53 Greg Ungerer wrote:
> >> Attached is a script and patch that does a kind of brute force
> >> simplistic merge of the directories and files. (Thanks to Stephen King
> >> <[email protected]> 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 :-)
I had absolutely no memory of having done said script, but if Sam
says wrote it did, that's probably true.
I was just about to say how much I like your script when I read
that it was my idea...
Arnd
On Mon, Feb 21, 2011 at 10:43:15PM +0100, Arnd Bergmann wrote:
> On Friday 18 February 2011 13:01:53 Greg Ungerer wrote:
> > >> Attached is a script and patch that does a kind of brute force
> > >> simplistic merge of the directories and files. (Thanks to Stephen King
> > >> <[email protected]> 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 :-)
>
> I had absolutely no memory of having done said script, but if Sam
> says wrote it did, that's probably true.
>
> I was just about to say how much I like your script when I read
> that it was my idea...
See semi original version in: 49148020bcb6910ce71417bd990a5ce7017f9bd3
Sam
Hi Thomas,
On 22/02/11 07:18, Thomas Gleixner wrote:
> On Fri, 18 Feb 2011, Greg Ungerer wrote:
>> Inside of the new arch/m68k is a little messy in the kernel and mm
>> directories. There is plenty of scope for cleanup and merge on the
>> files in here - but I want to leave that for follow up patches after
>> this initial directory merge. As a data point, when we merged the
>> m68k and m68knommu include files we had something like 70 or 80
>> duplicate but separate files, after some cleanups that is now down to
>> 10. Ongoing cleanup will merge some of these remaining ones as well.
>>
>> Thoughts?
>
> Hmm, how are you going to deal with the fact, that m68knommu uses
> genirq, m68k not? I guess there are some more points like this
> (clockevents, clocksource ...)
Initially it has no impact. This first step pretty much just
combines the 2 directories, it doesn't attempt to do a fine
grained merge of each file. (It does factor out identical
files - quite a few in arch/m68k/lib for example).
> Is there a plan to move m68k to the generic facilities as well ?
I'll look at doing what I can as I work through merging all the
underlying pieces :-)
Regards
Greg
------------------------------------------------------------------------
Greg Ungerer -- Principal Engineer EMAIL: [email protected]
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
On Tue, Feb 22, 2011 at 03:05, Greg Ungerer <[email protected]> wrote:
> On 22/02/11 07:18, Thomas Gleixner wrote:
>> On Fri, 18 Feb 2011, Greg Ungerer wrote:
>>> Inside of the new arch/m68k is a little messy in the kernel and mm
>>> directories. There is plenty of scope for cleanup and merge on the
>>> files in here - but I want to leave that for follow up patches after
>>> this initial directory merge. As a data point, when we merged the
>>> m68k and m68knommu include files we had something like 70 or 80
>>> duplicate but separate files, after some cleanups that is now down to
>>> 10. Ongoing cleanup will merge some of these remaining ones as well.
>>>
>>> Thoughts?
>>
>> Hmm, how are you going to deal with the fact, that m68knommu uses
>> genirq, m68k not? I guess there are some more points like this
>> (clockevents, clocksource ...)
>
> Initially it has no impact. This first step pretty much just
> combines the 2 directories, it doesn't attempt to do a fine
> grained merge of each file. (It does factor out identical
> files - quite a few in arch/m68k/lib for example).
>
>
>> Is there a plan to move m68k to the generic facilities as well ?
Moving m68k to genirq is (the next thing?) on my list...
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
> >
> >
> >> Is there a plan to move m68k to the generic facilities as well ?
>
> Moving m68k to genirq is (the next thing?) on my list...
If I succeed migrating sparc32 to genirq I hope to be of a little help here.
It looks like a bigger task to migrate m68k than it was/is to migrate sparc32.
It would be _very_ nice to get the last two architectures migrated to genirq.
Sam
On Tue, Feb 22, 2011 at 08:29, Sam Ravnborg <[email protected]> wrote:
>> >> Is there a plan to move m68k to the generic facilities as well ?
>>
>> Moving m68k to genirq is (the next thing?) on my list...
>
> If I succeed migrating sparc32 to genirq I hope to be of a little help here.
> It looks like a bigger task to migrate m68k than it was/is to migrate sparc32.
>
> It would be _very_ nice to get the last two architectures migrated to genirq.
Aren't your forgetting s390?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
On Tue, Feb 22, 2011 at 08:40:53AM +0100, Geert Uytterhoeven wrote:
> On Tue, Feb 22, 2011 at 08:29, Sam Ravnborg <[email protected]> wrote:
> >> >> Is there a plan to move m68k to the generic facilities as well ?
> >>
> >> Moving m68k to genirq is (the next thing?) on my list...
> >
> > If I succeed migrating sparc32 to genirq I hope to be of a little help here.
> > It looks like a bigger task to migrate m68k than it was/is to migrate sparc32.
> >
> > It would be _very_ nice to get the last two architectures migrated to genirq.
>
> Aren't your forgetting s390?
Hmm, I had the understanding that m68k and sparc32 was the only two remaining :-(
But I did not check.
s390 sees more active maintenance so if they become the last non genirq user,
then they may feel a bit of pressure :-)
Sam
Greg,
On Tue, 22 Feb 2011, Greg Ungerer wrote:
> On 22/02/11 07:18, Thomas Gleixner wrote:
> > On Fri, 18 Feb 2011, Greg Ungerer wrote:
> > > Inside of the new arch/m68k is a little messy in the kernel and mm
> > > directories. There is plenty of scope for cleanup and merge on the
> > > files in here - but I want to leave that for follow up patches after
> > > this initial directory merge. As a data point, when we merged the
> > > m68k and m68knommu include files we had something like 70 or 80
> > > duplicate but separate files, after some cleanups that is now down to
> > > 10. Ongoing cleanup will merge some of these remaining ones as well.
> > >
> > > Thoughts?
> >
> > Hmm, how are you going to deal with the fact, that m68knommu uses
> > genirq, m68k not? I guess there are some more points like this
> > (clockevents, clocksource ...)
>
> Initially it has no impact. This first step pretty much just
> combines the 2 directories, it doesn't attempt to do a fine
> grained merge of each file. (It does factor out identical
> files - quite a few in arch/m68k/lib for example).
Ah, ok. So you doing it similar to the plain move approach which we
did with x86 back then.
> > Is there a plan to move m68k to the generic facilities as well ?
>
> I'll look at doing what I can as I work through merging all the
> underlying pieces :-)
Fair enough.
Thanks,
tglx
Hi Geert,
Looks like we both have our changes for m68k and m68knommu in Linus'
git tree for this merge window. Do you plan to push anything else?
If you are done I will prepare a single git commit on the m68knommu
git tree that merges the m68knommu and m68k arch branches. I will
post here again for one last check over early next week, and if
everyone is happy I will ask Linus to pull it later next week.
How does that sound?
Regards
Greg
------------------------------------------------------------------------
Greg Ungerer -- Principal Engineer EMAIL: [email protected]
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
Hi Greg,
On Fri, Mar 18, 2011 at 00:59, Greg Ungerer <[email protected]> wrote:
> Looks like we both have our changes for m68k and m68knommu in Linus'
> git tree for this merge window. Do you plan to push anything else?
Nothing planned for now.
> If you are done I will prepare a single git commit on the m68knommu
> git tree that merges the m68knommu and m68k arch branches. I will
> post here again for one last check over early next week, and if
> everyone is happy I will ask Linus to pull it later next week.
>
> How does that sound?
Sounds great! Thx!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds