[Tinyos-beta-commits]
CVS: tinyos-1.x/beta/teps/txt tep103.txt, 1.1, 1.2
Jonathan Hui
jwhui at users.sourceforge.net
Wed Jan 26 11:29:04 PST 2005
Update of /cvsroot/tinyos/tinyos-1.x/beta/teps/txt
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv25308
Modified Files:
tep103.txt
Log Message:
- Added a concrete proposal for volume management.
Index: tep103.txt
===================================================================
RCS file: /cvsroot/tinyos/tinyos-1.x/beta/teps/txt/tep103.txt,v
retrieving revision 1.1
retrieving revision 1.2
diff -C2 -d -r1.1 -r1.2
*** tep103.txt 19 Jan 2005 16:35:45 -0000 1.1
--- tep103.txt 26 Jan 2005 19:29:02 -0000 1.2
***************
*** 48,52 ****
A common restriction of flash technology is that each bit can only be
! written once between erases. The table below summarises the differences
between the various flash technologies:
--- 48,52 ----
A common restriction of flash technology is that each bit can only be
! written once between erases. The table below summarizes the differences
between the various flash technologies:
***************
*** 112,116 ****
b. Small objects (Deluge metadata, many other apps):
! This scenario involves keeping a small chunck (less than 100
some bytes). Requires multiple and random reads/writes.
--- 112,116 ----
b. Small objects (Deluge metadata, many other apps):
! This scenario involves keeping a small chunk (less than 100
some bytes). Requires multiple and random reads/writes.
***************
*** 128,132 ****
Size: large
! Reads: from memorised write points or beginning
Writes: sequential, object is linear or circular
Failure model: writes are atomic, failure during/between writes
--- 128,132 ----
Size: large
! Reads: from memorized write points or beginning
Writes: sequential, object is linear or circular
Failure model: writes are atomic, failure during/between writes
***************
*** 137,152 ****
(crash-style) failure
! These interfaces will be offered on top of two ways of sharing the flash:
!
! - Need a way to allocate storage in a way similar to
! ByteEEPROMAllocate. But must do it in a way that is independent of how or
! with what components the application is compiled. For example, when
! switching between program images via Deluge, one app may require storage
! -space not affected by the second app. In most cases, don't care where block
! is, just want isolation and the same region across reboots. Proposal:
! unique strings, size fixed at allocation ("poor man's filing system?")
!
! - a simple filing system (not in 1.2?), may offer subset of a/b/c (note,
! e.g., that directories + atomic sequential files may cover the needs of b)
We envision separate implementations of these abstractions for each class
--- 137,147 ----
(crash-style) failure
! These interfaces will be offered on top of a uniform method of sharing
! the flash. Volumes are allocated in a similar way to fdisk. Volumes
! will be allocated and a partition table kept in non-volatile
! storage. To use a volume, it must be mounted. Thus, volumes exist
! independent of which components the applications are compiled
! with. This allows switching of applications while managing the sharing
! of flash.
We envision separate implementations of these abstractions for each class
***************
*** 191,223 ****
d. Intel Strataflash (should extend to other memory-mapped NOR flashes)
! interface HALStrata { /* In flux until higher level stuff written */
! command result_t lockRange(uint32_t from, uint32_t count);
! command result_t unlockRange(uint32_t from, uint32_t count);
! /* These return to read array mode when done */
! command result_t write(uint32_t address, uint16_t *data, uint8_t count);
! event result_t writeDone(result_t success);
! command result_t erase(uint32_t block);
! event result_t eraseDone(result_t success);
! /* Will probably want to read some amount of device info. Not clear what
! yet, exactly. */
! }
e. M25P:
- interface {
- command result_t read(addr_t addr, void* dest, addr_t len);
- event result_t readDone(result_t result);
! command result_t write(addr_t addr, void* source, addr_t len);
! event result_t writeDone(result_t result);
! command result_t erase(sector_t sector);
! event result_t eraseDone(result_t result);
! command result_t bulkErase();
! event result_t bulkEraseDone();
! }
--- 186,219 ----
d. Intel Strataflash (should extend to other memory-mapped NOR flashes)
! interface HALStrata { /* In flux until higher level stuff written */
! command result_t lockRange(uint32_t from, uint32_t count);
! command result_t unlockRange(uint32_t from, uint32_t count);
! /* These return to read array mode when done */
! command result_t write(uint32_t address, uint16_t *data, uint8_t count);
! event void writeDone(result_t success);
! command result_t erase(uint32_t block);
! event void eraseDone(result_t success);
! /* Will probably want to read some amount of device info. Not clear what
! yet, exactly. */
! }
e. M25P:
! interface {
! command result_t read(addr_t addr, void* dest, addr_t len);
! event result_t readDone(result_t result);
! command result_t write(addr_t addr, void* source, addr_t len);
! event result_t writeDone(result_t result);
! command result_t erase(sector_t sector);
! event result_t eraseDone(result_t result);
!
! command result_t bulkErase();
! event result_t bulkEraseDone();
! }
***************
*** 228,242 ****
b. Presentation: application-level OS service (see discussion above)
c. Space allocation
!
! interface ExtStorageAllocate {
! /* still under discussion */
! a) Standardization process reserves areas of flash for
! TinyOS-wide purposes (e.g. Deluge, configuration).
! Pro: Simple
! Con: Inflexible, hard to change
! b) Very-simple filing system with file size specified at create.
! Pro: Flexible, easy to change
! Con: Complex, resource overhead, etc.
! }
d. Large object
--- 224,259 ----
b. Presentation: application-level OS service (see discussion above)
c. Space allocation
!
! This is similar to fdisk. Allocation of volumes can only occur
! between calls to init() and commit(). init() wipes the volume
! table clean and commit() writes out the volume table.
!
! interface FStorage {
! command result_t init();
! command result_t allocate(uint8_t id, addr_t size);
! command result_t allocateFixed(uint8_t id, addr_t addr, addr_t size);
! command result_t commit();
! event void commitDone(storage_result_t result, uint8_t id);
! }
!
! The mount interface is used to setup access to a specific
! volume.
!
! interface Mount {
! command result_t mount(uint8_t id);
! event void mountDone(storage_result_t result, uint8_t id);
! }
!
! This interface is provided by the components implementing
! BlockRead/Write, ConfigStorage, and LogRead/Write. This
! interface is necessary for components to setup any required
! metadata. For example, ConfigRead may need to know where to
! read a specific configuration. LogWrite may need to search for
! the current offset.
!
! interface VolumeInit {
! command result_t init();
! event void initDone(storage_result_t result);
! }
d. Large object
***************
*** 246,264 ****
// varies by platform. Len must be a multiple of this.
command result_t write(addr_t addr, void* source, addr_t len);
! event result_t writeDone(storage_result_t result);
command result_t erase();
! event result_t eraseDone(storage_result_t result);
command result_t commit();
! event result_t commitDone(storage_result_t result);
}
interface BlockRead {
command result_t read(addr_t addr, void* dest, addr_t len);
! event result_t readDone(storage_result_t result);
command result_t verify();
! event result_t verifyDone(storage_result_t result);
}
--- 263,281 ----
// varies by platform. Len must be a multiple of this.
command result_t write(addr_t addr, void* source, addr_t len);
! event void writeDone(storage_result_t result);
command result_t erase();
! event void eraseDone(storage_result_t result);
command result_t commit();
! event void commitDone(storage_result_t result);
}
interface BlockRead {
command result_t read(addr_t addr, void* dest, addr_t len);
! event void readDone(storage_result_t result);
command result_t verify();
! event void verifyDone(storage_result_t result);
}
***************
*** 268,302 ****
interface ConfigStorage {
command result_t read(addr_t addr, void* dest, addr_t len);
! event result_t readDone(storage_result_t result);
command result_t write(addr_t addr void* source, addr_t len);
! event result_t writeDone(storage_result_t result);
command result_t commit();
! event result_t commitDone(storage_result_t result);
}
f. Large sequential object
! interface LogWrite
! {
command result_t erase();
! event result_t eraseDone(storage_result_t success);
command result_t append(uint8_t* data, uint32_t numBytes);
! event result_t appendDone(uint8_t* data, uint32_t numBytes, result_t success);
command uint32_t currentOffset();
command result_t sync();
! event result_t syncDone(storage_result_t success);
}
! interface LogRead
! {
command result_t read(uint8_t* data, uint32_t numBytes);
! event result_t readDone(uint8_t* data, uint32_t numBytes, result_t success);
command result_t seek(uint32_t cookie);
! event result_t seekDone(storage_result_t success);
}
--- 285,317 ----
interface ConfigStorage {
command result_t read(addr_t addr, void* dest, addr_t len);
! event void readDone(storage_result_t result);
command result_t write(addr_t addr void* source, addr_t len);
! event void writeDone(storage_result_t result);
command result_t commit();
! event void commitDone(storage_result_t result);
}
f. Large sequential object
! interface LogWrite {
command result_t erase();
! event void eraseDone(storage_result_t success);
command result_t append(uint8_t* data, uint32_t numBytes);
! event void appendDone(uint8_t* data, uint32_t numBytes, result_t success);
command uint32_t currentOffset();
command result_t sync();
! event void syncDone(storage_result_t success);
}
! interface LogRead {
command result_t read(uint8_t* data, uint32_t numBytes);
! event void readDone(uint8_t* data, uint32_t numBytes, result_t success);
command result_t seek(uint32_t cookie);
! event void seekDone(storage_result_t success);
}
More information about the Tinyos-beta-commits
mailing list