linux-kernel - Re: Closed source userspace graphics drivers with an open source kernel component

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <AANLkTilEKPmHKNDNbNpmUvcYC338YezLkNBc4ShfTFdp@mail.gmail.com>
Date:	Fri, 2 Jul 2010 10:13:11 +1000
From:	Dave Airlie <airlied@...il.com>
To:	Daniel Walker <dwalker@...eaurora.org>
Cc:	LKML <linux-kernel@...r.kernel.org>,
	dri-devel <dri-devel@...ts.freedesktop.org>,
	linux-arm-msm@...r.kernel.org, jcrouse@...eaurora.org
Subject: Re: Closed source userspace graphics drivers with an open source 
	kernel component

On Fri, Jul 2, 2010 at 10:08 AM, Daniel Walker <dwalker@...eaurora.org> wrote:
> On Fri, 2010-07-02 at 09:37 +1000, Dave Airlie wrote:
>
>> > Oh, man .. It seems like any driver model that straddles userspace and
>> > kernel space is kind of asking for trouble (my opinion anyway)..
>> >
>> > Would you accept a userspace component that supported some subset of the
>> > features ? You would have a kernel space driver, and userspace both open
>> > source and GPL'd , but the userspace component wouldn't support ever
>> > feature available .. Then the company would be free to make another
>> > proprietary userspace with more features based off the open source one.
>> >
>>
>> That starts to get a bit more towards useful, except you still run
>> into the problem of what happens if community developers start adding
>> features to the open driver, that conflict with  features in the
>> closed code. We'd also have to be very careful about what interfaces
>> the kernel exposed had corresponding code in userspace. i.e. adding
>> "special" ioctls for the closed bits would be a disaster, all such
>> ioctls would need open users for verification and testing.
>
> Ok .. The open userspace would just be like any other project, but
> whatever company pushed the driver would likely maintain the userspace
> component .. So the maintainer would have to handle the conflicts
> between the proprietary vs. open source sides of it.
>
> Actually , now that I think about it the biggest problem is the license
> of the userspace side.. Whatever company makes this would have to be
> able to relicense it and actually make a proprietary userspace.. So the
> userspace license would be really critical.. Either that or no one
> outside the company that pushed the driver could make code changes to
> the userspace side..

We generally use MIT for userspace bits anyways, I don't think we have
any LGPL/GPL drivers in userspace currently. So this would probably be
an okay solution to continue with.

The thing is with architectures like Gallium it would be possible to
write a complete open driver and just keep the Windows interface bits,
granted we don't have an open gallium to windows driver layer so that
would have to be worked on.

>
>> So for example, if you have a kernel KMS/DRM driver, and it set the
>> hardware up, but then you had an open 2D driver and a closed 3D
>> driver, you would have to make sure there was no functionality in the
>> kernel that only the 3D driver used as it would become impossible to
>> openly validate it.
>
> Ok. I'm not sure how crazy that would be to setup, but it doesn't seem
> like it would be that hard to just abstract the various components of
> the driver.

Its pretty much what something like gallium can do.

>
>> The other issue I see with a lot of these, is the driver are presented
>> as this is the kernel driver, these APIs are set in stone as we have
>> binary userspaces already deployed, this is even more unacceptable,
>> since we need to be able to change the interface and do proper driver
>> design before merging what looks like crap thrown together in a pile
>> and made to stick.
>
> This seems really wild to me .. Your talking about how you change the
> kernel space side and you need to be able to change the userspace side
> to match right ?
>
> Where does the userspace side of these driver live? Not in the kernel
> right?

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.

Dave.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/