I think we're on the same page here but there are some details to work out.
Anything in "tos" could be assigned an AM ID range by the net2 WG. The question is how do things move from "contrib", "apps", etc. to "tos"? An example might be a new timesync protocol that someone develops and wants to be part of the official release (by which I mean, in "tos"). There needs to be a clear way for someone to (a) get their code in there and (b) get the AM IDs assigned for it. Being a member of the net2 WG is one way to do that, but I would hope there are other avenues that permit inclusion of third-party protocols as part of the standard tree. The flip side is what happens if a lot of protocols end up being "blessed" in this way and we start to run out of AM IDs in the 128-255 range. My suggestion was to consider an AM ID assignment as a revokable lease, rather than a permanent guarantee. That way the net2 WG can reclaim unused/stale AM IDs if needed. On Apr 30, 2008, at 12:11 PM, Philip Levis wrote: > > On Apr 30, 2008, at 6:02 AM, Matt Welsh wrote: >> That makes a lot more sense to me than just "protocols developed by >> net2". As Om said you only need about 15-20 IDs, but you're >> proposing to claim 128. Seems like a mismatch. >> >> Here's a proposal. As TinyOS matures it's clear that we need some >> way to resolve AM ID space conflicts. One approach is for net2 (or >> some appropriate working group) to maintain the AM ID registry for >> all *standard* protocols included in the TinyOS core tree (apart >> from contrib). > > What is a standard protocol? I mean, if it's in the tree, it needs > to be able to work with the other protocols in the tree. Note that > protocols defined in apps/ would fall into the range 0-127. > > >> When a protocol is pushed into the main tree, it is assigned AM >> ID(s) by the net2 WG and these are published somewhere (doc wiki >> seems like a good idea). Those IDs would be assigned in the range >> 128-255. The range 0-127 is marked as "unassigned" and applications >> are free to use anything in that range (at their own peril). >> >> The main challenge with this approach is determining what >> constitutes an "official" protocol that warrants an ID in the >> reserved space. Over time I would expect accretion of "dead" >> protocols that are claiming AM IDs. One policy would be for the AM >> ID to have a renewal period of, say, 2 years. This problem would >> largely go away if we could move to 16-bit AM IDs. > > I think the criterion is "in the tinyos-2.x tree." More precisely, a > protocol has an ID in the range 128-255 iff it is in tinyos-2.x/tos/. > > Phil _______________________________________________ Tinyos-help mailing list [email protected] https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
