On Mon, Jul 30, 2018 at 10:36 PM, Matthew Wilcox <willy@xxxxxxxxxxxxx> wrote: > I'm not entirely sure I understand the binder code (... does anyone?) > but from what I can see, it intends to open a file descriptor in the > process which is the target of the message being sent. You're right. > That strikes > me as wrong-headed; it should be allocating a struct file and passing > that file to the other process. When that process receives the message, > *it* allocates a file descriptor for itself.ho We're looking into cleaning this up (historically it was done this way because VIVT caches made this not very efficient), and this is indeed a very good candidate for fixing it. > > But I think the binder user-space API relies on this. The userspace API > seems to rely on passing fd numbers around ... but I'm having trouble > figuring most of this user API out. Perhaps Martijn can help here. The UAPI does expect a file descriptor, but we may be able to do the mapping from fd to struct file (and vice-versa) in the kernel driver, so userspace wouldn't notice. Thanks, Martijn
