Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1288953 > unrolled thread

Re: [PATCHv4 1/1] SCSI: hosts: update to use ida_simple for host_no management

Started byLee Duncan <lduncan@suse.com>
First post2015-12-10 22:50 +0100
Last post2015-12-17 20:30 +0100
Articles 7 — 4 participants

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  Re: [PATCHv4 1/1] SCSI: hosts: update to use ida_simple for host_no  management Lee Duncan <lduncan@suse.com> - 2015-12-10 22:50 +0100
    Re: [PATCHv4 1/1] SCSI: hosts: update to use ida_simple for  host_no management Ewan Milne <emilne@redhat.com> - 2015-12-11 16:40 +0100
      Re: [PATCHv4 1/1] SCSI: hosts: update to use ida_simple for host_no  management Lee Duncan <lduncan@suse.com> - 2015-12-13 20:20 +0100
        Re: [PATCHv4 1/1] SCSI: hosts: update to use ida_simple for  host_no management Ewan Milne <emilne@redhat.com> - 2015-12-14 16:10 +0100
          Re: [PATCHv4 1/1] SCSI: hosts: update to use ida_simple for host_no  management Hannes Reinecke <hare@suse.de> - 2015-12-14 16:30 +0100
            Re: [PATCHv4 1/1] SCSI: hosts: update to use ida_simple for host_no management "Martin K. Petersen" <martin.petersen@oracle.com> - 2015-12-15 03:00 +0100
              Re: [PATCHv4 1/1] SCSI: hosts: update to use ida_simple for host_no  management Lee Duncan <lduncan@suse.com> - 2015-12-17 20:30 +0100

#1288953 — Re: [PATCHv4 1/1] SCSI: hosts: update to use ida_simple for host_no management

FromLee Duncan <lduncan@suse.com>
Date2015-12-10 22:50 +0100
SubjectRe: [PATCHv4 1/1] SCSI: hosts: update to use ida_simple for host_no management
Message-ID<qEhg6-3j4-19@gated-at.bofh.it>
On 11/17/2015 03:20 PM, Martin K. Petersen wrote:
>>>>>> "Lee" == Lee Duncan <lduncan@suse.com> writes:
> 
> Lee> Martin: I will be glad to update the patch, creating a modprobe
> Lee> parameter as suggested, if you find this acceptable.
> 
> For development use a module parameter would be fine. But I am concerned
> about our support folks that rely on the incrementing host number when
> analyzing customer log files.
> 
> Ewan: How do you folks feel about this change?
> 

Ewan?

-- 
Lee Duncan

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

[toc] | [next] | [standalone]


#1289689 — Re: [PATCHv4 1/1] SCSI: hosts: update to use ida_simple for host_no management

FromEwan Milne <emilne@redhat.com>
Date2015-12-11 16:40 +0100
SubjectRe: [PATCHv4 1/1] SCSI: hosts: update to use ida_simple for host_no management
Message-ID<qExXA-6lB-25@gated-at.bofh.it>
In reply to#1288953
On Thu, 2015-12-10 at 13:48 -0800, Lee Duncan wrote:
> On 11/17/2015 03:20 PM, Martin K. Petersen wrote:
> >>>>>> "Lee" == Lee Duncan <lduncan@suse.com> writes:
> > 
> > Lee> Martin: I will be glad to update the patch, creating a modprobe
> > Lee> parameter as suggested, if you find this acceptable.
> > 
> > For development use a module parameter would be fine. But I am concerned
> > about our support folks that rely on the incrementing host number when
> > analyzing customer log files.
> > 
> > Ewan: How do you folks feel about this change?
> > 
> 
> Ewan?


