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@lists.linaro.org https://lists.linaro.org/mailman/listinfo/greybus-dev