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: <f2b55d220702260216j17003b19l44d8275d9e87950@mail.gmail.com>
Date:	Mon, 26 Feb 2007 02:16:20 -0800
From:	"Michael K. Edwards" <medwards.linux@...il.com>
To:	Alan <alan@...rguk.ukuu.org.uk>
Cc:	"Pavel Machek" <pavel@....cz>, davids@...master.com,
	"v j" <vj.linux@...il.com>, trent.waddington@...il.com,
	"Linux-Kernel@...r. Kernel. Org" <linux-kernel@...r.kernel.org>,
	"Neil Brown" <neilb@...e.de>
Subject: Re: GPL vs non-GPL device drivers

On 2/25/07, Alan <alan@...rguk.ukuu.org.uk> wrote:
> > Busy-wait loops were a rhetorical flourish, I grant you.
>
> Thats a complicated fancy way of saying you were talking rubbish ?

No, it's a way of saying "yes, there are deliberate performance limits
in the driver code, but they're harder to explain than busy-wait
loops".  Ask anyone who has worked inside a peripheral device company,
especially one that sells into the OEM/ODM market.  It is
_standard_practice_ to fab a single chip design that runs as fast as
you know how, and then dumb it down in firmware to meet the spec that
the board vendor is willing to pay for.  If you don't, those guys will
steal you blind, diverting chips intended (and priced) for low-margin
commodity mobos into the high-margin gamer market.

There is, however, a gross error in my latest explanation of why ATI
and NVidia don't provide full driver source code.  Really an
embarrassing oversight.  Wouldn't blame you for ripping me a new one
over it.  Pity you were busy taking cheap shots at my tortured syntax.
 Here's what I forgot:

Macrovision.

Not that any of the stuff about market segmentation, retail margins,
and the FCC isn't true, but it's not the scariest thing in a PC
graphics vendor's world.  The scariest thing in their world is the
possibility that it will become widely known how to defeat the
"Macrovision in, Macrovision out" mechanism (and the equivalent for
DVD playback and HDMI).

Just so you know I'm not making this up:  I know where the "defeat
Macrovision" bits are on certain devices, and if I told you, Jack
Valenti would personally come to my house and ream me out with a
red-hot poker.  (Alan, that's a special kind of "talking rubbish"
known as "comic hyperbole".  I learned it from your Monty Python.  :-)
 Seriously though, those bits are in there, they're software
controlled (or were when I last fiddled with set-tops), and there are
large security deposits and large threats of being shut out of the
MPEG/DVD and DVI/HDMI patent pools riding on the graphics card makers'
promises to keep them hidden.  Not that they're that hard to reverse
engineer -- but they're not going to help you.

You're going to say this cat is already out of the bag; a quarter of
the teenagers in developed countries have the MaD sKiLlZ to rip DVDs
and pass them around on BitTorrent like so much 1970s kiddie porn.
And maybe that's so; but imagine next year's family PC with the HDMI
port attached to the 62" HDTV, dual-booting pirated Windows for
pirated first-person shooters and Linux for pirated DVDs, both of them
conveniently pre-installed by the neighborhood store-front beige-box
assembler.  That's the MPAA's worst nightmare -- and frankly, I'm not
too keen on it either.  I like seeing old movies lovingly restored and
published on DVD.  I'd like to see them come out someday in 16:9 720p,
preferably while my eyes are still good enough to tell the difference.

Anyway, that's more than enough purple prose.  Believe what you want to believe.
-
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