[Tinyos-2-commits] CVS: tinyos-2.x/doc/txt tep103.txt,1.3,1.4

[David Gay]

Update of /cvsroot/tinyos/tinyos-2.x/doc/txt
In directory sc8-pr-cvs10.sourceforge.net:/tmp/cvs-serv10110

Modified Files:
	tep103.txt 
Log Message:
rationale
some beginning of multiple storage chips


Index: tep103.txt
===================================================================
RCS file: /cvsroot/tinyos/tinyos-2.x/doc/txt/tep103.txt,v
retrieving revision 1.3
retrieving revision 1.4
diff -C2 -d -r1.3 -r1.4
*** tep103.txt	13 Sep 2006 16:51:09 -0000	1.3
--- tep103.txt	13 Sep 2006 17:45:08 -0000	1.4
***************
*** 70,74 ****
  derived from the timing and power consumption of erase and write operations
  (for NOR flash, values are for the STMicroelectronics M25P family, for NAND
! flash, values are from a Samsung datasheet). Energy/byte for reads appears
  to depend mostly on how long the read takes (the power consumptions are
  comparable), i.e., on the efficiency of the bus + processor.
--- 70,74 ----
  derived from the timing and power consumption of erase and write operations
  (for NOR flash, values are for the STMicroelectronics M25P family, for NAND
! flash, values are from the Samsung datasheet). Energy/byte for reads appears
  to depend mostly on how long the read takes (the power consumptions are
  comparable), i.e., on the efficiency of the bus + processor.
***************
*** 95,99 ****
    reimplemented for these other chips, in part because it does not 
    support some applications (e.g., network reprogramming) very well.
!   
  One approach to hiding the differences between different flash chips is to
  provide a disk-like, block interface (with, e.g., 512B blocks). This is the
--- 95,102 ----
    reimplemented for these other chips, in part because it does not 
    support some applications (e.g., network reprogramming) very well.
! 
! 2. Storage in TinyOS 2.x
! ====================================================================
! 
  One approach to hiding the differences between different flash chips is to
  provide a disk-like, block interface (with, e.g., 512B blocks). This is the
***************
*** 108,128 ****
    table is too expensive on many mote-class devices.
  
! Another approach to supporting multiple flash chips is to build a
! file system (like Matchbox) which can be implemented for multiple
! flash chips. However, TinyOS is currently targeted at running a 
! single application, and many applications know their storage needs
! in advance: for instance, a little space for configuration data, and
! everything else for a log of all sampled data. In such cases, the
! flexibility offered by a filing system (e.g., arbitrary numbers of
! files) is overkill, and may come at the expense of implementation
! and runtime complexity.
  
! Instead, TinyOS 2.x, divides flash chips into separate volumes (with
! sizes fixed at compile-time). Each volume provides a single storage
! abstraction (the abstraction defines the format). So far there are three
! such abstractions: large objects written in a single session,
! small objects with arbitrary reads and writes, and logs. This approach
! has two advantages:
  
  - Each abstraction is relatively easy to implement on a new flash chip, and
    has relatively little overhead.
--- 111,147 ----
    table is too expensive on many mote-class devices.
  
! A second approach is to provide a generic low-level interface providing
! operations (read, write, erase) corresponding to the basic flash
! operations, along with information describing the flash chip's layout
! (minimum write and erase unit, timing information, etc). However,
! we believe that the large differences between NAND and NOR flash (see the
! table above), in particular the differences in reliability, write and
! erase units, make the design of a useful generic low-level interface
! tricky at best. 
  
! We thus believe it is best, for now at least, to define high-level
! storage abstractions that are useful for sensor network applications,
! and leave their implementation up to each flash chip - such abstractions
! will be necessary anyway. We leave open the possibility that a future
! TEP may define portable lower-level flash interfaces (either for all
! flash chips, or, e.g., for NOR-family flashes). Such low-level
! interfaces would allow implementations of the storage abstractions
! defined in this TEP to be used for multiple flash chips.
  
+ This TEP describes three high-level storage abstractions: large objects
+ written in a single session, small objects with arbitrary reads and
+ writes, and logs. TinyOS 2.x, divides flash chips into separate volumes
+ (with sizes fixed at compile-time). Each volume provides a single
+ storage abstraction (the abstraction defines the format).
+ 
+ We prefer the use of single abstractions over fixed-size volumes over
+ the use of a more general filing system (like Matchbox) for several
+ reasons:
+      
+ - TinyOS is currently targeted at running a single application, and many
+   applications know their storage needs in advance: for instance, a
+   little space for configuration data, and everything else for a log of
+   all sampled data. In such cases, the flexibility offered by a filing
+   system (e.g., arbitrary numbers of files) is overkill,
  - Each abstraction is relatively easy to implement on a new flash chip, and
    has relatively little overhead.
***************
*** 134,153 ****
    the same number of time, to maximise flash chip lifetime).
  
