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

[Garrett D'Amore]

We need a full nightly build so we can see logs from lint, etc.  Also even seemingly simple fixes can cause issues in packaging or dependencies.   I realize this is very unlikely in this case, but the full build should not take that long, and its just machine time, not developer time.

  -- Garrett D'Amore

On May 27, 2011, at 3:45 AM, Alexey Zaytsev <alexey.zaytsev at gmail.com> wrote:

> 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.
> 
> _______________________________________________
> Developer mailing list
> Developer at lists.illumos.org
> http://lists.illumos.org/m/listinfo/developer