Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:8 as permitted sender) client-ip=2620:137:e000::3:8;
Date:   Thu,  2 Nov 2023 13:33:58 +0000
In-Reply-To: <ZUKaSD4sPtHzlqfT@google.com>
Mime-Version: 1.0
References: <ZUKaSD4sPtHzlqfT@google.com>
Message-ID: <20231102133358.324909-1-aliceryhl@google.com>
Subject: Re: [PATCH RFC 00/20] Setting up Binder for the future
From:   Alice Ryhl <aliceryhl@google.com>
To:     cmllamas@google.com
Cc:     a.hindborg@samsung.com, alex.gaynor@gmail.com,
        aliceryhl@google.com, arve@android.com, benno.lossin@proton.me,
        bjorn3_gh@protonmail.com, boqun.feng@gmail.com, brauner@kernel.org,
        gary@garyguo.net, gregkh@linuxfoundation.org, jeffv@google.com,
        joel@joelfernandes.org, linux-kernel@vger.kernel.org,
        maco@android.com, mattgilbride@google.com, mmaurer@google.com,
        ojeda@kernel.org, rust-for-linux@vger.kernel.org,
        surenb@google.com, tkjos@android.com, wedsonaf@gmail.com
Content-Type: text/plain; charset="utf-8"
Precedence: bulk

Carlos Llamas <cmllamas@google.com> writes:
> On Wed, Nov 01, 2023 at 06:01:30PM +0000, Alice Ryhl wrote:
>> Although this rewrite completely rethinks how the code is structured and
>> how assumptions are enforced, we do not fundamentally change *how* the
>> driver does the things it does. A lot of careful thought has gone into
>> the existing design. The rewrite is aimed rather at improving code
>> health, structure, readability, robustness, security, maintainability
>> and extensibility. We also include more inline documentation, and
> 
> Can you expand a bit more on what the plan is here? Is it a two step
> process? e.g. replacing first and then revisiting the *how* binder does
> things later?

Yes, a big part of the motivation behind this rewrite is to make it
easier to continue evolving Binder.

For example, we would like to make Binder have more thorough epoll
support and the ability for a single-threaded server to handle many
incoming transactions at the same time, similar to how you can use many
non-blocking tcp sockets on a single thread today. This would have a
number of performance benefits, like fewer threads, less contact
switching, etc.

We would prefer to not attempt this in the C driver because of how
challenging it is to make significant changes.

Alice