On 10/31/2016 08:50 AM, Alex Elder wrote:
> The Greybus kernel code, developed as part of Google's Project Ara,
> is in the upstream Linux kernel tree (under drivers/staging). The
> cancellation of that project makes the future for Greybus a bit less
> certain. There is interest among the core developers of Greybus
> (and others) to do what we can to preserve the value of the Greybus
> implementation for use beyond its original target platform. For
> that to have any chance of success, we need to establish some
> organization, and basically form a community of developers and
> interested parties.
At long last I can tell you I've arranged to get a mailing list
and IRC channel set up for Greybus development.
The e-mail address is:
greybus-dev(a)lists.linaro.org
This list is intended to handle all development discussion for
Greybus and related topics (like gbsim and manifesto), and this
includes patch traffic.
Please add yourself to the mailing list here:
https://lists.linaro.org/mailman/listinfo/greybus-dev
Archives of traffic on the list will be maintained here:
https://lists.linaro.org/pipermail/greybus-dev
The IRC channel is on Freenode, named #greybus. I believe it too
is logged (and if it is not now, we'll arrange for it to be).
We will continue to use the git repositories on Github:
https://github.com/projectara
There is no Wiki or other web page, nor other resources like
bug tracking or a patchwork instance. In time we may add these.
For anyone previously associated with Project Ara, please note
that the old e-mail lists and IRC channel will be shut down at
some future date (perhaps at the end of this year).
Any questions, please contact me. Thanks.
-Alex
> I'm proposing below a few things, which I'll implement this week
> unless I hear people express strong opposition (or clearly better
> suggestions). If you have comments, please say something.
>
> Git repositories. Public git repositories related to Project Ara
> are all hosted here:
> https://github.com/projectara
> At this time I see no reason to move away from this, but it would
> not surprise me if we decided to host the code and documentation
> somewhere else at some future date.
>
> Mailing List. Because the Greybus kernel code sits in the staging
> tree, mail about it should go to the driver-devel mailing list
> (devel(a)driverdev.osuosl.org). I know that some people prefer better
> mail filters rather than more mailing lists, but I think Greybus
> discussion warrants a separate list. Its code spans multiple code
> bases, and I think we're going to need some dedicated and ongoing
> strategy and design discussions. So I'd like to create a Greybus
> mailing list as a home for all Greybus-related discussion, including
> patch traffic. My suggestion is to create a majordomo list:
> greybus(a)kernel.org
>
> Patchwork. In the past I have found Patchwork to be a very useful
> tool in managing incoming patches. I'd like to set up a patchwork
> instance for Greybus, monitoring the greybus mailing list, again
> at kernel.org.
>
> Wiki page. If we want a Wiki page, we could set one up at
> kernel.org. Thoughts?
>
> Web home page. I have secured the "greybus.org" domain, so if there
> is any value in populating that page it could serve as the home page
> for the project. It currently has no content.
>
> Are there any other important resources I've missed? Once we get
> a list going (or not) I've got a few other things to talk about.
>
> Thanks.
>
> -Alex
>
> PS I have addressed this message to a set of interested people
> whose e-mail addresses I knew; the set is definitely incomplete.
> This will form the initial membership of the mailing list. If
> you do not want to be on that list, or if you know others I
> should include, please send me contact information by private
> message.
>
McCOY: You've got him, Jim! You've got him where you want him.
This patchset adds async operations to greybus-core. Rather than have
different drivers do variations on the same theme of launching and timing
out asynchronous operations, it makes sense instead to provide this
functionality via greybus-core.
This patchset makes it possible to launch asynchronous operations and have
the completion callback for an operation indicate -ETIMEDOUT for timeouts
without drivers having to manage that locally. This set doesn't convert the
existing synchronous operations away from
wait_for_completion_interruptible_timeout() since that would involve adding
an extra work-queue item to each synchronous call, with no added benefit
for synchronous operations. Synchronous operations can already detect
-ETIMEDOUT by blocking on the synchronous send operations, asynchronous
operations and the driver associated with those operations OTOH must
implement a completion handler. The main improvement this patchset makes is
to pass the -ETIMEDOUT completion status into that completion handler -
hiding the setup/timeout of operations away from a driver-level and into a
core-level set of logic.
Loopback as an example can have lots and lots of redundant code removed and
given we previously had some in-flight effort to add asynchronous
operations to SDIO it makes sense to move the generic types of things we
need to do on the asynchronous path into greybus-core so that SDIO and
other bundle drivers can reuse instead of reimplement asynchronous
operations.
Note: we had approximately three internal versions of this on Project-Ara.
Here's the log for completeness.
V3-V4:
Fix bug in loopback conversion - Mitch Tasman
V2-V3:
remotes/ara-main/sandbox/bodonoghue/ara-main-current+async_op3
Drop patch #6 converting sync operations to new t/o structure. Johan had a
concern about doing an in-depth analysis on that change and considering our
compressed timelines now, this analysis won't happen. OTOH the new async
API is the right thing for loopback and for potential later greybus
users/implementers to reuse.
Although it wasn't part of the motive for this change - I observe slightly
better performance than baseline with loopback tests with this change in
place - which shouldn't be surprising since we have less aggregate context
switching for operation timeouts.
V1-V2:
Rename async_private => private - Greg
gb_operation_request_send_async_timeout ->
gb_operation_request_send_async() - Greg
Using existing gb_operation_completion_wq - Viresh
Split out gb_operation_cancel() - timeout need not wait synchronously on
cancellation queue - Bryan
Move timeout to work-queue - Greg/Viresh
cancel timeout workqueue @ operation completion point - Viresh/Bryan
Bryan O'Donoghue (6):
staging: greybus/operation: add delayed worker for async timeouts
staging: greybus/operation: add generic asynchronous operation support
staging: greybus/operation: add async_private data with get/set
accessors
staging: greybus/loopback: convert loopback to use generic async
operations
staging: greybus/loopback: convert to use msecs internally
staging: greybus/loopback: Hold gb->mutex across loopback operations
drivers/staging/greybus/loopback.c | 190 ++++++++----------------------------
drivers/staging/greybus/operation.c | 65 ++++++++++++
drivers/staging/greybus/operation.h | 18 ++++
3 files changed, 126 insertions(+), 147 deletions(-)
--
2.7.4
Hi there. This is Eddie, your shipboard computer, and I'm feeling just
great, guys, and I know I'm just going to get a bundle of kicks out of
any program you care to run through me.