search

rdmenezes / remote-testbed

Automatically exported from code.google.com/p/remote-testbed
0 stars 1 forks source link

Generalize MCI's mote attributes handling #17

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
This is a proposal for changing the design of how mote attributes are
handled. The goal is to make the MCI general enough that it can support
different site infrastructures more easily.

There is clearly a need for mote attribute not only to flow from MCH to
MCS, but also for attributes to be fed back from MCS to MCH. This suggests
that the protocol between MCH and MCS should support a more generic method
for exchanging mote attributes. This method should allow decisions about
which mote attributes are relevant for a specific operations to be made as
close to where the operation takes place as possible.

One use case is information about the TOS address that some flash
programmers can use to assign a testbed wide address to modes. This implies
that it this mote attribute might not be needed by all testbeds.
Furthermore, where it is needed, it should be managed (as in assigned to
motes) at a central place such as in the database, which means that the MCS
 is responsible for sending this information to the MCH when motes needs to
be programmed. The MCH can then provide this information to the flash
programmer either via the process environment or as program arguments.

Another use case is mote attributes that the MCH can get via UDEV or by
running an external probing program. By routing this information to MCS, a
greater deal of auto-configuration can be achieved. A possible mote
attribute candidate is the mote platform.

Since it is hard to guess which attributes will be needed in the future a
generalized method of exchanging mote attribute back and forth between the
MCS and MCH will allow new attributes to be added/tested without having to
change the protocol and can potentially also reduce the need for upgrading
running servers. For example, the MCS could be setup for automatically
entering seen attributes into the database.

Possible candidates:

 - MCH side: device path, and mote platform.

 - MCS side: TOS address

Note, the mote MAC address is somewhat an attribute, but is special because
it is used for identifying motes and therefore must always be present.

Original issue reported on code.google.com by jonas.fonseca on 6 Nov 2007 at 3:29

GoogleCodeExporter commented 9 years ago

Original comment by jonas.fonseca on 12 Nov 2007 at 10:41

GoogleCodeExporter commented 9 years ago 
The simplest and most powerful way to fix this is to make it possible for UDEV
scripts to define attributes via the device hierarchy by placing them in a named
directory such as:

   /dev/remote/MOTEMAC/attr/

and make the MCH unconditionally send all such attributes to the MCS. The other 
way
the simplest solution is to make mote attributes available to mote programming
scripts via environment variables by allowing the MCS to define key=value pairs 
that
will be passed to exeve() when programming.

Original comment by jonas.fonseca on 19 Nov 2007 at 10:44

GoogleCodeExporter commented 9 years ago 
Here is a patch that shows how the mote programming will become more generic, 
remains
is to make the mote programmer path configurable via UDEV (issue 21), protocol
changes to send the mote attribute environment variables, and finally the 
sending of
MCH attributes.

Original comment by jonas.fonseca on 19 Nov 2007 at 1:15

Attachments:

GoogleCodeExporter commented 9 years ago 
Retargeting this to next release since it needs more thought. For the upcoming
release we can just add the necessary changes to the MCH-MCS protocol by adding 
the
platform attribute to MsgMoteConnectionInfo, etc.

The above patch + related cleanups has been merged, however, as a preparation 
and
nice cleanup.

Original comment by jonas.fonseca on 22 Nov 2007 at 12:19