Hi,
Werner Almesberger wrote:
> > You can simplify this. All you need are the following simple functions:
> >
> > - void register();
> > - void unregister();
> > - int is_registered();
> > - void inc_usecount();
> > - void dec_usecount();
> > - int get_usecount();
>
> I'm not sure if you, you're not changing the semantics.
See above functions as primitives, which one can use to build any other
resource management you want.
The module code does the get_usecount() test for every driver and if it
was zero it disables inc_usecount() and only then the driver is allowed
to unregister(). The module code has to add another is_active state for
this and is so actually adding more complexity to it.
> What I was
> describing was a non-blocking interface, e.g.
>
> if (!prepare_deregister(foo))
> return -E...;
> if (!prepare_deregister(bar)) {
> undo_deregister(foo);
> return -E...;
> }
> commit_deregister(foo);
> commit_deregister(bar);
> return 0;
You are making it too complex, as you probably need an is_active state
as well, it would be just per interface instead of global.
If you really want to reduce complexity, all you can do, is to get rid
of the is_active state. For the majority of drivers such state isn't
needed at all, but it's currently forced on all drivers.
So to keep things simple, we should just finish shutting down the
driver, as soon as we started with it and don't restart or undo
anything. To avoid the sleeping we can also simply return -EBUSY and
continue later, so the cleanup could look like this:
if (!ptr)
return 0;
if (is_registered())
unregister();
if (get_usecount())
return -EBUSY;
release();
return 0;
This way the caller just needs to do the following, which can be called
as often as necessary:
if (shutdown(ptr))
return -EBUSY;
ptr = NULL;
There is really no need to introduce extra states to make things more
complex.
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 : Thu Jan 23 2003 - 22:00:14 EST