lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1246123235.3990.15.camel@mulgrave.site>
Date:	Sat, 27 Jun 2009 12:20:35 -0500
From:	James Bottomley <James.Bottomley@...senPartnership.com>
To:	Joe Perches <joe@...ches.com>
Cc:	linux-kernel@...r.kernel.org, Adam Radford <linuxraid@...c.com>,
	Adaptec OEM Raid Solutions <aacraid@...ptec.com>,
	Rik Faith <faith@...unc.edu>,
	Neela Syam Kolli <megaraidlinux@....com>,
	Willem Riede <osst@...de.org>,
	Kai Mäkisara <Kai.Makisara@...umbus.fi>,
	Matthew Wilcox <matthew@....cx>,
	Guennadi Liakhovetski <g.liakhovetski@....de>,
	Kurt Garloff <garloff@...e.de>, linux-scsi@...r.kernel.org,
	osst-users@...ts.sourceforge.net
Subject: Re: [PATCH 14/19] drivers/scsi: Use PCI_VDEVICE

On Wed, 2009-06-24 at 22:13 -0700, Joe Perches wrote:
> Signed-off-by: Joe Perches <joe@...ches.com>

OK, so there's no description whatsoever how am I supposed to divine the
reasons for doing this?

Because if I look at an example:

> --- a/drivers/scsi/3w-9xxx.c
> +++ b/drivers/scsi/3w-9xxx.c
> @@ -2278,14 +2278,10 @@ out_disable_device:
>  
>  /* PCI Devices supported by this driver */
>  static struct pci_device_id twa_pci_tbl[] __devinitdata = {
> -	{ PCI_VENDOR_ID_3WARE, PCI_DEVICE_ID_3WARE_9000,
> -	  PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0},
> -	{ PCI_VENDOR_ID_3WARE, PCI_DEVICE_ID_3WARE_9550SX,
> -	  PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0},
> -	{ PCI_VENDOR_ID_3WARE, PCI_DEVICE_ID_3WARE_9650SE,
> -	  PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0},
> -	{ PCI_VENDOR_ID_3WARE, PCI_DEVICE_ID_3WARE_9690SA,
> -	  PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0},
> +	{ PCI_VDEVICE(3WARE, PCI_DEVICE_ID_3WARE_9000), 0},
> +	{ PCI_VDEVICE(3WARE, PCI_DEVICE_ID_3WARE_9550SX), 0},
> +	{ PCI_VDEVICE(3WARE, PCI_DEVICE_ID_3WARE_9650SE), 0},
> +	{ PCI_VDEVICE(3WARE, PCI_DEVICE_ID_3WARE_9690SA), 0},

It appears to take PCI matching on vendor device with any subvendor,
device and reproduce the results with a macro, which, for good measure
pastes PCI_VENDOR_ID on to the first argument but *doesn't* paste
PCI_DEVICE_ID on to the second?

So it transforms a relatively opaque initialiser which most people would
have to look up in pci.h into another relatively opaque initialiser
indirected via a macro, so now I have to look up both the structure and
the macro to figure out what's going on.

If that's all it does, I'm having a hard time seeing any actual
improvement here.

James


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