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

[Suresh Jayaraman <sjayaraman-l3A5Bk7waGM@public.gmane.org>]

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