[Tinyos-2.0wg] August 23 notes

Thu Aug 24 10:46:17 PDT 2006

Also up on the wiki.

------------------------
= TinyOS 2.x WG/08.23.2006 Meeting Notes =
------------------------

= Agenda =
------------
* TEPs 101, 102 (in external review)
* TEP 105 (being drafted by David Culler)
* TEPs 123, 124 (being drafted by net2 WG)
* TEP 103 (discussion of external review)
* TEP 107 (moving to external review)

= Participants =
----------------
* Phil Levis, Stanford
* David Gay, Intel
* Jan Hauer, TU Berlin
* Prabal Dutta, UC Berkeley
* Phil Buonadonna, Gilman Tolle, Arch Rock

= Action Items =
-----------------
* Jonathan will respond to 103 external review feedback
* David and Jonathan will discuss next steps for 103 with Ramesh
* Everyone reads 108 for discussion next week
* Phil will check on status of 101 external review
* Phil will send out to do list for 2.0 release
* Gil will update 109 and 116 to reflect left-justification  
requirement changes

= Next Meeting Agenda =
------------------------
* TEP 108

= Discussion Notes =
--------------------

== TEP101 (ADC) ==

Phil will ping for current status (was due 8/10)

== TEP102 (Timers) ==

Philippe Bonnet just started process (expected mid September)

== TEP105 (CSMA Radios) ==

PB: no report from David C.

== TEPs 123, 124 (net2) ==

TEP123:
MintRoute-like (independent route update)
Skeleton checked in

TEP124:
DSDV (Drain) like, route updates controlled by root
Can ensure no loops
No skeleton yet (Rodrigo, Om responsible)

== TEP103 ==

David: Discussion about the HIL level (David Moss arguing for chip- 
independent
HIL interface to chips.) You can always build higher layers on top.  
Thoughts
to move block storage more toward this. Jonathan thinks it might be a  
good
idea. I am not convinced.

Phil L.: You mean a chip-independent implementation?

David: A general read/write which then Block and Log and other higher
level things on top. Questions from Neil Hancock about error handling
and expected use cases. Ramesh himself had a few comments, which I
responded to. Jonathan still needs to respond. Ramesh, Jonathan
and I need to figure out what needs to change.

David: Some further feedback yesterday. I responded today. There were
some requests for some changes, I explained how one could be easily
implemented. In the circular log you can overwrite all records: user
wanted to know the number of records last since last asked. My response
is that there's a way to know that your read position has been  
overwritten.
I'm not sure exactly how you store this information across reboots  
without
central metadata, and it doesn't seem useful enough. Proposal has
some issues, and you can mostly do it already.

David: The second and more elaborate one is the notion of atomicity.
You have the guarantee that it's either read completely or not at all.
This gives the perspective of records, but you don't know where
the record ends, e.g., where is record N. The purpose isn't to have
record-based systems, rather to be able to support both record-based
and byte-based approaches without forcing the overhead.

Phil B.: One thing with the record/log-based storage that we found,
it seemed like every write you did to the log was implicitly a record,
but the records could be non-uniform size. So, 4 bytes, then 12 bytes.

David: There's an assurance that they're atomic, but they are not
necessarily records. That's just how Jonathan implemented it.

Phil B.: OK, so is it then up to the application to keep track of
its record map, to keep track of its store, somewhere, completely?

David: Yes.

Phil B.: This starts to get weird with Circular Logs, as you need
to erase the first block. This raises the question of where the first
full record starts.

David: It's up to the circular log to ensure that you read at
an atomic boundary.

Phil B: So it IS up to the circular log to provide a storage map?

David: Not completely. You only need to know the write boundaries.
So the first atomic write of each erase unit.

Phil B. What's the purpose of a seek? The whole abstraction is this
byte seek thing? On one hand, you have records, on the other, you
have to be able to seek arbitrarily.

David: All you need to do for this is maintain the offset of the
first record of an erase block.

Phil B.: I think this is a mistake. It should either be in terms
of records, or bytes, not this weird hybrid.

David: There's no seek to an arbitrary offset. You can only seek
to a result of current offset, which can only be obtained by getOffset,
which is on a record boundary. Opaque cookies, not arbitrary offsets.

Phil B.: I think there are some complexities here, and it's a bit of an
issue implementation-wise in imote2. It was frustrating.

David: I think we could simplify things, and that would make it
easier. The goal here was to make it more general, but not SO general
that it was unimplementable.

Phil L.: OK, so it sounds like Phil B. is  saying that it was
implementable, but it was such a pain that it wasn't worth it.

Phil B.: That's right. It just seems weird, you can read across
record boundaries, but you can't seek across them.

David: It's a byte stream with atomic writes. You don't see the
result of a partial write.

Prabal: Is part of the confusion here between the use of both byte
streams and records?

David: If the TEP says records, it shouldn't.

Phil B.: I just think the complexity isn't worth it.

Prabal: If you just used a straight circular log, would that make it  
easier?

Phil B: Yes, it would. I would just move the read seek pointer on an
erase.

David: Yes, but it becomes very hard to reread this log unless you know
where you are, as you do not know the offfset.

Prabal: You're sort of putting ADUs into the abstraction.  If you're  
reading
at write boundaries, and you just handle the wraparound, why is this a
big deal?

David: One solution is to never have records cross block boundaries.

Prabal: Why can't Phil B. just use it as a byte stream?

Phil L.: Because the front of the stream disappears.

Prabal: Why doesn't the current interface deal with Phil's issue? Let's
take this online.

Phil L: Are you OK taking this offline, Phil?

Phil B.: I seem to recall an edge case when writes never cross erase
boundaries. If you're reading from the last write in an erase block.

David: I don't think that we can go into this now. But I will say
that having full atomicity and reliability is hard. I think the  
discussion
here is whether the log is fully atomic and reliable.

Phil L: We should continue this discussion.

David: How about Phil B. and Jonathan describe what the challenges were,
and propose an alternative abstraction?

Phil B.: I'm torn. We've done it. We came up with a way to meet this  
interface.
I want TinyOS 2 to move forward. But if we had a 32MB chip, the  
approach we
used would be difficult. I think the best thing is that we stick with  
what we have,
and move forward.

Phil L.: So TEP 103 stays, but maybe in the future there will be another
TEP describing an alternative log-oriented storage abstraction. Sort  
of like
file streams versus the STL.

== TEP107 (Boot sequence) ==
(revised based on comments a few months back)

DG: Who made comments?

PL: Prabal, Ben Greenstein, maybe David C.

DG: Last discussion 5/24. Not 100% clear from notes.

PL: Proposal: put it for external review, internal group
members can comment via regular review process.

WG agrees to send to steering committee.

= Misc =
--------
*