public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Pete Zaitcev <zaitcev@redhat.com>
To: David Woodhouse <dwmw2@infradead.org>
Cc: Greg KH <greg@kroah.com>, Adrian Bunk <bunk@stusta.de>,
	mdharm-usb@one-eyed-alien.net, zaitcev@redhat.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: Mon, 24 Jan 2005 09:49:22 -0800	[thread overview]
Message-ID: <20050124094922.165fa988@localhost.localdomain> (raw)
In-Reply-To: <1106567331.6480.43.camel@localhost.localdomain>

On Mon, 24 Jan 2005 11:48:51 +0000, David Woodhouse <dwmw2@infradead.org> wrote:

> On Wed, 2005-01-19 at 14:07 -0800, Greg KH wrote:
> > 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?
> > 
> > > -#if !defined(CONFIG_BLK_DEV_UB) && !defined(CONFIG_BLK_DEV_UB_MODULE)
> > >  UNUSUAL_DEV(  0x0781, 0x0002, 0x0009, 0x0009, 
> > >  		"Sandisk",
> > >  		"ImageMate SDDR-31",
> > >  		US_SC_DEVICE, US_PR_DEVICE, NULL,
> > >  		US_FL_IGNORE_SER ),
> > > -#endif
> 
> Urgh. Please do. Code which may compile differently in the kernel image
> according to which _modules_ are configured at the time is horrid, and
> should be avoided.

The fallacy of this "urgh" is easy to demonstrate when you consider usb-storage
and ub the one and the same driver. Initially, ub was just a mode for
usb-storage ("threadless"). I only factored them separate for reasons
of clarity. Horrid, indeed. There's no reason to build one statically
and another as a module.

Mind, I didn't disagree with the backout patch as such, but not because
it was a good idea, but because it may help to shut up a few stupid users
(provided that our scripts preserve the link order from drivers/usb/Makefile
in modules.usbmap, or have other way to make sure that usb-storage entries
are ahead of ub entires; did anyone actually check it? if those scripts
sort by name, ub still pops ahead, and the backout is utterly ineffectual).

When we reintroduce ub in Fedora, I'll just put this patch right back,
it's not a problem. But please think about this issue a little more,
you might want to take the Urgh back.

-- Pete

      reply	other threads:[~2005-01-24 17:51 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
2005-01-21  0:04         ` Greg KH
2005-01-24 11:48       ` David Woodhouse
2005-01-24 17:49         ` Pete Zaitcev [this message]

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=20050124094922.165fa988@localhost.localdomain \
    --to=zaitcev@redhat.com \
    --cc=bunk@stusta.de \
    --cc=dwmw2@infradead.org \
    --cc=greg@kroah.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb-devel@lists.sourceforge.net \
    --cc=mdharm-usb@one-eyed-alien.net \
    /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