Hi,
Rusty Russell wrote:
> > 1) we do not prevent root from shooting themselves in the foot,
>
> I don't understand this point.
Something to remember here: When we kill processes with SIGKILL, do we
risk kernel stability? E.g. do we turn TASK_UNINTERRUPTIBLE into
TASK_INTERRUPTIBLE, do we allow to kill init or do we leave resources
behind?
> > 3) and this kind of code just adds error handling for no reason, when
> > _not_ handling the error keeps the code more clean.
>
> No, the reason is simple: the admin has said they want the damn module
> removed. They've *told* you what they want. Why do you want to
> disobey them? 8)
How do you want to make this mechanism halfway safe to use? Did you
check that all modules can still be deconfigured after you put them into
the going state via the wait option?
Both the wait and the force option are extremely dangerous options. You
are trying to implement something behind the modules back, what can only
go wrong as soon as the module becomes slightly more complex. If you
want to force the removal of a module, you should least attempt to keep
it safe and this is not possible without the help of the module. A
global don't-use switch is a worse idea than the global module count, if
it's forced onto the modules.
I'm really curious when we get the first bug reports from people, who
"only" unloaded a module. :(
bye, Roman
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed Jan 15 2003 - 22:00:47 EST