[PATCH] cifs-utils: mention the required kernel version to make cifs.idmap work

[PATCH] cifs-utils: mention the required kernel version to make cifs.idmap work

[Suresh Jayaraman]

.. properly in the "NOTES" section.

Cc: Shirish Pargaonkar <shirishpargaonkar-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Signed-off-by: Suresh Jayaraman <sjayaraman-l3A5Bk7waGM@public.gmane.org>
---
 cifs.idmap.8.in |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/cifs.idmap.8.in b/cifs.idmap.8.in
index f2fa3b2..7adfdc6 100644
--- a/cifs.idmap.8.in
+++ b/cifs.idmap.8.in
@@ -76,6 +76,9 @@ create      cifs\&.idmap     * * @sbindir@/cifs\&.idmap %k
 See
 \fBrequest-key.conf\fR(5)
 for more info on each field\&.
+.SH "NOTES"
+.PP
+For cifs.idmap to work properly you would need a kernel version 3.0 or above.
 .SH "SEE ALSO"
 .PP
 

Re: [PATCH] cifs-utils: mention the required kernel version to make cifs.idmap work

[Jeff Layton]

On Mon, 17 Oct 2011 17:33:47 +0530
Suresh Jayaraman <sjayaraman-l3A5Bk7waGM@public.gmane.org> wrote:

> .. properly in the "NOTES" section.
> 
> Cc: Shirish Pargaonkar <shirishpargaonkar-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> Signed-off-by: Suresh Jayaraman <sjayaraman-l3A5Bk7waGM@public.gmane.org>
> ---
>  cifs.idmap.8.in |    3 +++
>  1 files changed, 3 insertions(+), 0 deletions(-)
> 
> diff --git a/cifs.idmap.8.in b/cifs.idmap.8.in
> index f2fa3b2..7adfdc6 100644
> --- a/cifs.idmap.8.in
> +++ b/cifs.idmap.8.in
> @@ -76,6 +76,9 @@ create      cifs\&.idmap     * * @sbindir@/cifs\&.idmap %k
>  See
>  \fBrequest-key.conf\fR(5)
>  for more info on each field\&.
> +.SH "NOTES"
> +.PP
> +For cifs.idmap to work properly you would need a kernel version 3.0 or above.
>  .SH "SEE ALSO"
>  .PP
>  

This looks reasonable, but I'm always a bit leery of calling out
specific versions like this. Some distros (e.g. Red Hat's and Novell's)
will backport features from later kernels, so saying you need a 3.0
kernel might be confusing.

We might want to rephrase this with something like "Support for upcalls
to cifs.idmap was initially introduced in the 3.0 kernel." It's a
little more weaselly but it isn't false if someone is working with a
kernel that has backported this code.

Sound reasonable?
-- 
Jeff Layton <jlayton-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>

Re: [PATCH] cifs-utils: mention the required kernel version to make cifs.idmap work

[Suresh Jayaraman]

On 10/17/2011 05:41 PM, Jeff Layton wrote:
> On Mon, 17 Oct 2011 17:33:47 +0530
> Suresh Jayaraman <sjayaraman-l3A5Bk7waGM@public.gmane.org> wrote:
> 
>> .. properly in the "NOTES" section.
>>
>> Cc: Shirish Pargaonkar <shirishpargaonkar-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>> Signed-off-by: Suresh Jayaraman <sjayaraman-l3A5Bk7waGM@public.gmane.org>
>> ---
>>  cifs.idmap.8.in |    3 +++
>>  1 files changed, 3 insertions(+), 0 deletions(-)
>>
>> diff --git a/cifs.idmap.8.in b/cifs.idmap.8.in
>> index f2fa3b2..7adfdc6 100644
>> --- a/cifs.idmap.8.in
>> +++ b/cifs.idmap.8.in
>> @@ -76,6 +76,9 @@ create      cifs\&.idmap     * * @sbindir@/cifs\&.idmap %k
>>  See
>>  \fBrequest-key.conf\fR(5)
>>  for more info on each field\&.
>> +.SH "NOTES"
>> +.PP
>> +For cifs.idmap to work properly you would need a kernel version 3.0 or above.
>>  .SH "SEE ALSO"
>>  .PP
>>  
> 
> This looks reasonable, but I'm always a bit leery of calling out
> specific versions like this. Some distros (e.g. Red Hat's and Novell's)
> will backport features from later kernels, so saying you need a 3.0
> kernel might be confusing.
> 
> We might want to rephrase this with something like "Support for upcalls
> to cifs.idmap was initially introduced in the 3.0 kernel." It's a
> little more weaselly but it isn't false if someone is working with a
> kernel that has backported this code.
> 
> Sound reasonable?

