[mc1322x] Contiki tree resync

[Jon Smirl]

On Fri, Oct 30, 2009 at 11:51 AM, Mariano Alvira <mar at devl.org> wrote:
> On Fri, Oct 30, 2009 at 11:01:07AM -0400, Jon Smirl wrote:
>> On Fri, Oct 30, 2009 at 10:12 AM, Mariano Alvira <mar at devl.org> wrote:
>> > On Thu, Oct 29, 2009 at 11:00:42PM -0400, Jon Smirl wrote:
>>
>> Git is very different than CVS, with git no one else needs server
>> access.  Linus is the only person with access to his tree.
>
> Yes. But Linus isn't the only one with repositories on kernel.org ---
> which is more what I was talking about. So if there is anyone on this
> list who would like to use devl.org to put their repo's in a public
> place then please feel free to contact me.
>
>>
>> Everyone else makes patches in their own local git repositories. When
>> these patches are ready they get posted to the email list (there are
>> git commands for this).
>
> Yes, generally this is the workflow I like.
>
>> Before you approve something, you should make a new branch, apply the
>> patch and check it out. If you don't like it, send some email comments
>> and delete the test branch. If you like it, merge the test branch into
>> your main branch and push the result out. You function as a
>> gatekeeper. It's up to you to do some basic testing before accepting
>> things into your mainline. Linus does that pretty much full time, but
>> his project is a little larger.
>
> Hence the need for "basic testing". Right now we, as well as Contiki,
> has "next to none".
>
> I'd also prefer something "basically automatic".

For a start...
Does it compile?
Does it boot?
Do two or three random sample apps still work?

That's enough for this project. The quality control just needs to
ensure that the mainline does not get into a completely
non-functioning state.


>
>> In our case this is complicated by the existence of the CVS
>> repository.
>
>> If you could get Contiki to switch to git you could eliminate the need
>> for you to do the maintainer role. Adam would end up doing it instead.
>> You'd become a trusted lieutenant like GregKH is for Linus.
>
> Well, _I'm_ not going to be the one to email Contiki and tell them to
> use git... :)
>
> I feel Contiki might have too many "trusted lieutenants". I see it
> more as the u-boot scenario where each developer gets the thing they
> need to work, working, however they can, and then they get it into
> mainline without much consideration to the overall program. I think
> OpenOCD has a similar issue. I suppose it's a challenge for any
> software that is meant to run on a variety of hardware. Certainly a
> lot of the code for Contiki is nicely modular with clear interfaces
> and separations (e.g. RIME). Other places need work. (e.g. coffee and
> the sd card interface).

That is a correct assessment of the problem. Linux actually went
through the same transition around 2.6.0.  Before that there were no
lieutenants, it was just Linus and the mob.

uboot has lost control. That's why one party that is very dependent on
multi-platform u-boot (Pengutronix) made u-boot V2.  All of the
trusted lieutenants on Linux work for places like ARM, Intel, Cisco,
Redhat, etc. Companies that are dependent on Linux for the long term,
not a single product release. These companies know they have to keep
the architecture clean or bear the burden of expensive maintenance
later. A one-shot user doesn't care about the maintenance load but
one-shot users contribute a lot of initial code for new chips.

The maintainer for this project should really be a Freescale employee
and you are a trusted lieutenant. But we haven't done enough yet to
get Freescale to abandon IAR. Freescale employees now maintain their
ARCH ports on Linux.



>
>> CVS makes it hard to rearchitect things. There's no easy way to push
>> out a repo with a new core API and then get the ARCH maintainers to do
>> fixes for their ARCHs and then commit everything simultaneously.
>>
>> Maybe they can be talked into doing development in git and using
>> sourceforge CVS to simply track the git repo.
>
> I don't know if they can be convinced or not. I'm pretty new to
> contiki and haven't seen that discussed on the list. I certainly agree
> with you though about CVS making it hard for the ARCH maintainers.
>
>> For my application I need to get the TCPIP support working (either V4
>> or V6). I've been playing with V6 and 6lowpan. I keep getting bogged
>> down because I'm simultaneously working on a new CPU, with new
>> hardware, new protocol (6lowpan), etc. Right now I'm trying to figure
>> out why wireshark isn't fulling decoding 6lowpan packets. If I can't
>> decode the packets it is hard to see what is wrong with them.
>
> Yeah, that's a whole lot of 'new' to be handling all at
> once.
>
> I haven't done much here. My only experience has been to generate a
> pcap from a sniffed channel and look at 802.15.4 frames.
>
> I have new hardware that I've been meaning to get to. It's a Redbee
> ethernet gateway using the ENC28J60 MAC/PHY. We've used that part
> before on a PIC based design and uIP. So that takes out some of the
> unknowns for us. I've haven't done anything with ipv6 other than to
> read a book about it. And I've skimmed the 6lowpan RFCs... looks like
> a big mess. My hope is that Dunkles et. al. will sort it out.

A more cost effective way to do a gateway is to use a $60
Linksys/Dlink wireless router with USB printer support. Reflash it
with dd-wrt or openwrt and add the driver for the 802.15.4 USB stick.
ipv6 is already enabled in the WRT kernels.  You can do this with your
existing hardware but I haven't gotten around to it yet. I'm still
using my desktop PC as the router and a Raven USB stick.

With IPV6 it's not a gateway, it a router. Since they contain state
gateways are a completely unreliable pain. It is always better to go
routable IP everywhere and eliminate the gateway.

We're dependent on Dunkels to add ROLL support also. We want
6lowpan/ROLL so that Zigbee can be eliminated. Zigbee is not IP
routable.

-- 
Jon Smirl
jonsmirl at gmail.com