From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from wolverine02.qualcomm.com ([199.106.114.251]:61775 "EHLO wolverine02.qualcomm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754497Ab0GBASr (ORCPT ); Thu, 1 Jul 2010 20:18:47 -0400 Message-ID: <4C2D3066.9040104@codeaurora.org> Date: Thu, 01 Jul 2010 17:18:46 -0700 From: Saravana Kannan MIME-Version: 1.0 Subject: Re: Closed source userspace graphics drivers with an open source kernel component References: <1278024678.7738.54.camel@c-dwalke-linux.qualcomm.com> <1278026975.7738.89.camel@c-dwalke-linux.qualcomm.com> <1278029284.7738.116.camel@c-dwalke-linux.qualcomm.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-arm-msm-owner@vger.kernel.org List-ID: To: Dave Airlie Cc: Daniel Walker , LKML , dri-devel , linux-arm-msm@vger.kernel.org, jcrouse@codeaurora.org Dave Airlie wrote: > This is more about initial development stages. We maintain kernel > API/ABI for all in-tree drivers, however before we put a driver into > mainline, we usually need to redo the crazy interfaces that vendors > have come up with. Like 32/64 alignment, passing userspace addresses > into the kernel, passing phy addresses to userspace etc. If the > userspace binary is closed that process becomes next to impossible. My 2 cents: I think we should leave the onus of fixing the userspace to work with the sane kernel API with the entity trying to get their drivers into the kernel. I think it's a better approach (as in, more likelihood of getting device support) than saying, we will only allow fully open sourced kernel drivers. -Saravana