On Jan 26, 5:05 am, Tim Bird <tim.b...@am.sony.com> wrote: > On 01/25/2012 05:41 AM, rong wrote: > > > Hi Folks, > > > I've just finished a fresh implementation of the android binder > > driver, would love to see some suggestions or comments on the code as > > well as the whole binder IPC idea. > > This is really interesting. I hope this doesn't seem rude, but > why are you doing it? Is it just an interesting exercise, or are > you trying to develop something to replace the current driver? > Or, are you trying to develop something in the hopes that it > will have a better chance of being accepted into the mainline kernel?
It was just for fun, I guess that's the beauty of open source - people can always come up with different solutions when they see how others have done it. I've seen a lot of discussions on whether or how the android related driver should be accepted into the mainline kernel, so I have no intention in doing that. In my opinion, the binder driver contains too much domain specific details to become part of the generic kernel, on the other hand, if more people understand it well and use it in their day to day projects, it'll eventually become part of a generic system. Until then, I'm just doing it for the fun of coding, all I wish soon I can replace the binder driver on my phone and hopefully get a better interaction with it. > The main issue you seem to be addressing is performance scalability > on SMP. Is that right? Yes and no. The existing driver has poor SMP scalability for sure. But even on UP systems, that kind of global locking hasn't been a common practice since long ago, remember UP systems can also have preemption and so on. But don't get me wrong, the whole binder driver and supporting framework is quite sophisticated. Android people have done a great job to put everything together and get it used on a phone that has become so popular. Considering SMP is now the defacto standard on desktop PCs and more and more phones, removing the global locking to get a better system response is the way to go. Also I've seen some interfacing issues with running the existing driver and framework on 64-bit systems, so there's also something there to be sorted out. > > I'm involved with a project to try to get Android technologies > integrated into the mainline Linux kernel source tree. > Seehttp://elinux.org/Android_Mainlining_Project > > If your project gains traction, it would be useful, IMHO, > to discuss this as part of that effort. Also, you may wish > to follow the link on that page to see what issues mainline > kernel developers have with the current binder driver, to > see if they might also apply to your driver. Great. It'd be useful to have more and more Android specific code to be accepted into the kernel. Again when you think Android being a fully commercialized system, and Linux a purely open sourced generic OS, there will always be things can't be settled well especially in short period of time. I guess it's a more open ended question for people who are really evolved to think which way it should go. Having said that, I'm more than happy to provide whatever support I have to contribute to your project if ever needed. > Regards, > -- Tim > > ============================= > Tim Bird > Architecture Group Chair, CE Workgroup of the Linux Foundation > Senior Staff Engineer, Sony Network Entertainment > ============================= Cheers, Rong -- unsubscribe: android-kernel+unsubscr...@googlegroups.com website: http://groups.google.com/group/android-kernel
