linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Milton Miller <miltonm@bga.com>
To: Greg KH <greg@kroah.com>
Cc: Michael Ellerman <michael@ellerman.id.au>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	Jesse Barnes <jbarnes@virtuousgeek.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	linux-pci@vger.kernel.org, Jean Delvare <khali@linux-fr.org>,
	Greg KH <gregkh@suse.de>
Subject: Re: [PATCH/RFC] pci: dynids.use_driver_data considered harmful
Date: Thu, 17 Jul 2008 09:36:14 -0500	[thread overview]
Message-ID: <8c10c96094849c022d42a9d7d625e525@bga.com> (raw)
In-Reply-To: <20080717070759.GE22090@kroah.com>


On Jul 17, 2008, at 2:07 AM, Greg KH wrote:

> On Wed, Jul 16, 2008 at 05:18:18AM -0500, Milton Miller wrote:
>>
>> Greg,
>>
>> Please respond to this email and explain why the patch
>>
>> pci: dynids.use_driver_data considered harmful
>>
>> http://www.ussg.iu.edu/hypermail/linux/kernel/0807.1/index.html#2188
>>
>> should not be applied.   I am not arguing the correctness of
>> the removed code, rather its utility and benefit to the linux
>> community.
>>
>> As far as I can tell, the code only succeeds in limiting the
>> usefulness of the pci dynamic id addition mechanism.
...
>
> Sorry, I'm on the road right now and will not get back until Friday.
> Then I have the big merges with Linus to get through.  I'll try to get
> to this by Monday, but my original point still stands, this was
> implemented for a reason, saying that not enough drivers use it 
> properly
> does not make the need for it to go away.  It is required for them, so
> perhaps the other 419 drivers also need to have the flag set.  That's
> pretty trivial to do, right?
>

Fine, I'll give you a little time.  But I want to hear specifics how it
helps drivers.   I have shown how it hurts many drivers.   My arguement
is that once we set the flag on the drivers, we will end up with it set
on all drivers or the remaining drivers will not care.   There were 413+
drivers in linux-next that were compiled by allyesconfig, about 150 used
driver data.

If the purpose is to enforce range checking, then I'll start working on
patches for those 100 drivers to do that.   But I don't see why a binary
flag helps any driver.   The flag is not "I will accept a additional id
table", its "I will accept the additional driver data that I need to
operate" on my dynamically added id table.

milton


  reply	other threads:[~2008-07-17 14:34 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-07-10 21:12 [RFC] (almost) booting allyesconfig -- please don't poke super-io without request_region Milton Miller
2008-07-10 21:14 ` mtd: remove __PPC__ hardcoded address from nand/diskonchip and devices/docprobe Milton Miller
2008-07-10 21:33 ` [lm-sensors] [RFC] (almost) booting allyesconfig -- please don't poke super-io without request_region Hans de Goede
2008-07-10 21:51   ` Milton Miller
2008-07-11  6:52     ` Jean Delvare
2008-07-11  7:27       ` Hans de Goede
2008-07-11  7:36         ` Jean Delvare
2008-07-13  6:31           ` Hans de Goede
2008-07-13 21:11             ` [lm-sensors] " David Hubbard
2008-07-13 21:22               ` Hans de Goede
2008-07-13 21:26                 ` David Hubbard
2008-07-14  7:59                   ` Jean Delvare
2008-07-14 17:09                     ` Milton Miller
2008-07-14 17:30                       ` [lm-sensors] " Hans de Goede
2008-07-14 17:55                         ` David Hubbard
2008-07-15  8:36                           ` Jean Delvare
2008-07-15 15:31                             ` David Hubbard
2008-07-16  7:46                               ` Jean Delvare
2008-07-16  8:09                                 ` Rene Herman
2008-07-15  8:28                       ` Jean Delvare
     [not found] ` <for-27-patch9@bga.com>
2008-07-12 20:02   ` [PATCH/RESEND] pci: dynids.use_driver_data considered harmful Milton Miller
2008-07-12 20:17     ` Greg KH
2008-07-12 20:58       ` Jean Delvare
2008-07-12 21:17       ` Milton Miller
2008-07-12 21:29         ` Milton Miller
     [not found]   ` <20080712041137.GA5933@kroah.com>
2008-07-12 21:08     ` [PATCH/RFC] " Milton Miller
2008-07-12 22:48       ` Milton Miller
2008-07-16 10:18         ` Milton Miller
2008-07-17  7:07           ` Greg KH
2008-07-17 14:36             ` Milton Miller [this message]
2008-08-06  7:31             ` Jean Delvare
2008-08-14 22:12               ` Greg KH
2008-08-15 14:50                 ` Milton Miller
2008-08-15 15:50                 ` Jean Delvare
2008-08-15 17:46                   ` Jesse Barnes
2008-08-15 18:55                     ` Jean Delvare
2008-08-15 19:15                       ` Jesse Barnes
2008-08-16  6:22                         ` Greg KH
2008-08-17 19:06                           ` Jean Delvare
2008-08-18  3:50                             ` Greg KH
2008-08-18 17:13                             ` Jesse Barnes
2008-08-18 20:41                             ` Jesse Barnes
2008-08-19 18:01                             ` Milton Miller
2008-08-06  7:22           ` Jean Delvare

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=8c10c96094849c022d42a9d7d625e525@bga.com \
    --to=miltonm@bga.com \
    --cc=akpm@linux-foundation.org \
    --cc=greg@kroah.com \
    --cc=gregkh@suse.de \
    --cc=jbarnes@virtuousgeek.org \
    --cc=khali@linux-fr.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=michael@ellerman.id.au \
    /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;
as well as URLs for NNTP newsgroup(s).