[Tinyos-devel] Request for comments on TEP 103, due August 10th

[Jonathan Hui]

On 7/26/06, David Moss <dmm at rincon.com> wrote:
> As a developer who's using this technology, time is one of my team's most
> valuable resources.  If my team has to spend twice the amount of time
> testing and developing code just to get it to run on two different
> platforms, then that's not worth it.  The fact that David Gay and Johnathan
> are both writing the same end functionality doesn't seem worth it to me
> because their time is equally valuable.  Trying to get people to adopt
> hardware-dependant technology is much more difficult than getting people to
> adopt hardware-independent technology.  If we eventually have 50 different
> flash types, who's going to write and test all that code for the basic
> storage implementations?  Not me, and not my team. Time to erase is one
> thing, but time to market is another.  An increase in nitty gritty
> bit-banging performance is usually not worth a delay in getting to a robust
> and finished product.

Depends what your end goals are. If you're trying maximize the
performance a chip can give you while minimizing resource consumption,
then having a separate implementation per chip is desireable. Note
that you can do this while still providing a chip-independent
interface. We have had the luxury of using "fat" nodes since they are
what Crossbow, Moteiv, etc. provides. When cost is an issue, you might
want to spend the extra time to do the chip-dependent optimization
that still provides a chip-independent interface so that  your app
still works.

> Having optional platform-dependent and -independent interfaces is probably
> the best route to meet everyone's needs.  If you want your app to work
> everywhere, use the platform-independent interfaces.  If you want your app
> to take full advantage of extra features on a specific chip, then use the
> implementation tailored to that hardware.  Full documentation should be
> provided on how these interfaces work, how to use them, and what to expect.

Don't get me wrong, I think application portability is important. It
really depends where you draw the "app" line. If most developers just
want a logging abstraction, then that's what they'll use and they
could care less if there's a common or different implementation for
each chip. You are different in that Blackbook is your "app" (the
product you're providing).

To support your concerns, we should look further into what the changes
should be. I'd be in favor of modifying the BlockStorage interfaces
since that seems pretty close to what you need (read/write/erase) and
add the erase unit gets. Then change commit() to sync() which commits
to stable storage. No need to differentiate between sync() and flush()
here. How does that sound?

> I guess what it comes down to is, I can jump in a hybrid or a ferrari and
> expect them to behave the same when I push the pedals, without having to
> reconfigure myself, the car, or know how their engines differ.

Just don't slam the gas pedal in a ferrari and expect to stay on the road ;-)

-- 
Jonathan W. Hui
jwhui at cs.berkeley.edu
http://www.cs.berkeley.edu/~jwhui/