[Tinyos-2.0wg] August 23 notes

[Kevin Klues]

I am in the process of updating TEP 108 and will ahve it out by the end of
the day.  Hopefully that will give you all time to look at it so we can
discuss it in tomorrows meeting.

Kevin

On 8/24/06, Philip Levis <pal at cs.stanford.edu> wrote:
>
> 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 =
> --------
> *
>
> _______________________________________________
> Tinyos-2.0wg mailing list
> Tinyos-2.0wg at Mail.Millennium.Berkeley.EDU
> https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-2.0wg
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.millennium.berkeley.edu/pipermail/tinyos-2.0wg/attachments/20060829/21055d75/attachment.htm