summaryrefslogtreecommitdiff
path: root/vulkan/libvulkan/api.cpp
diff options
context:
space:
mode:
author Steven Moreland <smoreland@google.com> 2020-12-18 02:27:20 +0000
committer Steven Moreland <smoreland@google.com> 2020-12-21 21:33:25 +0000
commite839388aaf2aaf82d6a8a84aa4ffb673dc62287d (patch)
tree5c5595d0cac7d2aaa585647a22703d23d295e265 /vulkan/libvulkan/api.cpp
parentd95f8b185ebc82f5a98d1697ef23a4308fdfc2a2 (diff)
BpBinder: hide 'handle' API
The 'handle' API represents an internal 'address' for use with the kernel, and it shouldn't be exported from libbinder (currenlty it is used in Parcel). If any clients are using this API (they really shouldn't be), then this CL should expose them. This way, when/if binder supports communications over sockets, the format of this data can be changed without having to worry about changing this API (we're worrying about changing that API now). Possible solutions here: 1. Parcel should not read/write binder objects. Instead, these objects should implement Parcelable. This certainly sounds like an elegant solution. However, because of the way that flattenBinder/unflattenBinder interact with Parcel internal details ('objects') rather than being composed of other Parcel primitives, having Parcel expose 'handle' is probably the lesser of the two evils (not to mention, the sizeof(IBinder) and its virtual address table is frozen). 2. Use 'friend' (and this is the route this CL goes). However, in order to avoid exposing unnecessary internal details of BpBinder, this CL creates a header-only access function which limits the ability of Parcel to inspect BpBinder, and it makes the contract/relationship explicit. Assuming this CL lands, I want to change other uses of 'friend' here to use a similar accessor pattern. Bug: 167966510 Test: boot, aidl_lazy_test Change-Id: I5b21d15989f7ce7c45e44b33ed3bde45a63347a5
Diffstat (limited to 'vulkan/libvulkan/api.cpp')
0 files changed, 0 insertions, 0 deletions