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

[Vlado Handziski]

I am replying to Jonathan, but this is a general comment to all participants
in the thread.

On 7/26/06, Jonathan Hui <jwhui at cs.berkeley.edu> wrote:
>
> On 7/25/06, Joe Polastre <joe at polastre.com> wrote:
> > David Moss makes a great point--By using get() functions combined with
> > the lowest common denominator, you can build Block/Config/Log above
> > it.  If you go back and re-read the Flexible Hardware Abstraction
> > paper, it clearly articulates that you should use HAL interfaces for
> > optimal performance.  For optimal hardware independence, you should
> > use HIL interfaces.
>
> Joe, I guess you and I differ in philosophy here. David Gay's and my
> goal was to not only provide hardware independence but not sacrafice a
> huge amount of performance in doing it. If you consider the design
> difference between the AT45DB and STM25P implementations, they are
> significant and for good reasons. More on this below.


I am not sure what the disagreement is actually about. I think we all agree
that the chips _are_ different and the respective HALs should represents the
"best abstractions" for this particular chip, exporting the full
capabilities of the hardware. The HALs should not compromise this, not even
if the goal is more simple/common HIL implementation. This is completely
independent from the question if the current flash HILs interfaces are the
best cross-chip abstraction for implementing a filing system like Blackbook.
I think David Moss confused either HAL and HIL in his original mail or the
difference between a HIL interface and HIL implementation. I think that the
HAA is quite clear on this.


> Jonathan's comments when taken in the context of the original paper
> > are in conflict--The goal of the HIL is not performance but
> > interoperability.  As such, the interface that provides the greatest
> > interoperability should be used at the HIL.  The interfaces that
> > provide the greatest performance should be used at the HAL.  David
> > Moss has made an excellent case that the current HIL interfaces are
> > unsuitable for building file systems in a platform independent manner.
> >  With this feedback, I believe it is worthwhile to revisit why
> > Config/Block/Log are the appropriate cross-platform HIL interfaces.
>
> Sure, so we decided to take a compromise. The HILs proposed in TEP103
> are implemented using the proposed HALs. David Gay and I, as chip
> developers, decided to provide chip-specific implementations of HILs
> that are most likely to have higher performance than a common
> implementation across both.


Again I think that we need to separate this discussion in two parts: 1. Are
the selected HALs for the specific chips the best abstractions providing
full access to the HW capabilities? and 2. What kind of HIL interfaces we
think are the best for implementing chip/platform independent WSN
applications using permanent external storage.

The implementation of the HIL components that transform between the
chip-specific HALs and the wanted HIL interface is not constrained in any
way by the HAA. In some cases, when the HALs are very similar, we can
achieve a common HIL component implementation (by pulling info from the
lower layers using "get" as David said) thas sits on a very thin glue over
the HAL components.
But this is not a general requirement and is not explicitly required by the
HAA. Let's take a hypothetical example where the selected HIL interface is
very close to the HAL interface of one of the chips  (the "best" or the
"newest" one) and is quite different from the HALs of the other "older"
chips.  It is clear that the developer of the driver for the "best" chip
will like to have a dedicated HIL component implementation that will be very
thin. The driver developers for the "older" chips will have to invest more
effort to implement in software all the functions required by the HIL
interface that are not provided by the particular chip hardware and are not
exported by its HAL.

David Moss' real point is he'd like to see another HIL live along side
> the proposed Config/Block/Log offerings. I never said Config/Block/Log
> are the *only* cross-platform HIL interfaces, they are just the first
> three that we proposed. You can implement David Moss' proposed HIL on
> top of the current HALs and Blackbook would use that. In his case,
> he's willing to suffer the performance hit of sitting on top of an
> HIL.


Exactly. This is a discussion about HILs and should not be confused with the
HALs.

The difference between Blackbook and Config/Block/Log is that it is a
> much more general storage system and requires much more code to
> maintain. So it's natural that David Moss would like to implement it
> on top of an HIL. In reality, his proposed HIL is pretty similar to
> the BlockStorage interface, and maybe some small tweaks to it would
> satisfy his requests. It seemed like only a few things were getting in
> his way, some of which have already been fixed.
>


I think that this is the best way forward. Let's see what is missing from
the current HIL interfaces that prevent David to implement his abstraction.
If the shortcomings can be addressed with simple changes of the existing HIL
interfaces, than this is the best way. If not, we should consider including
David's abstraction as a new HIL interface.

Vlado
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.millennium.berkeley.edu/pipermail/tinyos-devel/attachments/20060726/df8fd7a6/attachment.html