Yes. Also, I'd like to get Shirish Ack (just to be sure) before this one
gets merged.

I'll repost it.


Suresh

Re: [PATCH] cifs-utils: mention the required kernel version to make cifs.idmap work

[Steve French]

On Mon, Oct 17, 2011 at 7:11 AM, Jeff Layton <jlayton-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
> On Mon, 17 Oct 2011 17:33:47 +0530
> Suresh Jayaraman <sjayaraman-l3A5Bk7waGM@public.gmane.org> wrote:
>
>> .. properly in the "NOTES" section.
>>
>> Cc: Shirish Pargaonkar <shirishpargaonkar-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>> Signed-off-by: Suresh Jayaraman <sjayaraman-l3A5Bk7waGM@public.gmane.org>
>> ---
>>  cifs.idmap.8.in |    3 +++
>>  1 files changed, 3 insertions(+), 0 deletions(-)
>>
>> diff --git a/cifs.idmap.8.in b/cifs.idmap.8.in
>> index f2fa3b2..7adfdc6 100644
>> --- a/cifs.idmap.8.in
>> +++ b/cifs.idmap.8.in
>> @@ -76,6 +76,9 @@ create      cifs\&.idmap     * * @sbindir@/cifs\&.idmap %k
>>  See
>>  \fBrequest-key.conf\fR(5)
>>  for more info on each field\&.
>> +.SH "NOTES"
>> +.PP
>> +For cifs.idmap to work properly you would need a kernel version 3.0 or above.
>>  .SH "SEE ALSO"
>>  .PP
>>
>
> This looks reasonable, but I'm always a bit leery of calling out
> specific versions like this. Some distros (e.g. Red Hat's and Novell's)
> will backport features from later kernels, so saying you need a 3.0
> kernel might be confusing.
>
> We might want to rephrase this with something like "Support for upcalls
> to cifs.idmap was initially introduced in the 3.0 kernel." It's a
> little more weaselly but it isn't false if someone is working with a
> kernel that has backported this code.
>
> Sound reasonable?

Yes - also to supplement this data can use the cifs version (displayed
by modinfo) - presumably with wholesale backport of cifs code the
version number could be updated as well.

> Jeff Layton <jlayton-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-cifs" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>



-- 
Thanks,

Steve

Re: [PATCH] cifs-utils: mention the required kernel version to make cifs.idmap work

[Jeff Layton]

On Mon, 17 Oct 2011 11:59:20 -0500
Steve French <smfrench-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:

> On Mon, Oct 17, 2011 at 7:11 AM, Jeff Layton <jlayton-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
> > On Mon, 17 Oct 2011 17:33:47 +0530
> > Suresh Jayaraman <sjayaraman-l3A5Bk7waGM@public.gmane.org> wrote:
> >
> >> .. properly in the "NOTES" section.
> >>
> >> Cc: Shirish Pargaonkar <shirishpargaonkar-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> >> Signed-off-by: Suresh Jayaraman <sjayaraman-l3A5Bk7waGM@public.gmane.org>
> >> ---
> >>  cifs.idmap.8.in |    3 +++
> >>  1 files changed, 3 insertions(+), 0 deletions(-)
> >>
> >> diff --git a/cifs.idmap.8.in b/cifs.idmap.8.in
> >> index f2fa3b2..7adfdc6 100644
> >> --- a/cifs.idmap.8.in
> >> +++ b/cifs.idmap.8.in
> >> @@ -76,6 +76,9 @@ create      cifs\&.idmap     * * @sbindir@/cifs\&.idmap %k
> >>  See
> >>  \fBrequest-key.conf\fR(5)
> >>  for more info on each field\&.
> >> +.SH "NOTES"
> >> +.PP
> >> +For cifs.idmap to work properly you would need a kernel version 3.0 or above.
> >>  .SH "SEE ALSO"
> >>  .PP
> >>
> >
> > This looks reasonable, but I'm always a bit leery of calling out
> > specific versions like this. Some distros (e.g. Red Hat's and Novell's)
> > will backport features from later kernels, so saying you need a 3.0
> > kernel might be confusing.
> >
> > We might want to rephrase this with something like "Support for upcalls
> > to cifs.idmap was initially introduced in the 3.0 kernel." It's a
> > little more weaselly but it isn't false if someone is working with a
> > kernel that has backported this code.
> >
> > Sound reasonable?
> 
> Yes - also to supplement this data can use the cifs version (displayed
> by modinfo) - presumably with wholesale backport of cifs code the
> version number could be updated as well.
> 

Except that often, distros pick and choose what new features to
backport. FWIW, I typically I don't bother bumping the version number
in the kmod in RHEL since it's more or less meaningless...

-- 
Jeff Layton <jlayton-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>

