Emmanuel Ackaouy wrote:
>>>> +#obj-y += elf.o
>>>> +#obj-$(CONFIG_COMPAT) += elf32.o
>>>
>>> Can we just zap those lines?
>>
>> Once ia64 is tested and ppc dom0 builder is ported over to libelf we can.
>
> Can you explain what ia64 or ppc have to do with lines that are commented
> out?
ia64 should work in theory, cross-compiling worked last time I tried,
didn't boot it though due to lack of hardware.
ppc(64) needs adaptions, simliar to the changes in
xen/arch/x86/domain_build.c and xen/arch/ia64/xen/domain.c
>>>> + /* compatibility check */
>>>> + compatible = 0;
>>>> + compat32 = 0;
>>>> + machine = elf_uval(&elf, elf.ehdr, e_machine);
>>>> + switch (CONFIG_PAGING_LEVELS) {
>>>
>>> Can we make this a compile time check instead of run-time?
>>
>> CONFIG_PAGING_LEVELS is a constant, thus it actually is compile-time,
>> the gcc optimizer should throw away the unused code paths. I prefer
>> this way over cluttering the source with #ifdefs.
>
> I'm not sure I follow. Are you suggesting we replace ifdefs with run
> time checks because the compiler will deal with it?
Yes.
CONFIG_COMPAT is partly handled that way too: with compat=n the
IS_COMPAT() macro is defined to 0, and gcc will optimize out the
conditional code which can run with compat=y only.
>>> Also, it
>>> would seem easier to do all the checks first and then do a printk
>>> specifying which kernel we found and, if it's not compatible with the
>>> hypervisor, why not.
>>
>> I intentionally print kernel and xen type unconditionally. I think it
>> is useful to have that information in the log, even if the combination
>> is not incompatible.
>
> I didn't suggest printing nothing when the combination is compatible.
I don't see the point in rearranging the code then.
cheers,
 Gerd
-- 
Gerd Hoffmann <kraxel@xxxxxxx>
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel