On Mon, 17 Oct 2011 11:59:20 -0500
Steve French <[email protected]> wrote:

> On Mon, Oct 17, 2011 at 7:11 AM, Jeff Layton <[email protected]> wrote:
> > On Mon, 17 Oct 2011 17:33:47 +0530
> > Suresh Jayaraman <[email protected]> wrote:
> >
> >> .. properly in the "NOTES" section.
> >>
> >> Cc: Shirish Pargaonkar <[email protected]>
> >> Signed-off-by: Suresh Jayaraman <[email protected]>
> >> ---
> >>  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 <[email protected]>
--
To unsubscribe from this list: send the line "unsubscribe linux-cifs" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to