RE: [Xen-devel] Remaining ia64 differences in xen driver code -- privcmd

["Magenheimer, Dan (HP Labs Fort Collins)" <dan.magenheimer@xxxxxx>]

> I have also had to hack up privcmd.c for PowerPC. (It's not 
> at all "done", but 
> if you're curious you can see 
> http://xenbits.xensource.com/ext/linux-ppc-2.6.hg?cmd=file;fil
> enode=2d94a3add83d64fa65e574dffbcb9a7cebea5c4b;file=drivers/xe
> n/privcmd/privcmd.c .) 
> 
> It would be cleaner to have privcmd_ioctl just call out to 
> arch_privcmd_ioctl.

That makes sense, but currently there is no directory structure
to support the archdep/arch-neutral boundaries for xen drivers
(so no place to put arch_privcmd_ioctl) other than in header files.

This needs to be fixed before the xen drivers (and xen core
driver support files) find their way upstream into linux,
but I'm guessing that will happen (sadly) post-3.0.

> For example, PPC Linux doesn't do physical<->machine 
> translation right now. 
> We will probably change that in the future, but for the 
> moment things like 
> 'machine_to_phys_mapping' do not exist. It seems from your 
> ifdefs that IA64 
> has similar issues, so for now it seems there are more 
> differences than 
> commonality in privcmd_ioctl, so we should just make it arch-specific.

True on ia64 also and there has been much discussion
on xen-ia64-devel as to whether this should be changed
to reduce maintenance costs.  Personally I think the right
answer is to define better (archdep/arch-neutral) boundaries,
but others would like Xen/ia64 to be as similar to Xen/x86
as possible.

Dan

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