Personally, I think having host numbers that increase essentially
without limit (I think I've seen this with iSCSI sessions) are a
problem, the numbers start to lose meaning for people when they
are not easily recognizable.  Yes, it can help when you're analyzing
a log file, but it seems to me that you would want to track the
host state throughout anyway, so you could just follow the number
as it changes.

If we change the behavior, we have to change documentation, and
our support people will get calls.  But that's not a reason not
to do it.

-Ewan


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

[toc] | [prev] | [next] | [standalone]


#1290677

FromLee Duncan <lduncan@suse.com>
Date2015-12-13 20:20 +0100
Message-ID<qFklz-3Zf-1@gated-at.bofh.it>
In reply to#1289689
On 12/11/2015 07:31 AM, Ewan Milne wrote:
> On Thu, 2015-12-10 at 13:48 -0800, Lee Duncan wrote:
>> On 11/17/2015 03:20 PM, Martin K. Petersen wrote:
>>>>>>>> "Lee" == Lee Duncan <lduncan@suse.com> writes:
>>>
>>> Lee> Martin: I will be glad to update the patch, creating a modprobe
>>> Lee> parameter as suggested, if you find this acceptable.
>>>
>>> For development use a module parameter would be fine. But I am concerned
>>> about our support folks that rely on the incrementing host number when
>>> analyzing customer log files.
>>>
>>> Ewan: How do you folks feel about this change?
>>>
>>
>> Ewan?
> 
> 
> Personally, I think having host numbers that increase essentially
> without limit (I think I've seen this with iSCSI sessions) are a
> problem, the numbers start to lose meaning for people when they
> are not easily recognizable.  Yes, it can help when you're analyzing
> a log file, but it seems to me that you would want to track the
> host state throughout anyway, so you could just follow the number
> as it changes.
> 
> If we change the behavior, we have to change documentation, and
> our support people will get calls.  But that's not a reason not
> to do it.
> 
> -Ewan
> 

Ewan:

Thank you for your reply. I agree with you, which is why I generated
this patch.

If we *do* make this change, do you think it would be useful to have a
module option to revert to the old numbering behavior? I actually think
it would be more confusing to support two behaviors than it would be to
bite the bullet (so to speak) and make the change.

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

[toc] | [prev] | [next] | [standalone]


#1291251 — Re: [PATCHv4 1/1] SCSI: hosts: update to use ida_simple for host_no management

FromEwan Milne <emilne@redhat.com>
Date2015-12-14 16:10 +0100
SubjectRe: [PATCHv4 1/1] SCSI: hosts: update to use ida_simple for host_no management
Message-ID<qFCVb-7NZ-11@gated-at.bofh.it>
In reply to#1290677
On Sun, 2015-12-13 at 11:16 -0800, Lee Duncan wrote:
> On 12/11/2015 07:31 AM, Ewan Milne wrote:
> > On Thu, 2015-12-10 at 13:48 -0800, Lee Duncan wrote:
> >> On 11/17/2015 03:20 PM, Martin K. Petersen wrote:
> >>>>>>>> "Lee" == Lee Duncan <lduncan@suse.com> writes:
> >>>
> >>> Lee> Martin: I will be glad to update the patch, creating a modprobe
> >>> Lee> parameter as suggested, if you find this acceptable.
> >>>
> >>> For development use a module parameter would be fine. But I am concerned
> >>> about our support folks that rely on the incrementing host number when
> >>> analyzing customer log files.
> >>>
> >>> Ewan: How do you folks feel about this change?
> >>>
> >>
> >> Ewan?
> > 
> > 
> > Personally, I think having host numbers that increase essentially
> > without limit (I think I've seen this with iSCSI sessions) are a
> > problem, the numbers start to lose meaning for people when they
> > are not easily recognizable.  Yes, it can help when you're analyzing
> > a log file, but it seems to me that you would want to track the
> > host state throughout anyway, so you could just follow the number
> > as it changes.
> > 
> > If we change the behavior, we have to change documentation, and
> > our support people will get calls.  But that's not a reason not
> > to do it.
> > 
> > -Ewan
> > 
> 
> Ewan:
> 
> Thank you for your reply. I agree with you, which is why I generated
> this patch.
> 
> If we *do* make this change, do you think it would be useful to have a
> module option to revert to the old numbering behavior? I actually think
> it would be more confusing to support two behaviors than it would be to
> bite the bullet (so to speak) and make the change.
> 

I'm not opposed to having the module option if others (Martin?) feel
they need it, but generally I think it's better to keep things as simple
as possible.  So, unless there are strong objections, I would say no.

-Ewan



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

[toc] | [prev] | [next] | [standalone]


#1291276

FromHannes Reinecke <hare@suse.de>
Date2015-12-14 16:30 +0100
Message-ID<qFDey-7Vd-21@gated-at.bofh.it>
In reply to#1291251
On 12/14/2015 04:07 PM, Ewan Milne wrote:
> On Sun, 2015-12-13 at 11:16 -0800, Lee Duncan wrote:
>> On 12/11/2015 07:31 AM, Ewan Milne wrote:
>>> On Thu, 2015-12-10 at 13:48 -0800, Lee Duncan wrote:
>>>> On 11/17/2015 03:20 PM, Martin K. Petersen wrote:
>>>>>>>>>> "Lee" == Lee Duncan <lduncan@suse.com> writes:
>>>>>
>>>>> Lee> Martin: I will be glad to update the patch, creating a modprobe
>>>>> Lee> parameter as suggested, if you find this acceptable.
>>>>>
>>>>> For development use a module parameter would be fine. But I am concerned
>>>>> about our support folks that rely on the incrementing host number when
>>>>> analyzing customer log files.
>>>>>
>>>>> Ewan: How do you folks feel about this change?
>>>>>
>>>>
>>>> Ewan?
>>>
>>>
>>> Personally, I think having host numbers that increase essentially
>>> without limit (I think I've seen this with iSCSI sessions) are a
>>> problem, the numbers start to lose meaning for people when they
>>> are not easily recognizable.  Yes, it can help when you're analyzing
>>> a log file, but it seems to me that you would want to track the
>>> host state throughout anyway, so you could just follow the number
>>> as it changes.
>>>
>>> If we change the behavior, we have to change documentation, and
>>> our support people will get calls.  But that's not a reason not
>>> to do it.
>>>
>>> -Ewan
>>>
>>
>> Ewan:
>>
>> Thank you for your reply. I agree with you, which is why I generated
>> this patch.
>>
>> If we *do* make this change, do you think it would be useful to have a
>> module option to revert to the old numbering behavior? I actually think
>> it would be more confusing to support two behaviors than it would be to
>> bite the bullet (so to speak) and make the change.
>>
>
> I'm not opposed to having the module option if others (Martin?) feel
> they need it, but generally I think it's better to keep things as simple
> as possible.  So, unless there are strong objections, I would say no.
>
Agreeing with Ewan here.

Martin, I guess it's up to you to tell us whether you absolutely 
need a module parameter ...

Cheers,

Hannes
-- 
Dr. Hannes Reinecke		               zSeries & Storage
hare@suse.de			               +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]


#1291767 — Re: [PATCHv4 1/1] SCSI: hosts: update to use ida_simple for host_no management

From"Martin K. Petersen" <martin.petersen@oracle.com>
Date2015-12-15 03:00 +0100
SubjectRe: [PATCHv4 1/1] SCSI: hosts: update to use ida_simple for host_no management
Message-ID<qFN4d-5Oz-5@gated-at.bofh.it>
In reply to#1291276
>>>>> "Hannes" == Hannes Reinecke <hare@suse.de> writes:

>> I'm not opposed to having the module option if others (Martin?) feel
>> they need it, but generally I think it's better to keep things as
>> simple as possible.  So, unless there are strong objections, I would
>> say no.

Hannes> Agreeing with Ewan here.

Hannes> I guess it's up to you to tell us whether you absolutely need a
Hannes> module parameter ...

Still not a big ida fan but since the most people seem to be in favor of
this I guess I'll have to bite the bullet.

I don't see much value in the module parameter since it will require
customers to tweak their configs and reproduce. Not worth the hassle.

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

[toc] | [prev] | [next] | [standalone]


#1294165

FromLee Duncan <lduncan@suse.com>
Date2015-12-17 20:30 +0100
Message-ID<qGMps-3Er-11@gated-at.bofh.it>
In reply to#1291767
On 12/14/2015 05:55 PM, Martin K. Petersen wrote:
>>>>>> "Hannes" == Hannes Reinecke <hare@suse.de> writes:
> 
>>> I'm not opposed to having the module option if others (Martin?) feel
>>> they need it, but generally I think it's better to keep things as
>>> simple as possible.  So, unless there are strong objections, I would
>>> say no.
> 
> Hannes> Agreeing with Ewan here.
> 
> Hannes> I guess it's up to you to tell us whether you absolutely need a
> Hannes> module parameter ...
> 
> Still not a big ida fan but since the most people seem to be in favor of
> this I guess I'll have to bite the bullet.
> 
> I don't see much value in the module parameter since it will require
> customers to tweak their configs and reproduce. Not worth the hassle.
> 

Thank you Martin. I'll look at further cleaning up the host module, but
I think this still much better than leaving the code as is.

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

[toc] | [prev] | [standalone]


Back to top | Article view | linux.kernel


csiph-web