On 11/29/2016 09:36 AM, Alex Elder wrote:
> OK now that we have lists and IRC in place, it's time to start
> using them. Bryan (at least) has posted some patches for review
> but if Greybus is going to provide some greater long-term usefulness
> it will need to be adapted to be more easily used in contexts outside
> Project Ara.
OK I've been out of the country (I still am) for a week and was
pretty preoccupied before I left; sorry I didn't weigh in on things
earlier.
I'm going to summarize a bit.
A summary of the summary bullets that follow:
- Defining a new target for Greybus seems cool. "IoT" is not an
adequately defined target.
- It should be reworked for other applications, but should not
abandon the existing UniPro support
- Compatibility with the Motorola Z code is desired
- Motorola used Greybus mainly for control protocols (primarily
because of excessive power consumption--which is not really a
Greybus issue, per se)
- It's going to take some effort to incorporate the Motorola code,
independent of any re-targeting of Greybus
- We should continue to keep the spec as a definitive statement
of the design.
And now more detail:
- Agreement that the SVC, control, etc. protocols are fairly specific
to the Ara hardware platform, and that will need to change
- Laurent pointed out that "IoT" is a current buzzword; we need to be
more clear about the details and requirements of our target. And
there's no point if we aren't demonstrably better than existing
solutions.
- Bryan questioned whether we were dropping UniPro support, and I
concur with Laurent that there's no reason to do that--we'd want
to just modularize things so UniPro was *one* possible transport.
- Laurent expressed concern that we should be careful to ensure
Motorola's needs can be met by whatever Greybus becomes
- Bryan asked about continued use of NuttX.
- I don't know the status of the NuttX code; Greg might.
- I personally wish we could try to make the module side be
a portable core set of code with hooks to link into an
OS (like NuttX or Zephyr). I can't comment on how suitable
the current NuttX code is for that sort of thing.
- Laurent seized on the opportunity to ding Gerrit, which I endorse.
Michael sheepishly and in vain tried to come to Gerrit's defense.
- Bryan asked about what hardware we might select for host, transport,
and modules.
- Sandeep said he still has Ara hardware, as does Viresh.
- My comment: This will be good for validation, but really we
need to also be evolving toward something else.
- Bryan offered a definition of "IoT", based on the notion of small
edge devices having Internet connectivity. He thinks Greybus
being self-describing, hot-pluggable, and transport agnostic is
what makes it interesting for such an application.
- Laurent asserted that Greybus can't be transported over the
Internet. (I don't completely understand that statement.)
- Laurent feels Greybus could be useful for use by sensors and other
tiny embedded devices--which might include IoT but which probably
goes beyond whatever IoT really represents. There are other field
buses though, and it's not clear what advantage Greybus offers.
- Jim Wylder jumped in and gave a nice overview of how Motorola actually
used Greybus.
- There has been a desire to stay connected with the upstream code,
but they simply had to diverge. (It seems there is still a wish
to preserve some sense of compatibility.)
- They added a switching layer to abstract the UniPro transport,
allowing others (I2C and SPI) to be used instead.
- Practically speaking Greybus over UniPro consumed too much power,
so they didn't use that (though it's supported).
- Greybus used for control traffic for high-speed links, as well
as for simple/low bandwidth protocols
- There remains an SVC abstraction, but it is mostly stubbed out.
Connection setup/teardown for routing are the main uses of the
SVC protocol.
- Protocol versioning needed some rework to be useful.
- Jim pointed out that there are some broader concerns that should be
addressed (security in particular).
- We ought to work on a plan for integrating the Motorola fork and
the upstream Greybus kernel code.
- Bryan pointed out that "gbsim" provides a model of system behavior
that is relatively current. He suggested that we could use that as
a tool for bringing together the Motorola and upstream code. Jim
said Motorola did not do anything with "gbsim."
- Bryan also suggested a process of cherry-picking Motorola code
into the Greybus upstream.
- We have generally been disciplined about keeping the spec up-to-date
as we developed the code. Now should be no different, and we need
to use the spec as a tool for defining and showing agreement on
design.
- Greg pointed out that the spec has Creative Commons BY-SA 4.0
license. Yip skip!
I have more to say--some actual feedback--but I'm about to board a
plane. I may get something out now but if I don't finish, I hope to
do so within a day or so.
-Alex
> There was some informal conversation about this at ELCE. I have a
> few of my own thoughts but mainly I just want to get some discussion
> started to see if we have some pieces we can agree on, and take things
> from there. Here's a short summary of what's below:
> - Retargeting Greybus for use in IoT seems reasonable
> - We will need to adjust the abstract model currently implemented for
> Greybus to match the new target
> - Certain core functionality should be useful as-is; but some other
> features will need to be re-thought and redefined.
> - We will need to evolve the Greybus kernel code to define what is
> truly "core" functionality, and what that core needs from its
> environment.
> - We will need to ensure the Greybus API is stable, and that our
> versioning design is sound.
>
> One thing that came up multiple times in October was the notion that
> Greybus could serve as the basis for communication among entities in
> an Internet of Things system. I agree with this, at least in part.
> We have set up a system with some well-defined mechanisms for
> encapsulating messages, along with a model of remote procedure calls
> that provide a pretty robust way of getting things done across a
> network. The core code implements a lot of features (like timeouts
> and message cancellation) that are very useful, and which should
> really be done in a generic way. We've got code and conventions in
> the existing protocol drivers that provide good examples of how
> to use the core functionality. I think it's reasonable to pursue
> adapting Greybus to be usable in IoT environments.
>
> In any case, one thing that occurred to me during that week and
> those discussions was that we really need to define a new *target*
> for Greybus. That is, we no longer have the Ara phone as the
> hardware target, and we need to somehow define another ultimate
> goal for the hardware or environment in which Greybus operates.
> This should be more abstract than a hardware definition; instead
> it ought to define properties of and services provided by the
> entities communicating in a Greybus system. In some ways we
> already have that (Interfaces and Modules are abstract, but
> the details of what they represent may no longer match what
> is required).
>
> I think the things that Greybus defines now that can be pretty
> universally useful are the core concepts:
> - generic Greybus host device driver interface
> - connections with fixed protocols that define how messages
> carried over them are interpreted
> - the format of messages, and the generic message header
> - the overall messaging model, including sending, receiving
> cancelling messages
> - the operations RPC model, including completion semantics
> (asynchronous completion, unidirectional operations, first
> error result prevails, and the ability to have multiple
> outstanding operations)
> From there we get into some things that are almost certainly
> useful, but there may need to be some changes:
> - The grouping of connections into bundles, which attach to
> Linux device drivers. (I think we need this, but there
> remains some work to do, especially in relation to the
> next item.)
> - Manifests to describe module/interface functionality
> - Control connection and how it's used
> And we can keep going into other things that become more and
> more likely to be unnecessary or just plain wrong when we
> are targeting something different from an Ara phone:
> - SVC and the SVC protocol
> The above is not at all exhaustive; I just wanted to try to
> identify a few specific things we can maybe start to agree
> on.
>
> Currently, the control protocol and SVC protocol are very
> much biased toward the Ara hardware. (Other protocols are
> too, like time sync and maybe firmware update.) Furthermore,
> pieces of these have necessarily made their way into core
> Greybus code. As we define a new non-Ara target, we need
> to figure out what parts really belong in the Greybus core,
> and which things need to be supplied either by external
> entities or by protocol drivers. One way to do that might
> be to implement the core code as a library, but to be honest
> I think the real work lies in teasing things apart so the
> core can be defined to supply certain well-known services,
> with hooks to allow other capabilities. For a (contrived)
> example of what I mean, we may need to provide hooks for
> setting up connection routing rather than implementing
> it in the core code. In any case, I think we need to look
> at what constitutes the true "core" of Greybus services
> and what that core needs from its environment in order to
> be used.
>
> If Greybus is going to provide a more general service we need
> to ensure it provides a stable API. We have structured things
> this way since the beginning, but I fear we may have gotten
> sloppy because we basically always packaged everything together.
> As it is, all the versioning is in place but to my knowledge
> we've never really tested it to make sure it works.
>
> I had another point which I've now forgotten... In any case,
> I really just hope to get some conversation going.
>
> What do you think?
>
> -Alex
> _______________________________________________
> greybus-dev mailing list
> greybus-dev@xxxxxxxxxxxxxxxx
> https://lists.linaro.org/mailman/listinfo/greybus-dev
>
_______________________________________________
greybus-dev mailing list
greybus-dev@xxxxxxxxxxxxxxxx
https://lists.linaro.org/mailman/listinfo/greybus-dev
|