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@xxxxxxx> wrote: > On 10/17/2011 10:36 PM, Jeff Layton wrote: >> On Mon, 17 Oct 2011 11:59:20 -0500 >> Steve French <smfrench@xxxxxxxxx> wrote: >> >>> On Mon, Oct 17, 2011 at 7:11 AM, Jeff Layton <jlayton@xxxxxxxxxx> wrote: >>>> On Mon, 17 Oct 2011 17:33:47 +0530 >>>> Suresh Jayaraman <sjayaraman@xxxxxxx> wrote: >>>> >>>>> .. properly in the "NOTES" section. >>>>> >>>>> Cc: Shirish Pargaonkar <shirishpargaonkar@xxxxxxxxx> >>>>> Signed-off-by: Suresh Jayaraman <sjayaraman@xxxxxxx> >>>>> --- >>>>> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-cifs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
