cifs-utils: mention the required kernel version to make cifs.idmap work
Subsystems (2)
PATCH 1/1 cifs-utils: mention the required kernel version to make cifs.idmap work
.. properly in the "NOTES" section.
--- cifs.idmap.8.in | 3 +++ 1 files changed, 3 insertions(+), 0 deletions(-)
cifs.idmap.8.in +3 -0
@@ -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
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 13 lines · On Mon, 17 Oct 2011 17:33:47 +0530 Suresh Jayaraman…
.. 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(-)cifs.idmap.8.in +0
-0
cifs.idmap.8.in create cifs\&.idmap * * @sbindir@/cifs\&.idmap %k · line 84
Quoted 9 lines
cifs.idmap.8.in +3
-0@@ -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?
Signature · 1 line
Jeff Layton <[email protected]>
A message that is not in the archive (sent off-list or not yet received): 20111017081139.564089db-9yPaYZwiELC+kQycOl6kW4xkIHaj4LzF@public.gmane.org
Quoted 31 lines · Jeff Layton
Quoted 13 lines · On Mon, 17 Oct 2011 17:33:47 +0530 Suresh Jayaraman…
.. 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(-)cifs.idmap.8.in +0
-0cifs.idmap.8.in create cifs\&.idmap * * @sbindir@/cifs\&.idmap %k · line 84
Quoted 9 lines
cifs.idmap.8.in +3
-0@@ -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" .PPThis 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.
Quoted 6 lines
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
Quoted 31 lines · Jeff Layton
Quoted 13 lines · On Mon, 17 Oct 2011 17:33:47 +0530 Suresh Jayaraman…
.. 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(-)cifs.idmap.8.in +0
-0@@ -76,6 +76,9 @@ create cifs\&.idmap * * @sbindir@/cifs\&.idmap %kQuoted 9 lines
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"
.PPThis 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.
Quoted 6 lines
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.
Quoted 6 lines
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
Signature · 3 lines
Thanks, Steve
A message that is not in the archive (sent off-list or not yet received): CAH2r5msxArv-Hdy6sBVGbNtLcjhwk0EUwGj07H85iOT4KHqiRg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org
Quoted 37 lines · On Mon, 17 Oct 2011 11:59:20 -0500 Steve French…
Quoted 36 lines · Jeff Layton
Quoted 13 lines · On Mon, 17 Oct 2011 17:33:47 +0530 Suresh Jayaraman…
.. 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(-)cifs.idmap.8.in +0
-0@@ -76,6 +76,9 @@ create cifs\&.idmap * * @sbindir@/cifs\&.idmap %kQuoted 9 lines
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"
.PPThis 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.
Quoted 6 lines
Quoted 1 line
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...
Signature · 1 line
Jeff Layton <[email protected]>
A message that is not in the archive (sent off-list or not yet received): 20111017130654.53fd42c4-4QP7MXygkU+dMjc06nkz3ljfA9RmPOcC@public.gmane.org
Quoted 42 lines · Jeff Layton
Quoted 39 lines · On Mon, 17 Oct 2011 11:59:20 -0500 Steve French…
Quoted 37 lines · Jeff Layton
Quoted 13 lines · On Mon, 17 Oct 2011 17:33:47 +0530 Suresh Jayaraman…
.. 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(-)cifs.idmap.8.in +0
-0@@ -76,6 +76,9 @@ create cifs\&.idmap * * @sbindir@/cifs\&.idmap %kQuoted 9 lines
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"
.PPThis 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?
Quoted 8 lines
Quoted 4 lines
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).
Signature · 3 lines
Thanks, Steve
Quoted 42 lines · Jeff Layton
Quoted 39 lines · On Mon, 17 Oct 2011 11:59:20 -0500 Steve French…
Quoted 37 lines · Jeff Layton
Quoted 13 lines · On Mon, 17 Oct 2011 17:33:47 +0530 Suresh Jayaraman…
.. 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(-)cifs.idmap.8.in +0
-0cifs.idmap.8.in create cifs\&.idmap * * @sbindir@/cifs\&.idmap %k · line 84
Quoted 9 lines
cifs.idmap.8.in +3
-0@@ -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" .PPThis 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?
Quoted 9 lines
Quoted 4 lines
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
A message that is not in the archive (sent off-list or not yet received): [email protected]
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)
Quoted 68 lines · Suresh Jayaraman
Quoted 42 lines · Jeff Layton
Quoted 39 lines · On Mon, 17 Oct 2011 11:59:20 -0500 Steve French…
Quoted 37 lines · Jeff Layton
Quoted 13 lines · On Mon, 17 Oct 2011 17:33:47 +0530 Suresh Jayaraman…
.. 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(-)cifs.idmap.8.in +0
-0@@ -76,6 +76,9 @@ create cifs\&.idmap * * @sbindir@/cifs\&.idmap %kQuoted 9 lines
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"
.PPThis 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?
Quoted 9 lines
Quoted 4 lines
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
Signature · 3 lines
Thanks, Steve