[Tinyos-2.0wg] 7/26 meeting notes

[Philip Levis]

Notes are up on the wiki.

Vlado, Jan, Philip, Kevin, Prabal, Jonathan, Phil L., Gil (later),  
Martin

PL: What to do about contrib?

Prabal: What's broken with 1.x? Bit rot? But it does provide a place  
to put code.

Martin: I think that the contrib directory is good from an archival  
standpoint. Even if bits rot, it's there. Although we're focusing on  
problems... how do you convince people to maintain their contrib  
directory? It's a bit unorganized... hard to find things. Things move  
around. Having a standard policy there.

Prabal: No schema, no index, bit rot?

Vlado: Licenses? We allowed external entities to supply code with  
different licenses. But this breaks the Sourceforge user agreeement.

PL: We're breaking the rules.

Vlado: If the Alliance decides on a specific license, then this might  
become easier. We do need a better structure. By project, by user, by  
institution.

PL: Currently, the alliance says BSD. One way would be to have a  
contrib/ directory that follows this, but then have another place for  
other licenses.

Vlado: True, but why would someone want to follow the rules for  
licensing, but not have it in the core?

PL: I'd think that the difference between in the core and contrib is  
a support question.

Vlado: The beta issue is something we didn't clear. Some questions.  
Branches are becoming tricky. You can shadow individual files.  
Branching means copying directories, etc. We have a proposal: one top- 
level directory, testing/ or broken/, where we can put code in  
individual subdirectories which can then be wired using include  
files. There are several branches out there, not seeing enough testing,

PL: That sounds reasonable. Devel -> main, plus. But consensus is  
that we want a contrib directory. Top-level module, or subdirectory  
in tinyos-2.x/?

Vlado: Directory seems OK.

PL: Any other issues?

Prabal: Bit rot?

PL: Contrib is up to the developer.

Prabal: It's all under the umbrella, though. If you check out, you  
get contrib. Maybe it would be useful to have it in a different  
location. Vlado's concern about incompatibility is valid. This  
suggests that it should be a top-level module. Let's make a division  
between what's core and what's not, through the checkout policy.  
Otherwise we inherit all of the bad juju of contrib.

PL: Let's continue this over email. Bug tracking.

Vlado: I think we need a dedicated mailing list for bugs. It's much  
harder for developers to locate bug reports. Developers have first- 
round filtering.

Prabal: There's no admission control on tinyos-bugs, but there is  
admission control on Sourceforge. Developers put them on Sourceforge.

Vlado: Yes.

Prabal: Sounds like consensus.

Phil L: I'll include it in the mail. Let's talk about TEP 103 and  
101. Start with 103, Vlado can you summarize the discussion.

Vlado: David Moss commented on 103. He provided a long email with  
extended comments. From what I understood, his main concern was that  
while there are some HAA confusion, the core of the problem is that  
the current HILs did not let him implement the filesystem  
abstraction. He suggested a modification so that he could more easily  
implement his abstraction on existing chips. I think we all agree  
that the HAL should be customized to current chips, should provide  
maximum performance. The separate issue is what HILs we should  
provide, and how are they implemented. How much sharing, etc. So I  
don't think there are many problems there. The basic question is  
whether the current interfaces are not OK for Blackbook. If so, we  
need to fix that.

PL: Jonathan?

Jonathan: The initial confusion was just because David Moss mixed up  
interface versus implementations in the HAL/HIL. If we are going to  
look into satisfying David Moss's requirements, we need to consider  
NAND flashes. I think that's David Gay's question, based on his  
email. He's not sure that what David Moss is proposing is sufficient  
for NAND flash technology.

PL: A lot of other people have done storage work. I asked Rick and  
Deepak if they could sound off or have a student sound off on the  
issues. What Ramesh thinks is also important.

Vlado: Reading his next message, I am still confused.

PL: Let's continue the discussion.

Vlado: It sounds like he doesn't think the HAL/HIL decomposition is  
worth the effort. It looks like he is ready to take the performance  
hit. But that doesn't mean everyone is. Are there applications where  
you are not ready to make that compromise.

