On Tue, Jul 31, 2018 at 10:44:33AM +0200, Martijn Coenen wrote: > 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. Ah, this wasn't brought up in the original thread when discussing to turn this into a module. If using internal functions like this is going away it makes sense to wait for this work to happen first. Is there a time-frame for this? Thanks! Christian > > > > > 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
