Tian, Kevin
2005-Jun-17 09:34 UTC
RE: [Xen-devel] [Patch 1/2] Re-org dom0_ops.h to allow arch specificdefinition
>-----Original Message----- >From: Ian Pratt [mailto:m+Ian.Pratt@cl.cam.ac.uk] >Sent: Friday, June 17, 2005 4:25 PM >To: Tian, Kevin; xen-devel@lists.xensource.com > >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 itsworth>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 fromdom0_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@lists.xensource.com http://lists.xensource.com/xen-devel