Phil: Maybe in a week we can organize a telecon to discuss. Any more  
comments on TEP 103?

Vlado: One more, to Jonathan. But there is a comment there in the  
TEP, where it is claimed that the  (section 3.2) system guaranteees  
that the user is going to use  at most one complete record from the  
log. I think it's a bit confusing. I think this should be rephrased.  
You do not guarantee that there are no half-records.

Jonathan: Metadata-data distinction. You put the record on, but you  
update the metadata separately.

Vlado: You filter things. You don't manage the actual record. I was  
confused by one sentence: Applications do not need to worry about  
incomplete log entries. Some applications read the data post-facto.  
E.g., if I just suck the data off.

Jonathan: OK, I'll talk with David Gay.

PL: Let's go on to 101. ARC, did you guys get a chance to read the  
transforming proposal?

Jonathan: It was a proposal to transform the configuration into  
something more platform-independent, right?

Vlado: Yes, as well as defining the unit, as some fraction of a volt.

Jonathan: Ah, OK. So, I haven't read the document word-for-word, but  
both of those proposals, I'm in favor of.

Vlado: So Jan has implemented it.

PL: What do you think, Gil?

Gil: This is feeling about right to me. Just the other option would  
be to call configure without a parameter.

Vlado: I think the advantage is that we get a compile-time check.

PL: How?

Vlado: There's a section in the document.

Gil: Here's a separate issue. There's also this bit about voltages  
instead of ADC units. So that wasn't in the original discussion, was it?

Vlado: This came up in the discussion. If we change the configuration  
interface, so the interface should be as well.

Gil: It's just not clear to me where this happens. Tracing down the  
call path, it's not clear to me where the translation into millivolts  
occurs. It seems like the platform ADC would do this.

Jan: For the sensor driver, it is not clear whether the sensor is  
attached to an ADC, so the config has to provide the read, but it  
will not actually provide read, but it will wire a component that does.

Gil: So you're thinking a single driver might be able to work on two  
different ADCs?

Vlado: No, the idea is to support a sensor that if you have one  
sensor that produces analog output, in order to sample these in an  
ADC independent way, then the ADC needs to provide some kind of  
independent measurement, so the driver can make some kind of  
computation on it.

Gil: Why does ADCReadClienC isn't providing millivolt by itself. It  
gets routed through configC and configP.

Kevin: Comes out of the ADC, goes through the config component.  
That's because you don't know whether it's going through an ADC. It  
just wants a millivolt value, doesn't care where it comes from. So  
the way the wiring works is you wire the driver to the config, which  
then wires to the ADC. In this example, it's going directly through.

Gil: So the config component translates ADC value to millivolt, which  
then the driver translates to a value.

Jan: We are discussing. The idea is that this proposal only affects  
the ADC representation. It provides data in millivolts. How the  
sensors use this is in the sensorboards TEP, and this should be  
independent of the driver. The driver can decide whether to use the  
ADC HIL, or to wire it in some other way (e.g., I2C), maybe post- 
process.

Gil: The back into millivolts seems kinds of backwards.

Phil: But what about draining batteries.

Vlado: But you can correct it, if you know the reference voltage. I  
don't see what the problem of the reference voltage. then there is no  
problem. The curves are always based on volts, or parts of volts.

Gil: I don't think there is an issue.

PL: How about your questions about the proposal?

Gil: I still don't see how the ReadClientC works with regards to the  
Config.

Vlado: Your concern is in the wiring of the driver. Your question is  
why is this from Config, rather than the HIL directly.

Gil: I also don't see ConfigP, which is what bridges ConfigC to the HIL.

Vlado: OK, I need to update the doc.

PL: Do we want to retract the TEP from review? Or should be just fold  
in comments?

Vlado: Let's wait for comments on existing document. Let's see if  
those are addressed, relevant, and then try to unify everything into  
a new version of the TEP. I think it's too late to retract. The  
comments that come back will be good.

PL: I'll send out email, Vlado will update the proposal.

Phil