In message <Pine.LNX.4.44.0211131430190.2109-100000@serv> you write:
> Hi,
>
> On Wed, 13 Nov 2002, Rusty Russell wrote:
>
> > Feedback appreciated. It's aimed at driver writers.
>
> If that's your audience, I expect a very confused audience.
>From my feedback, I suspect you are right. I've rewritten it.
> You can make it very simple: There are safe interfaces and there are
> broken interfaces and you shall never write or use broken interfaces.
> For the majority of driver writers that's good enough.
Yes, maybe I should.
> Any documentation about module writing should also include/point to a
> chapter about resource management.
Yes, it'd be nice to have good documentation on this.
> As soon as the user gets that right he will also have no problems to
> get module unloading right _if_ that would follow the same rules,
> but currently it involves lots of black magic instead.
Look, your implementation was slow, confusing, invasive, inflexible
*and* buggy.
Slow: Your approach where every interface has to do reference counts
even though they're only useful for modules makes every interface
slow, whether they are using modules or not. You can't make them
fast, because that would make every interface NR_CPUS *
sizeof(cacheline) larger.
Confusing: Your "deregistration can fail if busy but must succeed
otherwise" is guaranteed to confuse authors who will wonder why.
Currently some fail if it wasn't registered in the first place. To
understand why this has to change, they have to understand your
interface. You require a massive style change of not handling failure
within the failing function. Each module has to implement four (or
was it five?) functions for managing it.
Invasive: Every unregister interface to change, although many are very
happy with try_inc_modcount(). Worse, every module in the kernel has
to change to implement your method.
Inflexible: There is no way your scheme could allow "rmmod --wait" or
"rmmod --force" without adding yet another interface to *every*
module.
Buggy: You did not solve the "module used before init failed" problem,
but left the module loaded and uninitialized in this case.
> Rusty, I'm not impressed by the new module code,
I seriously question your taste in this matter. You obviously hold a
personal dislike for my code. Fine.
> maybe I'm missing something, but it doesn't fix anything
Then you don't understand the problem.
Sorry, but I'm wasting my time sending you mail. 8(
Rusty.
-- Anyone who quotes me in their sig is an idiot. -- Rusty Russell. - 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 : Fri Nov 15 2002 - 22:00:31 EST