>-----Original Message-----
>From: Ian Pratt [mailto:m+Ian.Pratt@xxxxxxxxxxxx]
>Sent: Friday, June 17, 2005 4:25 PM
>To: Tian, Kevin; xen-devel@xxxxxxxxxxxxxxxxxxx
>
>It probably makes sense not to re-use arch-specific dom0_op numbers
>(though there wouldn't be any real abiguity), but I'm not sure its
worth
>trying to carve up the number space like this.
>
>I guess there's an argument for renaming the arch-specific dom0 ops to
>put X86 or IA64 in the name, but I don't think there's any real
>confusion. Perhaps we should split out arch definitions from
dom0_ops.h?
That's one way. Then union "dom0_op_t" may have a new field named
arch_dom0_op_t, which is defined in separate arch_dom0_ops.h.
Furthermore, include/public will have sub-directory then. If people all
agree on this direction, other files with similar requirement, like
arch_ia64.h, arch_x86_32.h, ..., may also be split like this way, to
export a uniform interface to management tools.
>
>
>I'm inclined not to do much in the way of rearranging until post 3.0.
>After 3.0 I'd like to rename dom0_ops altogether, and implement finer
>grained delegation of control operations.
>
>Comments?
OK, that's reasonable care. Actually simply considering dom0_ops, I like
the idea of a specific delegation, which is better and cleaner than
allowing arch to define its own set of operations.
Then saying the new operation I raised initially for this thread, I'll
discuss with you in another thread for its necessity. Finally if you
AGREE to add after the discussion, I'll use some hack to not touch
common dom0_ops.h, with a specific dom0_ops_ia64.h as temporary
solution. Later at post 3.0, I'll change it to new mechanism. ;)
Thanks,
Kevin
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home