[Tinyos-devel] HplMsp430InterruptSigP.nc

[Vlado Handziski]

No, I never received that mail.

This is one of the reasons why I suggested that having a TEP on the threads
stuff would be useful. All this interventions in the ISRs, the McuSleep,
etc. have to be scrutinized very carefully, because they can introduce bugs
that are very hard to detect post factum. In an ideal world we would have
unit test coverage for all tinyos code, and we can test against regressions,
but for the time being we have to keep the "preemptive" approach.

Vlado

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

> I thought I did send an email about it, but no one ever responded.
> Can't seem to find it now though, so maybe I wrote it and it never got
> sent.... sorry about that.
>
> Motivation was for beginning to support threads in the future.  All
> interrupt handlers need a small bit of code appended to the bottom of
> them, and centralizing all the interrupts seemed the easiest way you
> do it. The changes now don't have this bit of code in their, but once
> we settled on adding the support for threads, having things arranged
> this way seemed easier.  It isn't a *necessary* change, however, and
> everything can be reverted back if people feel this isn't the way to
> go.  My original email basically said the same thing, but I guess you
> never read it (i.e. I never sent it) somehow...
>
> Kevin
>
> On Mon, May 5, 2008 at 10:52 AM, Vlado Handziski
> <handzisk at tkn.tu-berlin.de> wrote:
> > I have several issues with your commit from Apr. 18th:
> >
> >
> > Such major changes need to go through at least a discussion on
> tinyos-devel
> > The current policy of changing core code is to notify the authors in the
> > headers of the files (unless agreed otherwise at a phone call or email
> > thread here)
> > Having default event handlers for all interrupt sources is not without
> > secondary effects. In some cases interrupt flags are cleared just by
> having
> > a ISR defined
> > What was the motivation for the change?
> >  Even if the motivation is good, and we double check that no secondary
> > effect (apart from the bloat) is going to bite us, this is definitely not
> > something that should be buried in /pins !?Vlado
> >
> >
>
>
>
> --
> ~Kevin
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://www.millennium.berkeley.edu/pipermail/tinyos-devel/attachments/20080505/c6fc6f09/attachment-0001.htm