[Tinyos-devel] Parameterization of UartStream interface in UART abstraction on all platforms?

[Vlado Handziski]

As I said during the teleconference, I think that it is time to migrate to a
proper issue tracker, independent from SF. Neither e-mail, nor wikis alone
are particularly suitable for tracking tickets and reviewing patches. If we
want something lightweight, I think Rietveld from GvR fits the bill quite
nicely:

http://code.google.com/appengine/articles/rietveld.html

TUB is also ready to host such a tracker, the only problem would be the
domain, since most of the tinyos are taken. But maybe the holders will be
happy to release them back to the community.

Vlado

On Thu, May 22, 2008 at 8:10 PM, Kevin Klues <klueska at gmail.com> wrote:

> Glancing through the code one last time, both SpiPacket and I2CPacekt
> aren't parameterized on the atmega128 either.   Whenever the changes
> for UartStream get made, they will need to be made for these guys too.
>
> We need to start maintaining a TODO list of things that need to get
> done and cross them off one by one as they happen.  There's the file
> 'overall-todo' in the tinyos-2.x root, but its extremely outdated.
> I'm going to create a page on the TinyOS wiki to this effect and
> hopefully people will start using it.....
>
> I'm also going to remove the current 'overall-todo' file and replace
> it with a TODO.html that redirects to the wiki if there are no
> objections.
>
> Kevin
>
> On Thu, May 22, 2008 at 1:51 AM, Vlado Handziski
> <handzisk at tkn.tu-berlin.de> wrote:
> > On Thu, May 22, 2008 at 9:43 AM, Philip Levis <pal at cs.stanford.edu>
> wrote:
> >>
> >> On May 21, 2008, at 6:34 PM, Kevin Klues wrote:
> >> > I'm inclined to say we should just leave well enough alone until a
> >> > specific need for it arises.  I normally hate to say this, as I'm all
> >> > for consistency across platforms when appropriate, but in this case
> >> > there are reasons not to do so such as (unnecessary) code bloat and
> >> > incompatibility with legacy code that we dont know about (i.e. not in
> >> > the standard tree).  If someone is willing to put in the effort
> >> > required to make this change I say go for it.  I've just got too many
> >> > other things going on to make all the necessary changes and do them
> >> > well, given that there is not a pressing need for them at the moment.
> >>
> >> This makes sense to me. We should defer doing it until we need to.
> >> Otherwise we have to maintain unnecessary complexity.
> >>
> >
> > I agree with postponing this after the release, but I don't think we
> should
> > wait concrete request pops-up. All HALs should by default be ready to be
> > arbitrated. It is not a large change, and if the overhead is a problem we
> > can always start with NoArbiterC
> >
> > Vlado
> >
>
>
>
> --
> ~Kevin
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://www.millennium.berkeley.edu/pipermail/tinyos-devel/attachments/20080522/61060618/attachment.htm