! New abstractions (including a filing system) can easily be added to this
! framework, or can be built on top of these abstractions.
  
  The rest of this TEP covers some principles for the organisation of
! flash chips (Section 2), then describes the flash volumes and
! storage abstractions in detail (Section 3).
  
  
! 2. HPL/HAL/HIL Architecture
  ====================================================================
  
  The flash chip architecture follows the three-layer Hardware
  Abstraction Architecture (HAA), with each chip providing a presentation
! layer (HPL, Section 2.1), adaptation layer (HAL, Section 2.2) and
! platform-independent interface layer (the storage abstractions described in
! Section 3) [2_]. The implementation of these layers SHOULD be found in the
  ``tos/chips/CHIPNAME`` directory. If a flash chip is part of a larger
  family with a similar interface, the HAA SHOULD support all family members
--- 153,172 ----
    the same number of time, to maximise flash chip lifetime).
  
! New abstractions (including a filing system...) can easily be added to
! this framework.
  
  The rest of this TEP covers some principles for the organisation of
! flash chips (Section 3), then describes the flash volumes and
! storage abstractions in detail (Section 4).
  
  
! 3. HPL/HAL/HIL Architecture
  ====================================================================
  
  The flash chip architecture follows the three-layer Hardware
  Abstraction Architecture (HAA), with each chip providing a presentation
! layer (HPL, Section 3.1), adaptation layer (HAL, Section 3.2) and
! platform-independent interface layer (HIL, Section 3.3) [2_]. 
! The implementation of these layers SHOULD be found in the
  ``tos/chips/CHIPNAME`` directory. If a flash chip is part of a larger
  family with a similar interface, the HAA SHOULD support all family members
***************
*** 158,162 ****
  
  
! 2.1 Hardware Presentation Layer (HPL)
  --------------------------------------------------------------------
  
--- 177,181 ----
  
  
! 3.1 Hardware Presentation Layer (HPL)
  --------------------------------------------------------------------
  
***************
*** 173,177 ****
  particular flash chip found on the platform.
  
! 2.2 Hardware Adaptation Layer (HAL)
  --------------------------------------------------------------------
  
--- 192,196 ----
  particular flash chip found on the platform.
  
! 3.2 Hardware Adaptation Layer (HAL)
  --------------------------------------------------------------------
  
***************
*** 184,189 ****
  abstractions that interact cleanly with the rest of the flash system.
  
  
! 3. Non-Volatile Storage Abstracitons in TinyOS 2.x 
  ===================================================================
  
--- 203,221 ----
  abstractions that interact cleanly with the rest of the flash system.
  
+ 3.3 Hardware Interface Layer (HIL)
+ --------------------------------------------------------------------
  
! Each flash chip MUST provide implementations of the storage abstractions
! described in Section 4. These abstractions MUST be presented in
! components named ``ChipAbstractionC``, e.g., ``At45dbLogStorageC``.
! 
! Each platform MUST have ``AbstractionC`` components (e.g., ``LogStorageC``)
! implementing the storage abstractions of Section 4. Platforms with a single
! storage chip SHOULD simply make ``AbstractionC`` be a simple configuration
! wrapping the appropriate ``ChipAbstractionC`` component. Platforms with
! multiple storage chips SHOULD redirect uses of ``AbstractionC`` to the 
! appropriate storage chip, based on the requested volume.
! 
! 4. Non-Volatile Storage Abstractions
  ===================================================================
  
***************
*** 192,196 ****
  volume structure discussed in the introduction.
  
! 3.1. Volumes
  -------------------------------------------------------------------
  
--- 224,228 ----
  volume structure discussed in the introduction.
  
! 4.1. Volumes
  -------------------------------------------------------------------
  
***************
*** 235,239 ****
  
  
! 3.2 Large objects
  ------------------------------------------------------------------
  
--- 267,271 ----
  
  
! 4.2 Large objects
  ------------------------------------------------------------------
  
***************
*** 295,299 ****
  
  
! 3.3 Logging
  ------------------------------------------------------------------
  
--- 327,331 ----
  
  
! 4.3 Logging
  ------------------------------------------------------------------
  
***************
*** 391,395 ****
  
  
! 3.4 Small objects:
  ------------------------------------------------------------------
  
--- 423,427 ----
  
  
! 4.4 Small objects:
  ------------------------------------------------------------------
  
***************
*** 446,450 ****
  definitions.
  
! 4. Implementations
  ====================================================================
  
--- 478,482 ----
  definitions.
  
! 5. Implementations
  ====================================================================
  
***************
*** 454,458 ****
  
  
! 5. Authors' Addresses
  ====================================================================
  
--- 486,490 ----
  
  
! 6. Authors' Addresses
  ====================================================================
  
***************
*** 474,478 ****
  | email - jhui at archedrock.com
  
! 6. Citations
  ====================================================================
  
--- 506,510 ----
  | email - jhui at archedrock.com
  
! 7. Citations
  ====================================================================