On Mon, Feb 14, 2022 at 11:19:35PM -0800, Suren Baghdasaryan wrote:
On Mon, Feb 14, 2022 at 11:01 PM Greg Kroah-Hartman gregkh@linuxfoundation.org wrote:
On Mon, Feb 14, 2022 at 02:25:47PM -0800, T.J. Mercier wrote:
On Fri, Feb 11, 2022 at 11:19 PM Greg Kroah-Hartman
--- a/include/uapi/linux/android/binder.h +++ b/include/uapi/linux/android/binder.h @@ -137,6 +137,7 @@ struct binder_buffer_object {
enum { BINDER_BUFFER_FLAG_HAS_PARENT = 0x01,
BINDER_BUFFER_FLAG_SENDER_NO_NEED = 0x02,};
/* struct binder_fd_array_object - object describing an array of fds in a buffer
2.35.1.265.g69c8d7142f-goog
How does userspace know that binder supports this new flag?
Sorry, I don't completely follow even after Todd's comment. Doesn't the presence of BINDER_BUFFER_FLAG_SENDER_NO_NEED in the header do this?
There is no "header" when running a new kernel on an old userspace, right? How about the other way around, old kernel, new userspace?
- new kernel + old userspace = kernel supports the feature but
userspace does not use it. The old userspace won't even mount the new cgroup controller, accounting is not performed, charge is not transferred. 2. old kernel + new userspace = the new cgroup controller is not supported by the kernel, accounting is not performed, charge is not transferred. 3. old kernel + old userspace = same as #2 4. new kernel + new userspace = cgroup is mounted, feature is supported and used. Does that work or do we need a separate indication of whether binder driver supports the charge transfer feature?
Ok, if that's all working, this is fine, it just seemed odd to add a new type like this. Perhaps this can go into the changelog text...
thanks,
greg k-h