Re: [PATCH] cifs-utils: mention the required kernel version to make cifs.idmap work

[Steve French]

On Mon, Oct 17, 2011 at 12:06 PM, Jeff Layton <jlayton-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
> On Mon, 17 Oct 2011 11:59:20 -0500
> Steve French <smfrench-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>
>> On Mon, Oct 17, 2011 at 7:11 AM, Jeff Layton <jlayton-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
>> > On Mon, 17 Oct 2011 17:33:47 +0530
>> > Suresh Jayaraman <sjayaraman-l3A5Bk7waGM@public.gmane.org> wrote:
>> >
>> >> .. properly in the "NOTES" section.
>> >>
>> >> Cc: Shirish Pargaonkar <shirishpargaonkar-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>> >> Signed-off-by: Suresh Jayaraman <sjayaraman-l3A5Bk7waGM@public.gmane.org>
>> >> ---
>> >>  cifs.idmap.8.in |    3 +++
>> >>  1 files changed, 3 insertions(+), 0 deletions(-)
>> >>
>> >> diff --git a/cifs.idmap.8.in b/cifs.idmap.8.in
>> >> index f2fa3b2..7adfdc6 100644
>> >> --- a/cifs.idmap.8.in
>> >> +++ b/cifs.idmap.8.in
>> >> @@ -76,6 +76,9 @@ create      cifs\&.idmap     * * @sbindir@/cifs\&.idmap %k
>> >>  See
>> >>  \fBrequest-key.conf\fR(5)
>> >>  for more info on each field\&.
>> >> +.SH "NOTES"
>> >> +.PP
>> >> +For cifs.idmap to work properly you would need a kernel version 3.0 or above.
>> >>  .SH "SEE ALSO"
>> >>  .PP
>> >>
>> >
>> > This looks reasonable, but I'm always a bit leery of calling out
>> > specific versions like this. Some distros (e.g. Red Hat's and Novell's)
>> > will backport features from later kernels, so saying you need a 3.0
>> > kernel might be confusing.
>> >
>> > We might want to rephrase this with something like "Support for upcalls
>> > to cifs.idmap was initially introduced in the 3.0 kernel." It's a
>> > little more weaselly but it isn't false if someone is working with a
>> > kernel that has backported this code.
>> >
>> > Sound reasonable?
>>
>> Yes - also to supplement this data can use the cifs version (displayed
>> by modinfo) - presumably with wholesale backport of cifs code the
>> version number could be updated as well.
>>
>
> Except that often, distros pick and choose what new features to
> backport. FWIW, I typically I don't bother bumping the version number
> in the kmod in RHEL since it's more or less meaningless...
if it is a selective backport I agree - I sometimes do whole module
backport (with minor fixups for kabi changes).



-- 
Thanks,

Steve

Re: [PATCH] cifs-utils: mention the required kernel version to make cifs.idmap work

[Suresh Jayaraman]

On 10/17/2011 10:36 PM, Jeff Layton wrote:
> On Mon, 17 Oct 2011 11:59:20 -0500
> Steve French <smfrench-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> 
>> On Mon, Oct 17, 2011 at 7:11 AM, Jeff Layton <jlayton-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
>>> On Mon, 17 Oct 2011 17:33:47 +0530
>>> Suresh Jayaraman <sjayaraman-l3A5Bk7waGM@public.gmane.org> wrote:
>>>
>>>> .. properly in the "NOTES" section.
>>>>
>>>> Cc: Shirish Pargaonkar <shirishpargaonkar-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>>>> Signed-off-by: Suresh Jayaraman <sjayaraman-l3A5Bk7waGM@public.gmane.org>
>>>> ---
>>>>  cifs.idmap.8.in |    3 +++
>>>>  1 files changed, 3 insertions(+), 0 deletions(-)
>>>>
>>>> diff --git a/cifs.idmap.8.in b/cifs.idmap.8.in
>>>> index f2fa3b2..7adfdc6 100644
>>>> --- a/cifs.idmap.8.in
>>>> +++ b/cifs.idmap.8.in
>>>> @@ -76,6 +76,9 @@ create      cifs\&.idmap     * * @sbindir@/cifs\&.idmap %k
>>>>  See
>>>>  \fBrequest-key.conf\fR(5)
>>>>  for more info on each field\&.
>>>> +.SH "NOTES"
>>>> +.PP
>>>> +For cifs.idmap to work properly you would need a kernel version 3.0 or above.
>>>>  .SH "SEE ALSO"
>>>>  .PP
>>>>
>>>
>>> This looks reasonable, but I'm always a bit leery of calling out
>>> specific versions like this. Some distros (e.g. Red Hat's and Novell's)
>>> will backport features from later kernels, so saying you need a 3.0
>>> kernel might be confusing.
>>>
>>> We might want to rephrase this with something like "Support for upcalls
>>> to cifs.idmap was initially introduced in the 3.0 kernel." It's a
>>> little more weaselly but it isn't false if someone is working with a
>>> kernel that has backported this code.
>>>
>>> Sound reasonable?
>>
>> Yes - also to supplement this data can use the cifs version (displayed
>> by modinfo) - presumably with wholesale backport of cifs code the
>> version number could be updated as well.
>>
> 
> Except that often, distros pick and choose what new features to
> backport. FWIW, I typically I don't bother bumping the version number
> in the kmod in RHEL since it's more or less meaningless...
> 

