From: Rik van Riel <riel@redhat.com>
To: Dan Carpenter <dan.carpenter@oracle.com>,
Guenter Roeck <linux@roeck-us.net>
Cc: ksummit-discuss@lists.linux-foundation.org
Subject: Re: [Ksummit-discuss] No more module removal -- Unconference track
Date: Tue, 19 Aug 2014 12:59:18 -0400 [thread overview]
Message-ID: <53F38266.90809@redhat.com> (raw)
In-Reply-To: <20140819160917.GF5423@mwanda>
On 08/19/2014 12:09 PM, Dan Carpenter wrote:
> On Tue, Aug 19, 2014 at 08:47:38AM -0700, Guenter Roeck wrote:
>> On Tue, Aug 19, 2014 at 06:40:29PM +0300, Dan Carpenter wrote:
>>> Why can't we just taint the kernel on module removal?
>>>
>> Why not just fix its bugs ?
>>
>> If you want to taint the kernel on module removal because it is known that many
>> drivers have bugs in their removal code, you should taint the kernel if any code
>> is used which is known to have a bug. Or, in other words, just taint the kernel,
>> period.
>
> If you rmmod a module it probably means that your code was buggy before
> you started the rmmod.
Not necessarily.
I often rmmod the kvm module (and then load a new one) to
test performance enhancements.
For tracing, tools like systemtap insert kernel modules
to trace kernel code, and will remove them again when
the tracing script exits.
next prev parent reply other threads:[~2014-08-19 16:59 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-19 14:48 Theodore Ts'o
2014-08-19 14:55 ` Guenter Roeck
2014-08-19 15:23 ` Theodore Ts'o
2014-08-19 15:40 ` Dan Carpenter
2014-08-19 15:47 ` Guenter Roeck
2014-08-19 16:09 ` Dan Carpenter
2014-08-19 16:34 ` Martin K. Petersen
2014-08-19 16:59 ` Rik van Riel [this message]
2014-08-19 17:19 ` Guenter Roeck
2014-08-19 16:43 ` David Woodhouse
2014-08-19 17:13 ` Grant Likely
2014-08-19 17:23 ` David Woodhouse
2014-08-19 15:54 ` Takashi Iwai
2014-08-25 11:01 ` Masami Hiramatsu
2014-08-25 11:05 ` Jiri Kosina
2014-08-26 5:24 ` Masami Hiramatsu
2014-08-27 23:05 ` Theodore Ts'o
2014-08-26 21:39 ` David Howells
2014-08-26 21:45 ` Jiri Kosina
2014-08-27 6:43 ` Masami Hiramatsu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=53F38266.90809@redhat.com \
--to=riel@redhat.com \
--cc=dan.carpenter@oracle.com \
--cc=ksummit-discuss@lists.linux-foundation.org \
--cc=linux@roeck-us.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox