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

[Philip Levis]

On Jul 25, 2006, at 2:14 PM, David Moss wrote:

>
> SUMMARY
> * The HAL is broken as is and needs to be thought out some more to  
> provide
> one set of basic flash interfaces that works on each flash type  
> with no
> behavior inconsistencies.  Abstracting flash by providing direct  
> access
> through a common interface with predictable behavior is the key.   
> Volume
> abstractions can further be provided on top of that, but should not  
> be the
> basic means of accessing flash.
>
> * Above the HAL layer, the HIL should not be chip dependant.  If  
> the HAL is
> designed and built correctly (it's the Abstraction Layer after  
> all), the
> implementation layer should be written once, used everywhere.  The  
> AT45DB
> should look like a smaller M25P80 from the application standpoint.   
> Chip
> Dependant HIL == Chip Dependant Application.  And that breaks the  
> model for
> TinyOS.

I could be mistaken, but my understanding is that the current HILs  
are completely chip independent. You mentioned that you tried using  
earlier implementations. Do the current ones still have the same issues?


>
> * The LogStorage looks great - provided the user defining volumes and
> software knows that a circular log can't be implemented in less  
> than 2 erase
> units.
>
> * The ConfigStorage component should stop looking like the  
> BlockStorage
> component by getting rid of addresses in the arguments, taking a  
> load off
> the application layer.  If multiple structs are to be stored in
> ConfigStorage, key-value look ups should be considered as a simple,
> alternative implementation.
>
> * BlockStorage looks just like the basic flash interfaces previously
> described, but with some data verifying functionality. This  
> functionality
> should be well documented, and its implementation and behavior  
> should be
> identical on any flash chip to allow an application to port to any  
> platform.
> It would be nice to be able to find where the next writable address is
> located.
>
> * The address ranges an application is able to read/write should be  
> enforced
> - i.e. to prevent the app from using BlockStorage to overwrite an  
> area where
> the CRC's are kept.
>
> * Remove the confusing web of typedef's that translate back into basic
> variable types.
>
> * Remove the differences and references to commit, sync, and  
> flush.  Choose
> one.  They all basically mean the same thing.
>
> * Keep in mind that it's easy to define a volume simply as the size  
> of a
> sector, and enforce full volume-sized erases when you go to erase  
> something.
> This would help make flash access more chip-independent by removing  
> the
> erase unit size inconsistencies.
>


There are all useful, concrete comments. Having them in summary is  
great.

Phil