Re: [Xen-devel] [PATCH] Add RCU support into Xen - Repost

[Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>]

On 30/1/07 8:23 pm, "Keir Fraser" <Keir.Fraser@xxxxxxxxxxxx> wrote:

> This would require some interaction with new find_domain_by_id(). The
> invocation of find_domain_by_id() and all subsequent uses of its return
> value will need to be contained within an rcu_read_lock()/rcu_read_unlock()
> pair which seems kind of a pain. Particularly since this documentation is
> weak -- it may not immediately be clear in future what is being protected by
> the rcu read-side region (since the lock routines do not take a parameter).
> And I'm not sure how the documentation helps: who will it be useful to?

Thinking about this a little more, we could wrap up the rcu_read_[un]lock
invocations into a more informative API in this case:
get_domain_by_id_rcu(d) and put_domain_rcu(d), analagous with
get_domain/put_domain. get_domain_by_rcu(d) would include an implicit
rcu_read_lock(), and put_domain_rcu(d) an implicit rcu_read_unlock().

I could certainly live with that, and then keep direct use of
rcu_read_lock()/rcu_read_unlock() for small critical regions (e.g., in the
implementation of get_domain_by_id()).

 -- Keir

> Linux needs them for more than just documentation as it has to disable
> preemption (a feature which I don't expect Xen to ever acquire). I don't
> know whether it would have them otherwise.
> 
>  -- Keir
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel