linux-kernel - [patch] use C99 initialisers for PCI

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-next>] [day] [month] [year] [list]

Message-Id: <200704151234.37463.doomster@knuut.de>
Date:	Sun, 15 Apr 2007 12:34:36 +0200
From:	Ulrich Eckhardt <doomster@...ut.de>
To:	linux-kernel@...r.kernel.org
Subject: [patch] use C99 initialisers for PCI_VDEVICE()

(Note: CC me please, I'm not subscribed.)

Not much to say about the patch (it's against 2.6.20.6), it just converts a 
macro to generate C99-style initialisers.

--- include/linux/pci.h   (revision 17)
+++ include/linux/pci.h   (working copy)
@@ -407,9 +407,10 @@
  * private data.
  */

-#define PCI_VDEVICE(vendor, device)            \
-       PCI_VENDOR_ID_##vendor, (device),       \
-       PCI_ANY_ID, PCI_ANY_ID, 0, 0
+#define PCI_VDEVICE(vend, dev)         \
+       .vendor=PCI_VENDOR_ID_##vend, .device=(dev),    \
+       .subvendor=PCI_ANY_ID, .subdevice=PCI_ANY_ID,   \
+       .class=0, .class_mask=0

However, I still have two issues with this:
1. It explicitly allows in the comments for PCI_VDEVICE to have non-C99 fields 
follow for the driver_data field. IMHO this is wrong per se (just as 
old-style initialisers are), so the comment should perhaps be removed.
2. What happens to fields not initialised with this? I believe that these are 
initialised with zero, just like missing fields in old initialisers are, 
right? In that case, I would remove the initialisers for class and 
class_mask, so that people can at least optionally use them. However, this 
goes hand in hand with issue #1 because it would definitely break code that 
lets old-style initialisers follow.

As far as issue #2 is concerned, I did some checking (grep -r PCI_VDEVICE) and 
the only places where this is at all used is in the ATA code (drivers/ata)! 
Hmmm, no problem, that is grunt work but easily patched, too. If consensus 
exists that the class/class_mask fields should be removed, I hereby volunteer 
to submit a patch for that and the ATA code.

Uli
-
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/