public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <gregkh@suse.de>
To: Parag Warudkar <parag.lkml@gmail.com>
Cc: Stefan Richter <stefanr@s5r6.in-berlin.de>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	linux-kernel@vger.kernel.org,
	Andreas Gruenbacher <agruen@suse.de>,
	Jeff Mahoney <jeffm@suse.de>
Subject: Re: [patch 00/04] RFC: Staging tree (drivers/staging)
Date: Fri, 26 Sep 2008 15:03:51 -0700	[thread overview]
Message-ID: <20080926220351.GA9762@suse.de> (raw)
In-Reply-To: <f7848160809261356p1268f251pfc5bc8477862723@mail.gmail.com>

On Fri, Sep 26, 2008 at 04:56:19PM -0400, Parag Warudkar wrote:
> On Fri, Sep 26, 2008 at 4:19 PM, Greg KH <gregkh@suse.de> wrote:
> 
> > If you really don't like it, just never enable any of these modules,
> > you'll never be bothered by it.
> 
> So you are saying if a distro ships allmodconfig kernels or ships the
> crap modules in the hope that people will find them useful and I have
> one of the devices in my machine that I don't care about - I should
> just let the crap module autoload and crash/taint my kernel or take
> the special step of blacklisting all of them or build my own kernel -
> as unreasonable as ever.

If your distro does this, then they will have their own rules in place
for supporting this.  Take it up with them if they decide to enable
this.

> Or  are you saying distros should not build the crap modules - that
> doesn't make sense since it will drastically reduce the usage and
> delay the identification of problems until later.

I'm saying distros need to evaluate this based on their own usage /
support model, just like they do so for all other config options.

As an example, for a distro that I know a bit about, I can see openSUSE
enabling this option and supporting these drivers the best that they
can, but for the SLES product line, which doesn't even load any modules
that are not fully L3 supported, these drivers would not be included.

As others have raised, the issue, I'll leave the driver names alone, it
would just confuse people even more if they changed, the modalias flag
is good enough to mark them by for now.

thanks,

greg k-h

  reply	other threads:[~2008-09-26 22:07 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20080924224638.514504825@mini.kroah.org>
2008-09-24 23:00 ` [patch 00/04] RFC: Staging tree (drivers/staging) Greg KH
2008-09-24 23:01   ` [patch 01/04] Staging: add TAINT_CRAP for all drivers/staging code Greg KH
2008-09-24 23:01   ` [patch 02/04] Staging: add TAINT_CRAP flag to drivers/staging modules Greg KH
2008-09-24 23:01   ` [patch 04/04] USB: add princeton instruments usb camera driver Greg KH
2008-09-24 23:01   ` [patch 03/04] Staging: add Kconfig entries and Makefile infrastructure Greg KH
2008-09-24 23:39   ` [patch 00/04] RFC: Staging tree (drivers/staging) Parag Warudkar
2008-09-25  1:03     ` Randy Dunlap
2008-09-25  2:06       ` Greg KH
2008-09-25  2:06     ` Greg KH
2008-09-25  2:59       ` Parag Warudkar
2008-09-25  4:21         ` Greg KH
2008-09-25 11:02           ` Parag Warudkar
2008-09-25 20:53             ` Greg KH
2008-09-25 21:40               ` Parag Warudkar
2008-09-25 22:04                 ` Greg KH
2008-09-25 22:22                   ` Parag Warudkar
2008-09-26 18:36                     ` Stefan Richter
2008-09-26 20:11                       ` Parag Warudkar
2008-09-26 20:19                         ` Greg KH
2008-09-26 20:56                           ` Parag Warudkar
2008-09-26 22:03                             ` Greg KH [this message]
2008-09-26 21:00                           ` Leon Woestenberg
2008-09-26 22:04                             ` Greg KH
2008-09-26 20:39                         ` Stefan Richter
2008-09-26 20:47                           ` Parag Warudkar
2008-09-26 22:46                             ` Stefan Richter
2008-09-25  5:27         ` Paul Mundt
2008-09-25 14:49           ` Randy Dunlap
2008-09-25 17:53             ` Randy Dunlap
2008-09-25 20:48               ` Greg KH
2008-09-25 21:04                 ` Randy Dunlap
2008-09-25 21:51                   ` Stefan Richter
2008-10-06 15:11               ` config_experimental was " Pavel Machek
2008-10-09 21:01   ` Adrian Bunk
2008-10-09 21:08     ` Greg KH
2008-10-09 21:17     ` Andrew Morton

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=20080926220351.GA9762@suse.de \
    --to=gregkh@suse.de \
    --cc=agruen@suse.de \
    --cc=akpm@linux-foundation.org \
    --cc=jeffm@suse.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=parag.lkml@gmail.com \
    --cc=stefanr@s5r6.in-berlin.de \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox