From mboxrd@z Thu Jan 1 00:00:00 1970 From: Suresh Jayaraman Subject: Re: [PATCH] cifs-utils: mention the required kernel version to make cifs.idmap work Date: Tue, 18 Oct 2011 11:37:38 +0530 Message-ID: <4E9D17AA.8020407@suse.de> References: <4E9C19A3.8010009@suse.de> <20111017081139.564089db@tlielax.poochiereds.net> <20111017130654.53fd42c4@corrin.poochiereds.net> Reply-To: sjayaraman-l3A5Bk7waGM@public.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: linux-cifs , Shirish Pargaonkar To: Jeff Layton , Steve French Return-path: In-Reply-To: <20111017130654.53fd42c4-4QP7MXygkU+dMjc06nkz3ljfA9RmPOcC@public.gmane.org> Sender: linux-cifs-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-ID: On 10/17/2011 10:36 PM, Jeff Layton wrote: > On Mon, 17 Oct 2011 11:59:20 -0500 > Steve French wrote: > >> On Mon, Oct 17, 2011 at 7:11 AM, Jeff Layton wrote: >>> On Mon, 17 Oct 2011 17:33:47 +0530 >>> Suresh Jayaraman wrote: >>> >>>> .. properly in the "NOTES" section. >>>> >>>> Cc: Shirish Pargaonkar >>>> Signed-off-by: Suresh Jayaraman >>>> --- >>>> 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