[emstar-design] how to describe emstar better?

Karen Weeks karenyc at lecs.cs.ucla.edu
Tue Sep 6 16:34:06 PDT 2005


Hi Lew,
I really like this description - a good, concise, useful description of 
what EmStar is and does is something I had been struggling with for some 
time.  This description is good - it gives a useful picture of the key 
elements of EmStar and how they fit together (in my opinion anyway). 
Should be valuable for EmStar newbies, and for explaining what we do to 
people who haven't heard of EmStar before.

Karen

On Tue, 6 Sep 2005, Lewis Girod wrote:

> i've been having an off-line discussion with vlad about "what is
> emstar", and he had some very useful input which we should try to
> incorporate into documentation, tutorials, etc.  we have various
> slides that say what it does -- "libraries, services, tools" -- but
> what has been lacking is a description of how it works as a system.
> this is important information for someone who wants to understand it
> and understand how to use it.  after a long discussion with me over
> email, vlad's new understanding is this:
>
>> Thanks to your e-mails, here is a picture that I currently have in my mind:
>> Layer 0: FUSD KM or FUSDNet used for low level IPC
>> Layer 1: GLIB is used to handle events on IPC channels (QT or others could be
>> used here as well)
>> Layer 2: Device interaction patterns/libraries - this is the heart of EmStar.
>> Basically, it is an IPC mechanism that supports for a variety of synchronous
>> and asynchronous interactions with clearly defined semantics and concurrency
>> model.
>> Layer 3.1: Ready to use modules/services (logring/timesync/neighbord...) -
>> could be useful, but need not be a part of the system.
>> Layer 3.2: Extra tools: EmRun/EmLog/EmSim... etc... - these things just make
>> live easier since they are already implemented.
>>
>> Each layer relies only on the underlying interface, i.e. implementations can
>> be swaped in and out.
>>
>> IMHO, presenting EmStar this way and emphasising modularity (a.k.a.
>> mix-and-match capability) would help a lot of people.
>>
>> It would also be nice to present examples for all layers of EmStar. I am sure
>> that they already exist, it is just the matter of presenting them in parallel
>> with layers:
>> drums for FUSD, something for GLIB+FUSD, query/status device
>> examples for layer 3, etc...
>>
>> However, this could be just that PINGd as the first example does not hit the
>> spot for me personally. PingD is a good integration test, but it is not very
>> educational about the internals of the system.
>
> i think his description is very succinct and the layering is quite
> helpful.  i think that we have a lot of material that could be applied
> to this, although it is not organized in that way.. for example, we
> have a number of examples and sample code that fit the various layers
> but they are not in any particular order.
>
> perhaps we can do some kind of cut on this for SECON?
>
> _______________________________________________
> emstar-design mailing list
> emstar-design at cens.ucla.edu
> http://www.cens.ucla.edu/mailman/listinfo/emstar-design
>


More information about the emstar-design mailing list