Re: [Request for review] Revised delete_module(2) manual page
Lucas, On Wed, Oct 24, 2012 at 7:27 AM, Lucas De Marchi wrote: > Hi Michael, > > > On Sun, Oct 21, 2012 at 5:36 AM, Michael Kerrisk (man-pages) > wrote: >> Ping! >> >> Rusty (et al.) I'm pretty sure the new page text is okay, but I would >> like someone knowledgeable to confirm. > > One more thing: > >> .SH "SEE ALSO" >> .BR create_module (2), >> .BR init_module (2), >> .BR query_module (2), >> .BR lsmod (8), >> .BR rmmod (8) > > Shouldn't we remove the reference to query_module(2) and > create_module(2)? They don't exist anymore (and I miss a bigger > warning on their man pages). I think the SEE ALSO links should be kept, but you are right that the warnings that query_module(2) and create_module(2) no longer exist should be more prominent on those pages. By chance, I'd already made that change. > Last, I think there should be a ref here to modprobe (because of -r > flag), not lsmod. The rest looks good. I'll add modprobe(8); I think lsmod(8) is worth keeping. Cheers, Michael -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Author of "The Linux Programming Interface"; http://man7.org/tlpi/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Request for review] Revised delete_module(2) manual page
"Michael Kerrisk (man-pages)" writes: > Ping! > > Rusty (et al.) I'm pretty sure the new page text is okay, but I would > like someone knowledgeable to confirm. Yes, sorry, I did read it, and had nothing to add. Ack, Rusty. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Request for review] Revised delete_module(2) manual page
Michael Kerrisk (man-pages) mtk.manpa...@gmail.com writes: Ping! Rusty (et al.) I'm pretty sure the new page text is okay, but I would like someone knowledgeable to confirm. Yes, sorry, I did read it, and had nothing to add. Ack, Rusty. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Request for review] Revised delete_module(2) manual page
Lucas, On Wed, Oct 24, 2012 at 7:27 AM, Lucas De Marchi lucas.de.mar...@gmail.com wrote: Hi Michael, On Sun, Oct 21, 2012 at 5:36 AM, Michael Kerrisk (man-pages) mtk.manpa...@gmail.com wrote: Ping! Rusty (et al.) I'm pretty sure the new page text is okay, but I would like someone knowledgeable to confirm. One more thing: .SH SEE ALSO .BR create_module (2), .BR init_module (2), .BR query_module (2), .BR lsmod (8), .BR rmmod (8) Shouldn't we remove the reference to query_module(2) and create_module(2)? They don't exist anymore (and I miss a bigger warning on their man pages). I think the SEE ALSO links should be kept, but you are right that the warnings that query_module(2) and create_module(2) no longer exist should be more prominent on those pages. By chance, I'd already made that change. Last, I think there should be a ref here to modprobe (because of -r flag), not lsmod. The rest looks good. I'll add modprobe(8); I think lsmod(8) is worth keeping. Cheers, Michael -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Author of The Linux Programming Interface; http://man7.org/tlpi/ -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Request for review] Revised delete_module(2) manual page
Hi Michael, On Sun, Oct 21, 2012 at 5:36 AM, Michael Kerrisk (man-pages) wrote: > Ping! > > Rusty (et al.) I'm pretty sure the new page text is okay, but I would > like someone knowledgeable to confirm. One more thing: > .SH "SEE ALSO" > .BR create_module (2), > .BR init_module (2), > .BR query_module (2), > .BR lsmod (8), > .BR rmmod (8) Shouldn't we remove the reference to query_module(2) and create_module(2)? They don't exist anymore (and I miss a bigger warning on their man pages). Last, I think there should be a ref here to modprobe (because of -r flag), not lsmod. The rest looks good. Lucas De Marchi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Request for review] Revised delete_module(2) manual page
Hi Michael, On Sun, Oct 21, 2012 at 5:36 AM, Michael Kerrisk (man-pages) mtk.manpa...@gmail.com wrote: Ping! Rusty (et al.) I'm pretty sure the new page text is okay, but I would like someone knowledgeable to confirm. One more thing: .SH SEE ALSO .BR create_module (2), .BR init_module (2), .BR query_module (2), .BR lsmod (8), .BR rmmod (8) Shouldn't we remove the reference to query_module(2) and create_module(2)? They don't exist anymore (and I miss a bigger warning on their man pages). Last, I think there should be a ref here to modprobe (because of -r flag), not lsmod. The rest looks good. Lucas De Marchi -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Request for review] Revised delete_module(2) manual page
Ping! Rusty (et al.) I'm pretty sure the new page text is okay, but I would like someone knowledgeable to confirm. Thanks, Michael -- Forwarded message -- From: Michael Kerrisk (man-pages) Date: Fri, Oct 12, 2012 at 10:47 AM Subject: Re: [Request for review] Revised delete_module(2) manual page Hi Rusty, Thanks for taking a look at this page. In the light of your comments, I've substantially reworked the page, and further review would not go amiss, in case I made a misstep along the way. On Thu, Oct 11, 2012 at 5:02 AM, Rusty Russell wrote: > "Michael Kerrisk (man-pages)" writes: > >> Hello Kees, Rusty, >> >> The current delete_module(2) page is severely out of date (basically, >> its content corresponds to 2.4 days, and was even pretty thin in >> covering that). So, I took a shot at revising the page to Linux 2.6+ >> reality. Would it be possible that you could review it? > > OK. Main suggestion is that I discussed with Lucas removing the > !O_NONBLOCK case. It's not supported by modprobe -r, and almost > unheard-of for rmmod (it's --wait). > > In practice, people want the unload-or-fail semantics, or the > force-unload semantics. Okay -- I've substantially reworked the page to reflect these idea. >> Otherwise, by default, >> .BR delete_module () >> marks a module so that no new references are permitted. >> If the module's reference count >> (i.e., the number of processes currently using the module) is nonzero, >> it then places the caller in an uninterruptible sleep >> state until all reference count is zero, >> at which point the call unblocks. >> When the reference count reaches zero, the module is unloaded. > > So this should be inverted: > > Otherwise (assuming O_NONBLOCK, see flags below), if the > module's reference count (i.e., the number of processes > currently using the module) is nonzero, the call fails. Got it. See my reworked text. [...] > NOTES: > > If O_NONBLOCK is not set, then the kernel may enter uninterruptible > sleep until the module reference count reaches zero. This is not > generally desirable, so this flag may be compulsory in future kernel > configurations. I've added some text under NOTES. Okay, below (and attached) is the new version of the page. Let me know of any concerns. Cheers, Michael .\" Copyright (C) 2012 Michael Kerrisk .\" .\" Permission is granted to make and distribute verbatim copies of this .\" manual provided the copyright notice and this permission notice are .\" preserved on all copies. .\" .\" Permission is granted to copy and distribute modified versions of this .\" manual under the conditions for verbatim copying, provided that the .\" entire resulting derived work is distributed under the terms of a .\" permission notice identical to this one. .\" .\" Since the Linux kernel and libraries are constantly changing, this .\" manual page may be incorrect or out-of-date. The author(s) assume no .\" responsibility for errors or omissions, or for damages resulting from .\" the use of the information contained herein. The author(s) may not .\" have taken the same level of care in the production of this manual, .\" which is licensed free of charge, as they might when working .\" professionally. .\" .\" Formatted or processed versions of this manual, if unaccompanied by .\" the source, must acknowledge the copyright and authors of this work. .\" .TH DELETE_MODULE 2 2012-10-12 "Linux" "Linux Programmer's Manual" .SH NAME delete_module \- unload a kernel module .SH SYNOPSIS .nf .BI "int delete_module(const char *" name ", int " flags ); .fi .IR Note : There is no glibc wrapper for this system call; see NOTES. .SH DESCRIPTION The .BR delete_module () system call attempts to remove the unused loadable module entry identified by .IR name . If the module has an .I exit function, then that function is executed before unloading the module. The .IR flags argument is used to modify the behavior of the system call, as described below. This system call requires privilege. Module removal is attempted according to the following rules: .IP 1. 4 If there are other loaded modules that depend on (i.e., refer to symbols defined in) this module, then the call fails. .IP 2. Otherwise, if the reference count for the module (i.e., the number of processes currently using the module) is zero, then the module is immediately unloaded. .IP 3. If a module has a nonzero reference count, then the behavior depends on the bits set in .IR flags . In normal usage (see NOTES), the .BR O_NONBLOCK flag is always specified, and the .BR O_TRUNC flag may additionally be specified. .\" O_TRUNC == KMOD_REMOVE_FORCE i
Re: [Request for review] Revised delete_module(2) manual page
Ping! Rusty (et al.) I'm pretty sure the new page text is okay, but I would like someone knowledgeable to confirm. Thanks, Michael -- Forwarded message -- From: Michael Kerrisk (man-pages) mtk.manpa...@gmail.com Date: Fri, Oct 12, 2012 at 10:47 AM Subject: Re: [Request for review] Revised delete_module(2) manual page Hi Rusty, Thanks for taking a look at this page. In the light of your comments, I've substantially reworked the page, and further review would not go amiss, in case I made a misstep along the way. On Thu, Oct 11, 2012 at 5:02 AM, Rusty Russell ru...@rustcorp.com.au wrote: Michael Kerrisk (man-pages) mtk.manpa...@gmail.com writes: Hello Kees, Rusty, The current delete_module(2) page is severely out of date (basically, its content corresponds to 2.4 days, and was even pretty thin in covering that). So, I took a shot at revising the page to Linux 2.6+ reality. Would it be possible that you could review it? OK. Main suggestion is that I discussed with Lucas removing the !O_NONBLOCK case. It's not supported by modprobe -r, and almost unheard-of for rmmod (it's --wait). In practice, people want the unload-or-fail semantics, or the force-unload semantics. Okay -- I've substantially reworked the page to reflect these idea. Otherwise, by default, .BR delete_module () marks a module so that no new references are permitted. If the module's reference count (i.e., the number of processes currently using the module) is nonzero, it then places the caller in an uninterruptible sleep state until all reference count is zero, at which point the call unblocks. When the reference count reaches zero, the module is unloaded. So this should be inverted: Otherwise (assuming O_NONBLOCK, see flags below), if the module's reference count (i.e., the number of processes currently using the module) is nonzero, the call fails. Got it. See my reworked text. [...] NOTES: If O_NONBLOCK is not set, then the kernel may enter uninterruptible sleep until the module reference count reaches zero. This is not generally desirable, so this flag may be compulsory in future kernel configurations. I've added some text under NOTES. Okay, below (and attached) is the new version of the page. Let me know of any concerns. Cheers, Michael .\ Copyright (C) 2012 Michael Kerrisk mtk.manpa...@gmail.com .\ .\ Permission is granted to make and distribute verbatim copies of this .\ manual provided the copyright notice and this permission notice are .\ preserved on all copies. .\ .\ Permission is granted to copy and distribute modified versions of this .\ manual under the conditions for verbatim copying, provided that the .\ entire resulting derived work is distributed under the terms of a .\ permission notice identical to this one. .\ .\ Since the Linux kernel and libraries are constantly changing, this .\ manual page may be incorrect or out-of-date. The author(s) assume no .\ responsibility for errors or omissions, or for damages resulting from .\ the use of the information contained herein. The author(s) may not .\ have taken the same level of care in the production of this manual, .\ which is licensed free of charge, as they might when working .\ professionally. .\ .\ Formatted or processed versions of this manual, if unaccompanied by .\ the source, must acknowledge the copyright and authors of this work. .\ .TH DELETE_MODULE 2 2012-10-12 Linux Linux Programmer's Manual .SH NAME delete_module \- unload a kernel module .SH SYNOPSIS .nf .BI int delete_module(const char * name , int flags ); .fi .IR Note : There is no glibc wrapper for this system call; see NOTES. .SH DESCRIPTION The .BR delete_module () system call attempts to remove the unused loadable module entry identified by .IR name . If the module has an .I exit function, then that function is executed before unloading the module. The .IR flags argument is used to modify the behavior of the system call, as described below. This system call requires privilege. Module removal is attempted according to the following rules: .IP 1. 4 If there are other loaded modules that depend on (i.e., refer to symbols defined in) this module, then the call fails. .IP 2. Otherwise, if the reference count for the module (i.e., the number of processes currently using the module) is zero, then the module is immediately unloaded. .IP 3. If a module has a nonzero reference count, then the behavior depends on the bits set in .IR flags . In normal usage (see NOTES), the .BR O_NONBLOCK flag is always specified, and the .BR O_TRUNC flag may additionally be specified. .\ O_TRUNC == KMOD_REMOVE_FORCE in kmod library .\ O_NONBLOCK == KMOD_REMOVE_NOWAIT in kmod library The various combinations for .I flags have the following effect: .RS 4 .TP .B flags == O_NONBLOCK The call returns immediately, with an error. .TP .B flags == (O_NONBLOCK | O_TRUNC) The module is unloaded immediately, regardless of whether it has
Re: [Request for review] Revised delete_module(2) manual page
Hi Rusty, Thanks for taking a look at this page. In the light of your comments, I've substantially reworked the page, and further review would not go amiss, in case I made a misstep along the way. On Thu, Oct 11, 2012 at 5:02 AM, Rusty Russell wrote: > "Michael Kerrisk (man-pages)" writes: > >> Hello Kees, Rusty, >> >> The current delete_module(2) page is severely out of date (basically, >> its content corresponds to 2.4 days, and was even pretty thin in >> covering that). So, I took a shot at revising the page to Linux 2.6+ >> reality. Would it be possible that you could review it? > > OK. Main suggestion is that I discussed with Lucas removing the > !O_NONBLOCK case. It's not supported by modprobe -r, and almost > unheard-of for rmmod (it's --wait). > > In practice, people want the unload-or-fail semantics, or the > force-unload semantics. Okay -- I've substantially reworked the page to reflect these idea. >> Otherwise, by default, >> .BR delete_module () >> marks a module so that no new references are permitted. >> If the module's reference count >> (i.e., the number of processes currently using the module) is nonzero, >> it then places the caller in an uninterruptible sleep >> state until all reference count is zero, >> at which point the call unblocks. >> When the reference count reaches zero, the module is unloaded. > > So this should be inverted: > > Otherwise (assuming O_NONBLOCK, see flags below), if the > module's reference count (i.e., the number of processes > currently using the module) is nonzero, the call fails. Got it. See my reworked text. [...] > NOTES: > > If O_NONBLOCK is not set, then the kernel may enter uninterruptible > sleep until the module reference count reaches zero. This is not > generally desirable, so this flag may be compulsory in future kernel > configurations. I've added some text under NOTES. Okay, below (and attached) is the new version of the page. Let me know of any concerns. Cheers, Michael .\" Copyright (C) 2012 Michael Kerrisk .\" .\" Permission is granted to make and distribute verbatim copies of this .\" manual provided the copyright notice and this permission notice are .\" preserved on all copies. .\" .\" Permission is granted to copy and distribute modified versions of this .\" manual under the conditions for verbatim copying, provided that the .\" entire resulting derived work is distributed under the terms of a .\" permission notice identical to this one. .\" .\" Since the Linux kernel and libraries are constantly changing, this .\" manual page may be incorrect or out-of-date. The author(s) assume no .\" responsibility for errors or omissions, or for damages resulting from .\" the use of the information contained herein. The author(s) may not .\" have taken the same level of care in the production of this manual, .\" which is licensed free of charge, as they might when working .\" professionally. .\" .\" Formatted or processed versions of this manual, if unaccompanied by .\" the source, must acknowledge the copyright and authors of this work. .\" .TH DELETE_MODULE 2 2012-10-12 "Linux" "Linux Programmer's Manual" .SH NAME delete_module \- unload a kernel module .SH SYNOPSIS .nf .BI "int delete_module(const char *" name ", int " flags ); .fi .IR Note : There is no glibc wrapper for this system call; see NOTES. .SH DESCRIPTION The .BR delete_module () system call attempts to remove the unused loadable module entry identified by .IR name . If the module has an .I exit function, then that function is executed before unloading the module. The .IR flags argument is used to modify the behavior of the system call, as described below. This system call requires privilege. Module removal is attempted according to the following rules: .IP 1. 4 If there are other loaded modules that depend on (i.e., refer to symbols defined in) this module, then the call fails. .IP 2. Otherwise, if the reference count for the module (i.e., the number of processes currently using the module) is zero, then the module is immediately unloaded. .IP 3. If a module has a nonzero reference count, then the behavior depends on the bits set in .IR flags . In normal usage (see NOTES), the .BR O_NONBLOCK flag is always specified, and the .BR O_TRUNC flag may additionally be specified. .\" O_TRUNC == KMOD_REMOVE_FORCE in kmod library .\" O_NONBLOCK == KMOD_REMOVE_NOWAIT in kmod library The various combinations for .I flags have the following effect: .RS 4 .TP .B flags == O_NONBLOCK The call returns immediately, with an error. .TP .B flags == (O_NONBLOCK | O_TRUNC) The module is unloaded immediately, regardless of whether it has a nonzero reference count. .TP .B flags == 0 If .I flags does not specify .BR O_NONBLOCK , the following steps occur: .RS .IP * 3 The module is marked so that no new references are permitted. .IP * If the module's reference count is nonzero, the caller is placed in an uninterruptible sleep state .RB ( TASK_UNINTERRUPTIBLE
Re: [Request for review] Revised delete_module(2) manual page
Hi Rusty, Thanks for taking a look at this page. In the light of your comments, I've substantially reworked the page, and further review would not go amiss, in case I made a misstep along the way. On Thu, Oct 11, 2012 at 5:02 AM, Rusty Russell ru...@rustcorp.com.au wrote: Michael Kerrisk (man-pages) mtk.manpa...@gmail.com writes: Hello Kees, Rusty, The current delete_module(2) page is severely out of date (basically, its content corresponds to 2.4 days, and was even pretty thin in covering that). So, I took a shot at revising the page to Linux 2.6+ reality. Would it be possible that you could review it? OK. Main suggestion is that I discussed with Lucas removing the !O_NONBLOCK case. It's not supported by modprobe -r, and almost unheard-of for rmmod (it's --wait). In practice, people want the unload-or-fail semantics, or the force-unload semantics. Okay -- I've substantially reworked the page to reflect these idea. Otherwise, by default, .BR delete_module () marks a module so that no new references are permitted. If the module's reference count (i.e., the number of processes currently using the module) is nonzero, it then places the caller in an uninterruptible sleep state until all reference count is zero, at which point the call unblocks. When the reference count reaches zero, the module is unloaded. So this should be inverted: Otherwise (assuming O_NONBLOCK, see flags below), if the module's reference count (i.e., the number of processes currently using the module) is nonzero, the call fails. Got it. See my reworked text. [...] NOTES: If O_NONBLOCK is not set, then the kernel may enter uninterruptible sleep until the module reference count reaches zero. This is not generally desirable, so this flag may be compulsory in future kernel configurations. I've added some text under NOTES. Okay, below (and attached) is the new version of the page. Let me know of any concerns. Cheers, Michael .\ Copyright (C) 2012 Michael Kerrisk mtk.manpa...@gmail.com .\ .\ Permission is granted to make and distribute verbatim copies of this .\ manual provided the copyright notice and this permission notice are .\ preserved on all copies. .\ .\ Permission is granted to copy and distribute modified versions of this .\ manual under the conditions for verbatim copying, provided that the .\ entire resulting derived work is distributed under the terms of a .\ permission notice identical to this one. .\ .\ Since the Linux kernel and libraries are constantly changing, this .\ manual page may be incorrect or out-of-date. The author(s) assume no .\ responsibility for errors or omissions, or for damages resulting from .\ the use of the information contained herein. The author(s) may not .\ have taken the same level of care in the production of this manual, .\ which is licensed free of charge, as they might when working .\ professionally. .\ .\ Formatted or processed versions of this manual, if unaccompanied by .\ the source, must acknowledge the copyright and authors of this work. .\ .TH DELETE_MODULE 2 2012-10-12 Linux Linux Programmer's Manual .SH NAME delete_module \- unload a kernel module .SH SYNOPSIS .nf .BI int delete_module(const char * name , int flags ); .fi .IR Note : There is no glibc wrapper for this system call; see NOTES. .SH DESCRIPTION The .BR delete_module () system call attempts to remove the unused loadable module entry identified by .IR name . If the module has an .I exit function, then that function is executed before unloading the module. The .IR flags argument is used to modify the behavior of the system call, as described below. This system call requires privilege. Module removal is attempted according to the following rules: .IP 1. 4 If there are other loaded modules that depend on (i.e., refer to symbols defined in) this module, then the call fails. .IP 2. Otherwise, if the reference count for the module (i.e., the number of processes currently using the module) is zero, then the module is immediately unloaded. .IP 3. If a module has a nonzero reference count, then the behavior depends on the bits set in .IR flags . In normal usage (see NOTES), the .BR O_NONBLOCK flag is always specified, and the .BR O_TRUNC flag may additionally be specified. .\ O_TRUNC == KMOD_REMOVE_FORCE in kmod library .\ O_NONBLOCK == KMOD_REMOVE_NOWAIT in kmod library The various combinations for .I flags have the following effect: .RS 4 .TP .B flags == O_NONBLOCK The call returns immediately, with an error. .TP .B flags == (O_NONBLOCK | O_TRUNC) The module is unloaded immediately, regardless of whether it has a nonzero reference count. .TP .B flags == 0 If .I flags does not specify .BR O_NONBLOCK , the following steps occur: .RS .IP * 3 The module is marked so that no new references are permitted. .IP * If the module's reference count is nonzero, the caller is placed in an uninterruptible sleep state .RB ( TASK_UNINTERRUPTIBLE ) until the
Re: [Request for review] Revised delete_module(2) manual page
Lucas De Marchi writes: > What do you think? Mark as deprecated now and remove when kernel > removes it? Or remove now? Complain now, and I'll queue the removal in two merge windows. Thats gives us a chance just in case someone actually uses this; if so I want to talk to them about what it is they want! Thanks, Rusty. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Request for review] Revised delete_module(2) manual page
Hi, On Thu, Oct 11, 2012 at 12:02 AM, Rusty Russell wrote: > "Michael Kerrisk (man-pages)" writes: > >> Hello Kees, Rusty, >> >> The current delete_module(2) page is severely out of date (basically, >> its content corresponds to 2.4 days, and was even pretty thin in >> covering that). So, I took a shot at revising the page to Linux 2.6+ >> reality. Would it be possible that you could review it? > > OK. Main suggestion is that I discussed with Lucas removing the > !O_NONBLOCK case. It's not supported by modprobe -r, and almost > unheard-of for rmmod (it's --wait). > > In practice, people want the unload-or-fail semantics, or the > force-unload semantics. I'm all for removing this option. My idea was to complain loudly if user tries to use it: http://git.kernel.org/?p=utils/kernel/kmod/kmod.git;a=commit;h=8447b865aaac9139485dccdcc576725ddec2e7fa But maybe it's good to just remove it altogether > >> Otherwise, by default, >> .BR delete_module () >> marks a module so that no new references are permitted. >> If the module's reference count >> (i.e., the number of processes currently using the module) is nonzero, >> it then places the caller in an uninterruptible sleep >> state until all reference count is zero, >> at which point the call unblocks. >> When the reference count reaches zero, the module is unloaded. > > So this should be inverted: > > Otherwise (assuming O_NONBLOCK, see flags below), if the > module's reference count (i.e., the number of processes > currently using the module) is nonzero, the call fails. > >> The >> .IR flags >> argument can be used to modify the behavior of the system call. > > It is usually set to O_NONBLOCK, which may be required in future kernel > versions (see NOTES). > >> The following values can be ORed in this argument: >> .TP >> .B O_TRUNC >> .\" KMOD_REMOVE_FORCE in kmod library >> Force unloading of the module, even if the following conditions are true: >> .RS >> .IP * 3 >> The module has no >> .I exit >> function. >> By default, attempting to unload a module that has no >> .I exit >> function fails. >> .IP * >> The reference count for (i.e., the number of processes currently using) >> this module is nonzero. > ... >> .IP >> Using this flag taints the kernel (TAINT_FORCED_RMMOD). >> .IP >> .IR "Using this flag is dangerous!" >> If the kernel was not built with >> .BR CONFIG_MODULE_FORCE_UNLOAD , >> this flag is silently ignored. > > NOTES: > > If O_NONBLOCK is not set, then the kernel may enter uninterruptible > sleep until the module reference count reaches zero. This is not > generally desirable, so this flag may be compulsory in future kernel > configurations. What do you think? Mark as deprecated now and remove when kernel removes it? Or remove now? Lucas De Marchi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Request for review] Revised delete_module(2) manual page
Hi, On Thu, Oct 11, 2012 at 12:02 AM, Rusty Russell ru...@rustcorp.com.au wrote: Michael Kerrisk (man-pages) mtk.manpa...@gmail.com writes: Hello Kees, Rusty, The current delete_module(2) page is severely out of date (basically, its content corresponds to 2.4 days, and was even pretty thin in covering that). So, I took a shot at revising the page to Linux 2.6+ reality. Would it be possible that you could review it? OK. Main suggestion is that I discussed with Lucas removing the !O_NONBLOCK case. It's not supported by modprobe -r, and almost unheard-of for rmmod (it's --wait). In practice, people want the unload-or-fail semantics, or the force-unload semantics. I'm all for removing this option. My idea was to complain loudly if user tries to use it: http://git.kernel.org/?p=utils/kernel/kmod/kmod.git;a=commit;h=8447b865aaac9139485dccdcc576725ddec2e7fa But maybe it's good to just remove it altogether Otherwise, by default, .BR delete_module () marks a module so that no new references are permitted. If the module's reference count (i.e., the number of processes currently using the module) is nonzero, it then places the caller in an uninterruptible sleep state until all reference count is zero, at which point the call unblocks. When the reference count reaches zero, the module is unloaded. So this should be inverted: Otherwise (assuming O_NONBLOCK, see flags below), if the module's reference count (i.e., the number of processes currently using the module) is nonzero, the call fails. The .IR flags argument can be used to modify the behavior of the system call. It is usually set to O_NONBLOCK, which may be required in future kernel versions (see NOTES). The following values can be ORed in this argument: .TP .B O_TRUNC .\ KMOD_REMOVE_FORCE in kmod library Force unloading of the module, even if the following conditions are true: .RS .IP * 3 The module has no .I exit function. By default, attempting to unload a module that has no .I exit function fails. .IP * The reference count for (i.e., the number of processes currently using) this module is nonzero. ... .IP Using this flag taints the kernel (TAINT_FORCED_RMMOD). .IP .IR Using this flag is dangerous! If the kernel was not built with .BR CONFIG_MODULE_FORCE_UNLOAD , this flag is silently ignored. NOTES: If O_NONBLOCK is not set, then the kernel may enter uninterruptible sleep until the module reference count reaches zero. This is not generally desirable, so this flag may be compulsory in future kernel configurations. What do you think? Mark as deprecated now and remove when kernel removes it? Or remove now? Lucas De Marchi -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Request for review] Revised delete_module(2) manual page
Lucas De Marchi lucas.demar...@profusion.mobi writes: What do you think? Mark as deprecated now and remove when kernel removes it? Or remove now? Complain now, and I'll queue the removal in two merge windows. Thats gives us a chance just in case someone actually uses this; if so I want to talk to them about what it is they want! Thanks, Rusty. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Request for review] Revised delete_module(2) manual page
"Michael Kerrisk (man-pages)" writes: > Hello Kees, Rusty, > > The current delete_module(2) page is severely out of date (basically, > its content corresponds to 2.4 days, and was even pretty thin in > covering that). So, I took a shot at revising the page to Linux 2.6+ > reality. Would it be possible that you could review it? OK. Main suggestion is that I discussed with Lucas removing the !O_NONBLOCK case. It's not supported by modprobe -r, and almost unheard-of for rmmod (it's --wait). In practice, people want the unload-or-fail semantics, or the force-unload semantics. > Otherwise, by default, > .BR delete_module () > marks a module so that no new references are permitted. > If the module's reference count > (i.e., the number of processes currently using the module) is nonzero, > it then places the caller in an uninterruptible sleep > state until all reference count is zero, > at which point the call unblocks. > When the reference count reaches zero, the module is unloaded. So this should be inverted: Otherwise (assuming O_NONBLOCK, see flags below), if the module's reference count (i.e., the number of processes currently using the module) is nonzero, the call fails. > The > .IR flags > argument can be used to modify the behavior of the system call. It is usually set to O_NONBLOCK, which may be required in future kernel versions (see NOTES). > The following values can be ORed in this argument: > .TP > .B O_TRUNC > .\" KMOD_REMOVE_FORCE in kmod library > Force unloading of the module, even if the following conditions are true: > .RS > .IP * 3 > The module has no > .I exit > function. > By default, attempting to unload a module that has no > .I exit > function fails. > .IP * > The reference count for (i.e., the number of processes currently using) > this module is nonzero. ... > .IP > Using this flag taints the kernel (TAINT_FORCED_RMMOD). > .IP > .IR "Using this flag is dangerous!" > If the kernel was not built with > .BR CONFIG_MODULE_FORCE_UNLOAD , > this flag is silently ignored. NOTES: If O_NONBLOCK is not set, then the kernel may enter uninterruptible sleep until the module reference count reaches zero. This is not generally desirable, so this flag may be compulsory in future kernel configurations. Cheers, Rusty. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Request for review] Revised delete_module(2) manual page
Michael Kerrisk (man-pages) mtk.manpa...@gmail.com writes: Hello Kees, Rusty, The current delete_module(2) page is severely out of date (basically, its content corresponds to 2.4 days, and was even pretty thin in covering that). So, I took a shot at revising the page to Linux 2.6+ reality. Would it be possible that you could review it? OK. Main suggestion is that I discussed with Lucas removing the !O_NONBLOCK case. It's not supported by modprobe -r, and almost unheard-of for rmmod (it's --wait). In practice, people want the unload-or-fail semantics, or the force-unload semantics. Otherwise, by default, .BR delete_module () marks a module so that no new references are permitted. If the module's reference count (i.e., the number of processes currently using the module) is nonzero, it then places the caller in an uninterruptible sleep state until all reference count is zero, at which point the call unblocks. When the reference count reaches zero, the module is unloaded. So this should be inverted: Otherwise (assuming O_NONBLOCK, see flags below), if the module's reference count (i.e., the number of processes currently using the module) is nonzero, the call fails. The .IR flags argument can be used to modify the behavior of the system call. It is usually set to O_NONBLOCK, which may be required in future kernel versions (see NOTES). The following values can be ORed in this argument: .TP .B O_TRUNC .\ KMOD_REMOVE_FORCE in kmod library Force unloading of the module, even if the following conditions are true: .RS .IP * 3 The module has no .I exit function. By default, attempting to unload a module that has no .I exit function fails. .IP * The reference count for (i.e., the number of processes currently using) this module is nonzero. ... .IP Using this flag taints the kernel (TAINT_FORCED_RMMOD). .IP .IR Using this flag is dangerous! If the kernel was not built with .BR CONFIG_MODULE_FORCE_UNLOAD , this flag is silently ignored. NOTES: If O_NONBLOCK is not set, then the kernel may enter uninterruptible sleep until the module reference count reaches zero. This is not generally desirable, so this flag may be compulsory in future kernel configurations. Cheers, Rusty. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
