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: <ZqPd7i22_oyPB2UN@phenom.ffwll.local>
Date: Fri, 26 Jul 2024 19:33:34 +0200
From: Daniel Vetter <daniel.vetter@...ll.ch>
To: James Bottomley <James.Bottomley@...senpartnership.com>
Cc: Laurent Pinchart <laurent.pinchart@...asonboard.com>,
	Jiri Kosina <jikos@...nel.org>,
	Dan Williams <dan.j.williams@...el.com>, ksummit@...ts.linux.dev,
	linux-cxl@...r.kernel.org, linux-rdma@...r.kernel.org,
	netdev@...r.kernel.org, jgg@...dia.com
Subject: Re: [MAINTAINERS SUMMIT] Device Passthrough Considered Harmful?

On Wed, Jul 24, 2024 at 04:37:21PM -0400, James Bottomley wrote:
> On Wed, 2024-07-24 at 23:00 +0300, Laurent Pinchart wrote:
> [...]
> > What I get from the discussions I've followed or partcipated in over
> > the years is that the main worry of free software communities is
> > being forced to use closed-source userspace components, whether that
> > would be to make the device usable at all, or to achieve decent level
> > of performance or full feature set. We've been through years of
> > mostly closed-source GPU support, of printer "windrivers", and quite
> > a few other horrors. The good news is that we've so far overcome lots
> > (most) of those challenges. Reverse engineering projects paid off,
> > and so did working hand-in-hand with industry actors in multiple ways
> > (both openly and behind the scenes). One could then legitimately ask
> > why we're still scared.
> 
> I don't think I am.  We're mostly fully capable of expounding at length
> on the business rationale for being open if the thing they're hiding
> isn't much of a differentiator anyway (or they're simply hiding it to
> try to retain some illusion of control), so we shouldn't have any fear
> of being able to make our case in language business people understand.
> 
> I also think this fear is partly a mindset problem on our part.  We
> came out of the real fight for openness and we do embrace things like a
> licence that forces open code (GPL) and symbols that discourage
> proprietary drivers (EXPORT_SYMBOL_GPL), so we've somewhat drunk the
> FSF coolaid that if we don't stand over manufacturers every second and
> force them they'll slide back to their old proprietary ways.  However,
> if you look at the entirely permissive ecosystem that grew up after we
> did (openstack, docker, kubernetes, etc.) they don't have any such fear
> and yet they still have large amounts of uncompelled openness and give
> back.

This matches my experience. Legal and technical roadblocks help a bit in
the margins, but they don't matter. The open gpu stack is 90% MIT, and
nvidia and all the others have demonstrated for years how easy it is to
ignore the GPL'ed part.

What gets vendors involved is a successful project that drives revenue,
where they have a clear need for a seat at the table to make sure the good
times for them continue. Clear rules what it takes to get that seat is in
my experience really the driving force for private discussions with
vendors, and from that pov the most important thing I've ever done for the
open gpu stack is this little documentation section:

https://dri.freedesktop.org/docs/drm/gpu/drm-uapi.html#open-source-userspace-requirements

Unlike laws you can legalese around and code you can trick with hacks for
an endless game of whack-a-mole the above doc was the real stick. And it
absolutely needed the carrot of the successful project that financially
matters to work.

Cheers, Sima
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