On Friday 21 July 2006 09:34 am, Ramesh Givindan wrote: > TEP 103 is ready to move from draft to final. [snip] > ... to send them to me before *August 10th*.
This week I started designing with the log storage (TEP 103 logging) component for stm25p. In searching the list archives, I found Ramesh's request for comments. Ramesh, if it is too late to accept my comments below, no worries. The tinyos.net homepage currently shows TEP 103 still in community review. The two suggestions below come from some shortcomings (?) I'm finding with the LogWrite/LogRead interfaces. Please tell me if I'm overlooking obvious solutions using the existing interface definitions. #1 record atomic LogRead.read() I'm storing data objects of varying size, one per record, in a circular log buffer. These objects must be treated as atomic units of data. The stm25p implementation, even for circular logs, appears to correctly enforce record-level atomicity for all functions except LogRead.read(). read() will silently read a partial record if the supplied user buffer is smaller than the record size. This means that some operations, like placing the contents of as many whole records as possible into a message_t's payload, require the use of an intermediate buffer and a second memory copy for each record read. I think a useful addition to the LogRead interface would be a record-atomic readRecord(). It could function much like snprintf(), in that readDone() in response to readRecord() would always return the size of the next record in the log but only copy it into the user buffer if it is capable of holding the entire record. Such a function would reduce RAM usage and data copies in many operations (like the above example) on log records containing variable sized objects. I make a distinction here between a record containing a variably sized object and a record containing a variable number of fixed-sized objects, like uint16_t's. In the latter case the application code knows to read in multiples of sizeof(uint16_t) so partial record reads are never an issue. #2 - Buffer overrun indication For circular logs containing valuable data, such as a sensor readings, it might be important to know when LogWrite.write() has overwritten existing records not yet extracted via LogRead.read(). One technique would be the addition of a recsLost() method, which returns the number of records overwritten since the last call to recsLost(). Thanks, Steve McKown _______________________________________________ Tinyos-help mailing list [email protected] https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
