This patch fixes the display of a few fields in the iBFT NIC attribute
structure in sysfs.
Signed-off-by: Ashutosh Naik <[email protected]>
Signed-off-by: Vishnu V<[email protected]>
On Saturday 11 April 2009 09:29:36 Ashutosh Naik wrote:
> This patch fixes the display of a few fields in the iBFT NIC attribute
> structure in sysfs.
>
> Signed-off-by: Ashutosh Naik <[email protected]>
> Signed-off-by: Vishnu V<[email protected]>
Thanks for finding such glaring copy-n-paste error.
Acked-off-by:Konrad Rzeszutek <[email protected]>
On Sat, 2009-04-11 at 18:59 +0530, Ashutosh Naik wrote:
> This patch fixes the display of a few fields in the iBFT NIC attribute
> structure in sysfs.
>
> Signed-off-by: Ashutosh Naik <[email protected]>
> Signed-off-by: Vishnu V<[email protected]>
What do these signoffs mean? Traditionally you sign off on a patch if
it passed through your hands, so if this is a patch from Vishnu which
you're sending in, they need to be in reverse order (and a From: for
Vishnu).
The second question is who picks this up? The drivers/firmware
directory doesn't seem to have a dedicated tree, so I can take this
through the SCSI tree if required or Andrew can take it through -mm.
James
On Sat, Apr 11, 2009 at 11:26 PM, James Bottomley
<[email protected]> wrote:
> What do these signoffs mean?
I am reattaching the patch here:
Description:This patch fixes the display of a few fields in the iBFT
NIC attribute
structure in sysfs.
Signed-off-by: Ashutosh Naik <[email protected]>
Cc: Vishnu V<[email protected]>
> The second question is who picks this up? ?The drivers/firmware
> directory doesn't seem to have a dedicated tree, so I can take this
> through the SCSI tree if required or Andrew can take it through -mm.
This is used for display of the various structures of the iBFT table
via sysfs and can be picked up by any iSCSI initiator driver module
that uses the information in the iBFT table to boot over iSCSI, such
as open-iscsi.
> The second question is who picks this up? The drivers/firmware
> directory doesn't seem to have a dedicated tree, so I can take this
> through the SCSI tree if required or Andrew can take it through -mm.
Which way works best for everybody? I was thinking SCSI, since the end result
of this module is to configure the storage used to bootstrap the box.
On Sun, 12 Apr 2009 09:06:59 -0400
Konrad Rzeszutek <[email protected]> wrote:
> > The second question is who picks this up? The drivers/firmware
> > directory doesn't seem to have a dedicated tree, so I can take this
> > through the SCSI tree if required or Andrew can take it through -mm.
>
> Which way works best for everybody? I was thinking SCSI, since the end result
> of this module is to configure the storage used to bootstrap the box.
I can merge merge it later this week.
However...
: From: Ashutosh Naik <[email protected]>
:
: Fix the display of a few fields in the iBFT NIC attribute structure in
: sysfs.
:
: Signed-off-by: Ashutosh Naik <[email protected]>
: Cc: Vishnu V <[email protected]>
: Signed-off-by: Andrew Morton <[email protected]>
: ---
:
: drivers/firmware/iscsi_ibft.c | 4 ++--
: 1 file changed, 2 insertions(+), 2 deletions(-)
:
: diff -puN drivers/firmware/iscsi_ibft.c~ibft-fix-the-display-of-a-few-fields-in-the-nic-attribute-structure-in-sysfs drivers/firmware/iscsi_ibft.c
: --- a/drivers/firmware/iscsi_ibft.c~ibft-fix-the-display-of-a-few-fields-in-the-nic-attribute-structure-in-sysfs
: +++ a/drivers/firmware/iscsi_ibft.c
: @@ -754,11 +754,11 @@ static int __init ibft_check_nic_for(str
: rc = 1;
: break;
: case ibft_eth_ip_addr:
: - if (!memcmp(nic->dhcp, nulls, sizeof(nic->dhcp)))
: + if (memcmp(nic->ip_addr, nulls, sizeof(nic->ip_addr)))
: rc = 1;
: break;
: case ibft_eth_subnet_mask:
: - if (!memcmp(nic->dhcp, nulls, sizeof(nic->dhcp)))
: + if (nic->subnet_mask_prefix)
: rc = 1;
: break;
: case ibft_eth_origin:
The changelog is bad.
What does "fix" mean? What does the old output look like and how does
this patch change it?
This matters, because this is a userspace interface and who knows, there
might be applications out there which somehow depend on the old and
broken behaviour.
Of course, that might be totally silly and unrealistic but because we
weren't told what the patch actually does, how can I tell?
Please send a new and complete description of this change, thanks.
On Thu, Apr 16, 2009 at 3:07 AM, Andrew Morton
<[email protected]> wrote:
> On Sun, 12 Apr 2009 09:06:59 -0400
> Konrad Rzeszutek <[email protected]> wrote:
>
>> > The second question is who picks this up? ?The drivers/firmware
>> > directory doesn't seem to have a dedicated tree, so I can take this
>> > through the SCSI tree if required or Andrew can take it through -mm.
>>
>> Which way works best for everybody? I was thinking SCSI, since the end result
>> of this module is to configure the storage used to bootstrap the box.
>
> I can merge merge it later this week.
>
> However...
>
>
> : From: Ashutosh Naik <[email protected]>
> :
> : Fix the display of a few fields in the iBFT NIC attribute structure in
> : sysfs.
<snip>
> The changelog is bad.
>
> What does "fix" mean? ?What does the old output look like and how does
> this patch change it?
>
> This matters, because this is a userspace interface and who knows, there
> might be applications out there which somehow depend on the old and
> broken behaviour.
>
> Of course, that might be totally silly and unrealistic but because we
> weren't told what the patch actually does, how can I tell?
>
> Please send a new and complete description of this change, thanks.
Sorry for the delay.
Here is an updated Changelog
The patch ensures that, if the DHCP IP address and the subnet mask for
the interface is present in the iBFT NIC structure, the corresponding
entries are created in sysfs tree for the device. This would hence
create the additional entries in the tree based on the iBFT table and
would not delete any existing entries.
Thanks.
On Thu, Apr 16, 2009 at 3:07 AM, Andrew Morton
<[email protected]> wrote:
> On Sun, 12 Apr 2009 09:06:59 -0400
> Konrad Rzeszutek <[email protected]> wrote:
>
>> > The second question is who picks this up? ?The drivers/firmware
>> > directory doesn't seem to have a dedicated tree, so I can take this
>> > through the SCSI tree if required or Andrew can take it through -mm.
>>
>> Which way works best for everybody? I was thinking SCSI, since the end result
>> of this module is to configure the storage used to bootstrap the box.
>
> I can merge merge it later this week.
>
> However...
>
>
> : From: Ashutosh Naik <[email protected]>
> :
> : Fix the display of a few fields in the iBFT NIC attribute structure in
> : sysfs.
<snip>
> The changelog is bad.
>
> What does "fix" mean? ?What does the old output look like and how does
> this patch change it?
>
> This matters, because this is a userspace interface and who knows, there
> might be applications out there which somehow depend on the old and
> broken behaviour.
>
> Of course, that might be totally silly and unrealistic but because we
> weren't told what the patch actually does, how can I tell?
>
> Please send a new and complete description of this change, thanks.
Sorry for the delay.
Here is an updated Changelog
The patch ensures that on, if the DHCP