From: Richard Weinberger <hidden> Date: 2015-06-30 19:01:28
On Tue, Jun 30, 2015 at 4:53 PM, Fujinaka, Todd [off-list ref] wrote:
I don't see the reason this is needed so I'm going to say NAK.
Using generic functions is always better than open coded stuff.
Linux's ARRAY_SIZE also makes sure that the passed variable is actually
an array.
--
Thanks,
//richard
Sorry for the top-posting, but I'm provided with the tools they give me and bottom posting from Outlook just confuses email threads. Plus, this was crossposted all over creation and cc-ed to anyone with an intel address.
I still would say no if I'm allowed, because to guarantee that this change - that I don't think fixes anything - works in all cases, we need to do an incredible amount of regression testing. Every variant of every Intel part that uses this driver (and there are many) should be tested and will end up being used by the community.
Plus, you have no idea the number of obscure bugs I have to deal with as the guy answering customer questions. If this triggers some odd embedded compiler bug, I'm going to have to dig it out. Unless there is an actual bug, I'd like to leave it as it is.
Todd Fujinaka
Software Application Engineer
Networking Division (ND)
Intel Corporation
todd.fujinaka@intel.com
(503) 712-4565
-----Original Message-----
From: Richard Weinberger [mailto:richard.weinberger@gmail.com]
Sent: Tuesday, June 30, 2015 12:01 PM
To: Fujinaka, Todd
Cc: Maninder Singh; Kirsher, Jeffrey T; Brandeburg, Jesse; Nelson, Shannon; Wyborny, Carolyn; Skidmore, Donald C; Vick, Matthew; Ronciak, John; Williams, Mitch A; intel-wired-lan@lists.osuosl.org; netdev@vger.kernel.org; linux-kernel@vger.kernel.org; pankaj.m@samsung.com
Subject: Re: [Intel-wired-lan] [PATCH 1/1] igb: Use ARRAY_SIZE instead fo sizeof(a)/sizeof(a[0])
On Tue, Jun 30, 2015 at 4:53 PM, Fujinaka, Todd [off-list ref] wrote:
I don't see the reason this is needed so I'm going to say NAK.
Using generic functions is always better than open coded stuff.
Linux's ARRAY_SIZE also makes sure that the passed variable is actually an array.
--
Thanks,
//richard
From: Richard Weinberger <richard@nod.at> Date: 2015-06-30 20:24:30
Hi!
Am 30.06.2015 um 22:16 schrieb Fujinaka, Todd:
Sorry for the top-posting, but I'm provided with the tools they give me and bottom posting from Outlook just confuses email threads. Plus, this was crossposted all over creation and cc-ed to anyone with an intel address.
I still would say no if I'm allowed, because to guarantee that this change - that I don't think fixes anything - works in all cases, we need to do an incredible amount of regression testing. Every variant of every Intel part that uses this driver (and there are many) should be tested and will end up being used by the community.
Plus, you have no idea the number of obscure bugs I have to deal with as the guy answering customer questions. If this triggers some odd embedded compiler bug, I'm going to have to dig it out. Unless there is an actual bug, I'd like to leave it as it is.
If you don't dare to touch your driver please update it's maintenance status.
"Supported" is definitely not the case, maybe "Odd fixes" would fit better.
Thanks,
//richard
From: Alex Gartrell <hidden> Date: 2015-06-30 20:38:49
On Tue, Jun 30, 2015 at 1:16 PM, Fujinaka, Todd [off-list ref] wrote:
I still would say no if I'm allowed, because to guarantee that this change - that I don't think fixes anything - works in all cases, we need to do an incredible amount of regression testing. Every variant of every Intel part that uses this driver (and there are many) should be tested and will end up being used by the community.
Validation is really simple: diff old_module.ko new_module.ko
And this is a good defensive measure, as it'll save you when someone
screws up and changes your array to a pointer to an array (you'll get
a build failure instead of 0).
--
Alex Gartrell [off-list ref]
From: Joe Perches <joe@perches.com> Date: 2015-06-30 20:52:45
On Tue, 2015-06-30 at 20:16 +0000, Fujinaka, Todd wrote:
Sorry for the top-posting, but I'm provided with the tools they give me
and bottom posting from Outlook just confuses email threads. Plus, this
was crossposted all over creation and cc-ed to anyone with an intel
address.
Not quite. It was posted to the names listed under the
MAINTAINERS entry.
INTEL ETHERNET DRIVERS
M: Jeff Kirsher [off-list ref]
R: Jesse Brandeburg [off-list ref]
R: Shannon Nelson [off-list ref]
R: Carolyn Wyborny [off-list ref]
R: Don Skidmore [off-list ref]
R: Matthew Vick [off-list ref]
R: John Ronciak [off-list ref]
R: Mitch Williams [off-list ref]
L: intel-wired-lan@lists.osuosl.org
btw: You aren't listed there Todd. Should you be?
I still would say no if I'm allowed, because to guarantee that this
change - that I don't think fixes anything
Simplicity for the reader is generally a good thing.
Removing the macros altogether is likely better.
- works in all cases, we
need to do an incredible amount of regression testing.
Compilers should not produce different object code.
Verification of no object changes should be good enough.
Every variant of
every Intel part that uses this driver (and there are many) should be
tested and will end up being used by the community.
Plus, you have no idea the number of obscure bugs I have to deal with
as the guy answering customer questions. If this triggers some odd
embedded compiler bug, I'm going to have to dig it out. Unless there is
an actual bug, I'd like to leave it as it is.
If any compiler miscompiles the ARRAY_SIZE macro, there are bound to
be real issues with using that compiler in a production environment.
I've submitted a version to intel-wired-lan that addresses the original issue as well as Joe Perches's suggestion to just delete the define.
Todd Fujinaka
Software Application Engineer
Networking Division (ND)
Intel Corporation
todd.fujinaka@intel.com
(503) 712-4565