All of lore.kernel.org
 help / color / mirror / Atom feed
From: Willy Tarreau <w@1wt.eu>
To: Matthew <jackdachef@gmail.com>
Cc: greg@kroah.com, Linux Kernel <linux-kernel@vger.kernel.org>,
	Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: [ANNOUNCE] Position Statement on Linux Kernel Modules
Date: Mon, 23 Jun 2008 15:21:18 +0200	[thread overview]
Message-ID: <20080623132118.GC1369@1wt.eu> (raw)
In-Reply-To: <e85b9d30806230602m10b5aa06m2f1c83e1a90a7dac@mail.gmail.com>

On Mon, Jun 23, 2008 at 03:02:58PM +0200, Matthew wrote:
> Hi Greg,
> 
> I largely agree to this statement,
> 
> there are however some downsides if you're preventing driver
> manufacturers (e.g. nvidia, ...) from the possibility to offer their
> customers proprietary drivers:
> 
> 1) One big and important point for me (and more and more future
> linux-users) is powersaving features on GPUs like powermizer (by
> nvidia) and powerplay (by AMD/ATI) or other hardware. I haven't seen
> this working on newer graphics cards models with the opensource
> drivers to the present day :(

I think that's one of the reasons of Greg's post.

(...)
> if those companies can't use their own closed proprietary drivers
> utilizing patented routines they are "forced" to use

You're wrong here. If they have patented routines, they don't need
their drivers to be closed, since there routines are protected by
patents. And even if they are not patented, not releasing the source
will not prevent a competitor from disassembling the code anyway.
So there's really no point in remaining closed. Some of them might
have signed NDAs before using some technologies, but by this time,
they should have sorted that our.

> they might think over it and switch to another operating system ...

Do you know many products with closed Linux drivers which are not
supported by at least one closed OS ? If they chose to support
Linux, it's not for your pleasure, just because they know they will
sell 5-10% more when a penguin is stuck on the box.

> 2) How will this affect performance, if all of those drivers are
> limited to an user-space interface?
> 
> I'm not a kernel hacker and don't have much insight into the kernel
> and kernel-development, so I can only reflect, what I've read:
> much of you kernel hackers are supposed to have said (read that on
> blogs, forums etc.) that nvidia's drivers are hackish and that it uses
> routines which shouldn't be used by this kind of drivers
> 
> other voices are saying nvidia is doing this because the linux-kernel
> lacks a common interface (yet) which disallows effective usage of the
> graphics cards which would result in abysmal bad performance not using
> their hacking ...

That has nothing to do with open/close. They may as well continue to
use their dirty hacks when the sources are public. That just means that
owners of such cards on other platforms (PPC, etc...) might be able to
build the drivers for those platforms. I think that most users don't
care about the fact that a driver is dirty. They want something which
simply builds for their platform. Also, publishing their dirty hacks
will encourage kernel developers to propose some cleaner alternatives
or to extend the kernel in order to ease integration of such drivers.

Willy


  reply	other threads:[~2008-06-23 13:21 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-06-23 13:02 [ANNOUNCE] Position Statement on Linux Kernel Modules Matthew
2008-06-23 13:21 ` Willy Tarreau [this message]
2008-06-25 22:45   ` jdow
2008-06-25 23:11     ` Willy Tarreau
2008-06-28  3:28       ` jdow
2008-06-23 18:11 ` Greg KH
  -- strict thread matches above, loose matches on Subject: below --
2008-06-23  5:01 Greg KH
2008-06-23 10:00 ` Jiri Kosina
2008-06-23 14:24   ` Greg KH
2008-06-23 11:29 ` Greg Louis
2008-06-23 13:09   ` Willy Tarreau
2008-06-24 11:33     ` Greg Louis
2008-06-24 15:02       ` David Newall
2008-06-23 18:12   ` Greg KH
2008-06-23 18:15 ` Måns Rullgård

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20080623132118.GC1369@1wt.eu \
    --to=w@1wt.eu \
    --cc=greg@kroah.com \
    --cc=jackdachef@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.