On Fri, Jul 26, 2024 at 12:49:20PM -0400, James Bottomley wrote: > On Thu, 2024-07-25 at 22:31 +0300, Laurent Pinchart wrote: > > 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. > > > > I don't think those are necessarily relevant examples, > > Well they do show it is possible to get an open ecosystem based on the > pull of business need instead of using a forcing function like the > licence. Yes, that's true. I still think it depends on the area, the market players and the maturity of the technology, but licenses should certainly not be regarded as being the only tool we can use. > > as far as device pass-through goes. Vendors have many times reverted > > to proprietary ways, and they still do, at least in the areas of the > > kernel I'm most active in. > > I'm not going to argue that companies don't make bad business > decisions: they definitely do. And also there are huge reservoirs of > proprietary mindset or fear of losing control in most of them which > tend to drive these bad decisions. I'm just saying we don't have to be > all stick and no carrot. If we can use the carrot to help them make > better business decisions, and overcome the proprietary mindset that > way, so much the better. > > There are also valid reasons to do pass-through, like you don't want to > invest in standardising the interface until you see that you have an > actual market, which is how mixed standardised/pass through systems > like DRM work (they allow innovation and experimentation, not all of > which works). This also matches what we routinely do in the kernel, where in-kernel abstractions are usually developed when we have a handful of drivers that need them. Standardizing interfaces with a single user is more often than not a recipe for failure, not even mentioning the incurred cost. If the main motivation for pass-through is avoidance of the large costs related to standardization when the market is in its infancy, I have no big objection in principle. There could be other issues to take into account though, that would make pass-through problematic for particular cases. In any case, this wouldn't preclude documenting the whole device API. When vendors want to keep part of the API secret and usable by closed-source userspace, the discussion becomes quite different. > > I've seen first hand a large SoC vendor very close to opening a > > significant part of their camera stack and changing their mind at the > > last minute when they heard they could possibly merge their code > > through a different subsystem with a pass-through blank cheque. > > So is the learning here is that perhaps we should co-ordinate better? I don't see how that could hurt :-) My experience with the pass-through discussions so far is that many people in the kernel community are aware of the overall issue, but most lack deep understanding of the case-specific constraints. That's not really surprising as we can't be expert in everything, but it easily leads to the wrong decisions being made. > > I'm willing to believe it can be different in other areas, which may > > partly explain why different subsystems and different developers have > > different biases and have trouble understand each other's point of > > view. > > I think that's true, due to different companies having different levels > of proprietary mindset and other fears of not controlling their own > destiny. However, the basic fact remains that it will be in their best > business interests to be more open if we can encourage it. That's what we've been telling ISP vendors for 5 years, and it's starting to show results. It's a long walk, but I agree it's the best long term strategy. We however sometimes need to combine it with other carrots or sticks along the way, in the shorter term. > > > > I can't fully answer that question, but there are two points that > > > > I think are relevant. Note that due to my background and > > > > experience, this will be heavily biased towards consumer and > > > > embedded hardware, not data centre-grade devices. Some > > > > technologies from the latter however have a tendency to migrate > > > > to the former over time, so the distinction isn't necessarily as > > > > relevant as one may consider. > > > > > > > > The first point is that hardware gets more complicated over time, > > > > and in some markets there's also an increase in the number of > > > > vendors and devices. There's a perceived (whether true or not) > > > > danger that we won't be able to keep up with just reverse > > > > engineering and a development model relying on hobyists. Getting > > > > vendors involved is important if we want to scale. > > > > > > Yes, but there are lots of not very useful complex devices being > > > produced every day that fail to capture market share. Not having > > > reverse engineered drivers for them is no real loss. If a device > > > does gain market share, it gains a huge pool of users some of whom > > > become interested in reverse engineering, so I think market forces > > > actually work in our favour: we get reverse engineering mostly > > > where the devices are actually interesting and capture market > > > share. It's self scaling. > > > > I can't agree with that, sorry. Not only is the difficulty to > > reverse-engineer some classes of devices increasing, > > So it's a higher hill to climb: I didn't say it wasn't. However for > hugely popular devices there's still more likelihood of finding someone > willing to climb it. It's not a guarantee, just a probability, though. Agreed. > > but saying that only devices that make it to the top of the market > > share chart are worth considering will leave many users on the side > > of the road. > > I'm afraid this is simple economics. Suppose we had the budget to pay > for reverse engineering, it's not going to cover everything, so we'd > have to make choices and that would necessarily mean investing in > devices that have utility to the greatest number of people. So low > market share devices would still be left out. Sure, but my point was that we need to get vendors on board and not just rely on reverse engineering if we want to scale. -- Regards, Laurent Pinchart
