[illumos-Developer] [PATCH] modload: Unload modules by name

Alexey Zaytsev alexey.zaytsev at gmail.com
Thu May 26 16:45:52 PDT 2011


On Fri, May 27, 2011 at 03:14, Albert Lee <trisk at opensolaris.org> wrote:
> On Thu, May 26, 2011 at 5:57 PM, Alexey Zaytsev
> <alexey.zaytsev at gmail.com> wrote:
>> Signed-off-by: Alexey Zaytsev <alexey.zaytsev at gmail.com>
>> ---
>>
>> Hi.
>>
>> I've seen all new nexenta people submit their first patches into
>> illumos pretty quick, so to solidify this tradition, here's one from me.
>>
>> It lets you unload modules by name, as simple as
>>
>> modunload vioif virtio
>>
>> And yes, it takes multiple modules, and you can actually even add one more
>> by using the -i option. The dependencies are not tracked, so you should pass
>> inter-dependent modules in the right order.
>>
>> I did not rebuild the whole tree, but the code passed both cstyle and lint checks,
>> and seems to work fine.
>>
>
> The advocates do try to request a full build when possible for an RTI,
> although you don't have to do that until you're satisfied with the
> review feedback.

Thanks for the feedback!

If Garrett would insist on it, I'll do the build, even if I'm not
convinced that a formal approach is the best here.
In my opinion, I should clean-build anything that's used by some other
components, but it seems to be pointless in case of a stand-alone
component.


> <snip>
>
> Why replace fatal() and error() with fprintf(stderr)?

Because more then one module might be unloaded. So we skip the ones
that can't be unloaded and try the rest.
Modunload still exits when the exec_file fails.

> (As an aside,
> webrev or some form other than inline diff would make it easier on
> reviewers, so we don't need to pull up the unmodified files for
> reference, and can quote line numbers. I was going to add inline
> comments, but it quickly became hard to read).

What about just quoting parts of the patch? I don't have a strong
opinion regarding webrev, just trying to keep it simple for simple
patches.



More information about the Developer mailing list