All of lore.kernel.org
 help / color / mirror / Atom feed
From: Matthew Dharm <mdharm-kernel@one-eyed-alien.net>
To: Greg KH <greg@kroah.com>
Cc: Adrian Bunk <bunk@stusta.de>,
	zaitcev@yahoo.com, linux-usb-devel@lists.sourceforge.net,
	linux-kernel@vger.kernel.org
Subject: Re: RFC: [2.6 patch] let BLK_DEV_UB depend on USB_STORAGE=n
Date: Wed, 19 Jan 2005 18:49:00 -0800	[thread overview]
Message-ID: <20050120024900.GA5506@one-eyed-alien.net> (raw)
In-Reply-To: <20050119220707.GM4151@kroah.com>

[-- Attachment #1: Type: text/plain, Size: 1699 bytes --]

On Wed, Jan 19, 2005 at 02:07:07PM -0800, Greg KH wrote:
> On Thu, Dec 23, 2004 at 03:40:31AM +0100, Adrian Bunk wrote:
> > On Sun, Dec 19, 2004 at 04:31:46PM -0800, Greg KH wrote:
> > > On Mon, Dec 20, 2004 at 01:16:44AM +0100, Adrian Bunk wrote:
> > > > I've already seen people crippling their usb-storage driver with 
> > > > enabling BLK_DEV_UB - and I doubt the warning in the help text added 
> > > > after 2.6.9 will fix all such problems.
> > > > 
> > > > Is there except for kernel size any good reason for using BLK_DEV_UB 
> > > > instead of USB_STORAGE?
> > > 
> > > You don't want to use the scsi layer?  You like the stability of it at
> > > times?  :)
> > > 
> > > > If not, I'd suggest the patch below to let BLK_DEV_UB depend
> > > > on EMBEDDED.
> > > 
> > > No, it's good for non-embedded boxes too.
> > 
> > 
> > My current understanding is:
> > - BLK_DEV_UB supports a subset of what USB_STORAGE can support
> > - for an average user, there's no reason to enable BLK_DEV_UB
> > - if you really know what you are doing, there might be several reasons
> >   why you might want to use BLK_DEV_UB
> 
> I have been running with just the code portion of this patch for a while
> now, with good results (no Kconfig changes.)
> 
> Pete and Matt, do you mind me applying the following portion of the
> patch to the kernel tree?

I have no objection.

Matt

-- 
Matthew Dharm                              Home: mdharm-usb@one-eyed-alien.net 
Maintainer, Linux USB Mass Storage Driver

E:  You run this ship with Windows?!  YOU IDIOT!
L:  Give me a break, it came bundled with the computer!
					-- ESR and Lan Solaris
User Friendly, 12/8/1998

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

  reply	other threads:[~2005-01-20  2:50 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-12-20  0:16 RFC: [2.6 patch] let BLK_DEV_UB depend on EMBEDDED Adrian Bunk
2004-12-20  0:29 ` Pete Zaitcev
2004-12-20  0:31 ` Greg KH
2004-12-20  1:35   ` Adrian Bunk
2004-12-20  4:51     ` Pete Zaitcev
2004-12-20  5:09       ` Randy.Dunlap
2004-12-20  6:20         ` Matthew Dharm
2004-12-20  6:37           ` Pete Zaitcev
2004-12-20  7:28             ` [linux-usb-devel] " Phil Dibowitz
2004-12-20  8:09             ` Matthew Dharm
2004-12-20  8:25               ` [linux-usb-devel] " Phil Dibowitz
2004-12-20  8:44               ` Pete Zaitcev
2004-12-20  8:59                 ` [linux-usb-devel] " Phil Dibowitz
2004-12-20 12:02             ` Ed Tomlinson
2004-12-20 15:28               ` [linux-usb-devel] " Alan Stern
2004-12-20 15:35                 ` Greg KH
2004-12-20 20:46                 ` Lee Revell
2004-12-22  8:10             ` Rob Browning
2004-12-23  1:45               ` Theodore Ts'o
2004-12-20  6:43           ` David Brownell
2004-12-20  7:06             ` Pete Zaitcev
2004-12-20 16:03               ` [linux-usb-devel] " David Brownell
2004-12-20  6:30         ` Pete Zaitcev
2004-12-20 15:25           ` [linux-usb-devel] " Alan Stern
2004-12-23  2:40   ` RFC: [2.6 patch] let BLK_DEV_UB depend on USB_STORAGE=n Adrian Bunk
2005-01-19 22:07     ` Greg KH
2005-01-20  2:49       ` Matthew Dharm [this message]
2005-01-21  0:04         ` Greg KH
2005-01-24 11:48       ` David Woodhouse
2005-01-24 17:49         ` Pete Zaitcev

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=20050120024900.GA5506@one-eyed-alien.net \
    --to=mdharm-kernel@one-eyed-alien.net \
    --cc=bunk@stusta.de \
    --cc=greg@kroah.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb-devel@lists.sourceforge.net \
    --cc=zaitcev@yahoo.com \
    /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.