public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <greg@kroah.com>
To: Chris Friesen <cfriesen@nortel.com>
Cc: Lee Revell <rlrevell@joe-job.com>,
	Xavier Bestel <xavier.bestel@free.fr>,
	linux-kernel@vger.kernel.org,
	Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [RFC] Simple userspace interface for PCI drivers
Date: Thu, 31 Aug 2006 14:39:35 -0700	[thread overview]
Message-ID: <20060831213935.GA11939@kroah.com> (raw)
In-Reply-To: <44F74C66.7000705@nortel.com>

On Thu, Aug 31, 2006 at 02:53:58PM -0600, Chris Friesen wrote:
> Lee Revell wrote:
> 
> >Why?  There's no technical or legal requirement for userspace drivers to
> >be GPLed.
> 
> I could see a benefit to tainting the kernel once userspace starts 
> poking at the hardware directly.  That way at least we'd know that a 
> crash might be due to userspace doing bad things.
> 
> For instance, consider the case where userspace misprograms a DMA 
> engine, which starts overwriting random kernel memory.

Then you get to keep the two pieces that the kernel just broke into.

We can't "taint" anything here.  Userspace is doing these kinds of
things already today.  You can mmap a PCI device and plug away at all
sorts of fun things with it right now.  You can to /dev/mem fun tricks,
and all sorts of other 'evil' things.

And us kernel developers don't really care.

What this framework does, is give users who already do this kind of
userspace driver thing today, a sane interface in which to do it.  One
that is simple and fast, and makes sense, unlike almost every other
proposal like this that I have seen in the past.

We are trying to help people out here.  Pushing drivers to userspace is
a good thing from a kernel's perspective, if they work well for the
driver in question.  USB has been doing this for years quite well.  This
just allows the PCI interrupt to be sanely handled so PCI and other
types of devices like it, can also work in a well defined way.

If a author of a driver doesn't want to put it in the kernel for
whatever reason, that's fine, do it in userspace.  Not all types of
drivers make sense in the kernel as they don't need any of the things
kernelspace is good for (speed, caching, common userspace interfaces,
etc.)

So there is nothing to worry about here, except for more Linux based,
laser welding robots taking over your neighborhood manufacturing plant.

And to answer the question that everyones been asking me in private, no,
I have no idea if nVidia or ATI can use this interface to move their
kerneldrivers out into userspace.  I've never seen that code and do not
know what their requirements are, nor do I care.  Go ask them, they know
this kind of thing, I sure don't.  And if they can move them there,
bully for them.

I don't know why people have this morbid fascination with these two,
monstrously horrible closed source drivers.  There are way more much
more insidious and common closed source Linux kernel modules out there
right now that everyone in the press seems to be ignoring.  Those are
the ones that I worry about...

And those are the ones that this interface might just help out with, and
if that happens, it is a very good thing for Linux overall.

thanks,

greg k-h

  reply	other threads:[~2006-08-31 21:39 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-08-30  6:23 [RFC] Simple userspace interface for PCI drivers Greg KH
2006-08-30 10:09 ` Thomas Gleixner
2006-08-30 14:34 ` Matt Porter
2006-08-30 16:25   ` Thomas Gleixner
2006-08-30 17:55   ` Greg KH
2006-08-30 20:32     ` Foli Ayivoh
2006-08-30 21:01     ` Matthias Schniedermeyer
2006-08-30 21:25       ` linux-os (Dick Johnson)
2006-08-30 22:08         ` Greg KH
2006-09-01  1:36     ` Brice Goglin
2006-09-01  3:22       ` Greg KH
2006-09-01  3:37         ` Brice Goglin
2006-09-01  4:27           ` Greg KH
2006-08-31 13:49   ` Andi Kleen
2006-09-01 18:16     ` Greg KH
2006-08-30 17:07 ` Manu Abraham
2006-08-30 17:52   ` Greg KH
2006-08-30 22:50     ` Manu Abraham
2006-08-31  0:17       ` Greg KH
2006-08-31 13:24         ` Manu Abraham
2006-08-31 22:42           ` Greg KH
2006-08-31  7:40 ` Andrew Morton
2006-08-31  8:05   ` Thomas Gleixner
2006-08-31  8:30 ` Xavier Bestel
2006-08-31 20:39   ` Lee Revell
2006-08-31 20:53     ` Chris Friesen
2006-08-31 21:39       ` Greg KH [this message]
2006-08-31 20:58     ` Xavier Bestel
2006-08-31 21:12       ` Lee Revell
2006-08-31 21:18         ` Xavier Bestel
2006-08-31 21:33           ` Manu Abraham
2006-08-31 21:40       ` Greg KH
2006-09-01 21:17 ` Pavel Machek
2006-09-03  8:34   ` Thomas Gleixner
2006-09-12 19:47 ` Sam Ravnborg
2006-09-14  5:57   ` Greg KH

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=20060831213935.GA11939@kroah.com \
    --to=greg@kroah.com \
    --cc=cfriesen@nortel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rlrevell@joe-job.com \
    --cc=tglx@linutronix.de \
    --cc=xavier.bestel@free.fr \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox