> The infrastructure is agnostic to whether the objects are common or
> driver specific.
> It actually gives you a (hopefully) convenient way to invoke verbs
> handlers in the kernel.
> Each handler is a function which could have some arguments. However,
> we can't pass kernel pointers
> from user-space to kernel and we can't trust the user-space from
> executing two calls concurrently that
> could use an object and destroy it at the same time. Currently
> (current infrastructure), when you write such a handler, you need
> to open code this yourself - map ids to objects and lock them.
>
> What we propose here is to have some additional info to the handler.
> This info could be thought as the function's deceleration.
> This additional info makes the infrastructure validates syntactically
> your attributes, map them to the actual kernel pointers and lock them.
> Since the kernel developer writes this "additional info"
> (specification), it can make sure only one "DESTROY" or "CREATE"
> object exists per a specification (to avoid the behavior you
> mentioned).
>
> A command handling always consists of 3 stages: pre, handler and post
> (for all handlers).
> So, overall, if you have a create based command, the "pre" stage
> creates the uobject and locks its dependencies. If the handler fails,
> this is totally reversible (unlock dependencies and destroy the
> uobject).
> If you have a destroy command, the "pre" stage locks the uobject for
> exclusive access. If the handler fails, it just unlocks the object. If
> it's successful, the "post" stage actually destroys it.
> In other commands, the "pre" stage just locks the uobjects and
> obviously it's reversible.
>
> I hope that answers your questions.
>
I'm in sync with you.
Thanks for further explaining.
- Ram
��.n��������+%������w��{.n�����{���fk��ܨ}���Ơz�j:+v�����w����ޙ��&�)ߡ�a����z�ޗ���ݢj��w�f
