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]
Date:	Fri, 2 Jul 2010 21:53:58 +1000
From:	Dave Airlie <airlied@...il.com>
To:	Luc Verhaegen <libv@...net.be>
Cc:	LKML <linux-kernel@...r.kernel.org>,
	dri-devel <dri-devel@...ts.freedesktop.org>
Subject: Re: Closed source userspace graphics drivers with an open source 
	kernel component

> Sure, but you still slammed, and this affected in first order mostly Qualcomm, instead
> of stating that you simply do not want to be involved.

I have no choice but to be involved, again you seem to misunderstand
what my position is.

>
>> They'll keep shipping closed stuff, just like they are now. Are you
>> going to reverse engineer the userspace drivers, so people who care
>> about open and free software platforms can use these drivers? (or have
>> you already signed NDAs saying you can't). Why should we maintain a
>> bunch of kernel code, when they are hiding away all the really useful
>> stuff that people could improve.
>
> Maintaining this exact code is not _your_ job, and you should've stated just that.

Maintaining kernel graphics drivers is my responsibility, a lot of
days i wish it wasn't, and I'm sure some day it won't be, but until
then I have to provide guidance on how things should work. Again you
should look at what being a kernel maintainer is.

>
> You will need to restate this every time anyway, unless you somehow manage to get your
> rather daunting and loud statement to be the first thing such corporations management
> people at linux.com, which is what people type in their browser first.

I'm sure I will, but now I can just point people at this rather public
statement as opposed to private emails.
>
> Heh, i could make a really nasty statement here, but i wont.

Please do, since you've proved you are clueless about this position entails.

> Hrm, i only see _very_ old docs getting updated, and none produced.
>
> I still have docs which are pretty ready to be shipped (from 2007), under uncertain
> legal status (the ati game was fun!), which were never made public. I am sure that
> bridgman, gave you these docs too, but under even more shady circumstances.

Shady circumstances? you might want to ask your lawyer before making
statements like that on a public mailing list.

>> The code doesn't exist, there is no userspace code to be the
>> documents, if you read what I said, documents would be a good start in
>> lieu of code, but code is perfectly fine.
>
>> Imagintaion technologies seriously? they've never ever taken one step
>> towards opening anything, I don't think this statement is suddenly
>> going to jumpstart them.
>
>> Maybe you should disclose what NDAs you currently are under and who
>> pays your bills, since you accuse me of Red Hat mind-control.
>
> Oh, i now work for basysKom, a contractor for, amongst others, nokia, which i'm sure
> you knew.

So you honestly think if I allow Nokia and/or Intel to push a poulsbo
driver into the kernel the magic fairies will come along and open the
userspace because they've seen the light?

What incentive does letting someone like Qualcomm etc put all their
kernel code upstream, and ignoring the userspace components do you
think it provides to open the userspace component, for once I'm
interested in your opinion since you seem to have the ARM players all
worked out. Previous experience with most companies has shown they'll
do as little as possible to ensure they can ship as many things as
possible, and this is fine, they need real incentives to follow the
open source rules.

>
>> I'm not sure how the ARM market would benefit from having no userspace
>> 3D drivers just like the x86 market, if you actually were normal you'd
>> realise the ARM people are trying to screw the market just like the
>> desktop people, to save themselves some money, but maybe working on
>> closed drivers has twisted you.
>
> Ah, so you did know.
>
> As a free software graphics driver developer there is little option left but to go
> straight to the ARM world, at least things have potential to move there still.

What potential? there are maybe 6 players on the ARM graphics scene

Imagination Technologies SGX, used in TI and poulsbo/mrst(x86) - no
hope of opening userspace
ARM Mali - not sure what is going on there, I;m going to go with no
hope but would be nice to be proved wrong
Qualcomm SnapDragon - imageon by another name, from what I can and
from talking to Jordan on irc, they don't seem to have much incentive
to bother working on an open userspace
Marvell - maybe OLPC can make them open a userspace for millions of
sales, it doesn't seem to have worked with VIA for 10s of thousands of
persumable sales
Samsung - also holding out hope for something maybe, they seemed to
have some interest once, but not sure what happening now.
Nvidia - well we know their position will never change.

So we should have six completely separate stacks shipping in the
kernel not using drm or kms, but all standalone, all with closed
userspace drivers, with no maintainer, thanks that is not a future I'm
interested in, and generally from experience in Linux it isn't
something we've had much luck with before, wireless, networking, sw
raid, etc all have this sort of vendor demands and it took independent
maintainer pushback to achieve some cooperation and get what we have
today.

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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