I too don't bump the version number in SLES unless I've to go for a full
backport.

Also, I noticed that we no longer document the major features/changes in
the CHANGES file w.r.t each module version (the last I see is 1.62). I
found that information sometimes useful for e.g. if you want to know
which features went in between two versions etc.

What do you think about keep the CHANGES file up-to-date? Would it be
useful?


Thanks
Suresh

Re: [PATCH] cifs-utils: mention the required kernel version to make cifs.idmap work

[Steve French]

Yes - I agree we should bring changes file up to date.

Patches welcome :)

(and also review of any of Pavel's smb2 patches would be great,
starting from the beginning would be good - I have gone through these,
especially the parts that hit existing cifs files and looks better
shape than I expected and I am pleased, or review 4 remaining lock
patches also would be a big help)

On Tue, Oct 18, 2011 at 1:07 AM, Suresh Jayaraman <sjayaraman-l3A5Bk7waGM@public.gmane.org> wrote:
> On 10/17/2011 10:36 PM, Jeff Layton wrote:
>> On Mon, 17 Oct 2011 11:59:20 -0500
>> Steve French <smfrench-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>>
>>> On Mon, Oct 17, 2011 at 7:11 AM, Jeff Layton <jlayton-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
>>>> On Mon, 17 Oct 2011 17:33:47 +0530
>>>> Suresh Jayaraman <sjayaraman-l3A5Bk7waGM@public.gmane.org> wrote:
>>>>
>>>>> .. properly in the "NOTES" section.
>>>>>
>>>>> Cc: Shirish Pargaonkar <shirishpargaonkar-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>>>>> Signed-off-by: Suresh Jayaraman <sjayaraman-l3A5Bk7waGM@public.gmane.org>
>>>>> ---
>>>>>  cifs.idmap.8.in |    3 +++
>>>>>  1 files changed, 3 insertions(+), 0 deletions(-)
>>>>>
>>>>> diff --git a/cifs.idmap.8.in b/cifs.idmap.8.in
>>>>> index f2fa3b2..7adfdc6 100644
>>>>> --- a/cifs.idmap.8.in
>>>>> +++ b/cifs.idmap.8.in
>>>>> @@ -76,6 +76,9 @@ create      cifs\&.idmap     * * @sbindir@/cifs\&.idmap %k
>>>>>  See
>>>>>  \fBrequest-key.conf\fR(5)
>>>>>  for more info on each field\&.
>>>>> +.SH "NOTES"
>>>>> +.PP
>>>>> +For cifs.idmap to work properly you would need a kernel version 3.0 or above.
>>>>>  .SH "SEE ALSO"
>>>>>  .PP
>>>>>
>>>>
>>>> This looks reasonable, but I'm always a bit leery of calling out
>>>> specific versions like this. Some distros (e.g. Red Hat's and Novell's)
>>>> will backport features from later kernels, so saying you need a 3.0
>>>> kernel might be confusing.
>>>>
>>>> We might want to rephrase this with something like "Support for upcalls
>>>> to cifs.idmap was initially introduced in the 3.0 kernel." It's a
>>>> little more weaselly but it isn't false if someone is working with a
>>>> kernel that has backported this code.
>>>>
>>>> Sound reasonable?
>>>
>>> Yes - also to supplement this data can use the cifs version (displayed
>>> by modinfo) - presumably with wholesale backport of cifs code the
>>> version number could be updated as well.
>>>
>>
>> Except that often, distros pick and choose what new features to
>> backport. FWIW, I typically I don't bother bumping the version number
>> in the kmod in RHEL since it's more or less meaningless...
>>
>
> I too don't bump the version number in SLES unless I've to go for a full
> backport.
>
> Also, I noticed that we no longer document the major features/changes in
> the CHANGES file w.r.t each module version (the last I see is 1.62). I
> found that information sometimes useful for e.g. if you want to know
> which features went in between two versions etc.
>
> What do you think about keep the CHANGES file up-to-date? Would it be
> useful?
>
>
> Thanks
> Suresh
>



-- 
Thanks,

Steve