On Mon, 2006-04-17 at 14:11 -0400, Maria Butrico wrote:
> I am missing all the point as well. You don't want an initialization
> for these variables? You are arguing that we get it for free?
Yes.
> My preference is to initialize everything, according to the convention
> used by the code. What are Xen conventions for initalizing global
> variables? If there aren't any already, then any ideas about what we want?
xen/arch/x86/setup.c contains quite a few globals. It has a couple "= 0"
initializations, but the majority is left for .bss.
Linux omits such initializations. Since we need to work in both worlds,
I think it would be helpful to keep consistent style where possible.
I believe some versions of GCC place "= 0" globals into .data,
increasing the size of the executable. Later gcc versions notice that
it's 0 (as opposed to some other value) and place them into .bss
anyways.
> So I prefer to initialize, but I am willing to do it in any reasonable
> way.
I prefer not to, which I think is reasonable. ;)
> Hollis Blanchard wrote:
> > On Sat, 2006-04-15 at 08:37 -0400, Jimi Xenidis wrote:
> >
> >> On Apr 14, 2006, at 11:36 AM, Hollis Blanchard wrote:
> >>
> >>>>>> +/* opt_nohv: If true, hardware has no hypervisor (HV) mode or
> >>>>>> nohv boot
> >>>>>> + * parameter was specified.
> >>>>>> + */
> >>>>>> +int opt_nohv = 0;
> >>>>>>
> >>> Don't need to explicitly initialize this.
> >>>
> >> Hollis, this is global processor state. We don;t track processor
> >> capabilities blobally yet, untill we do we need this. I don't think
> >> that we should expect boot_of.c to init it.
> >>
> >>
> >>>>>> +boolean_param("nohv", opt_nohv);
> >>>>>> +
> >>>>>> int opt_earlygdb = 0;
> >>>>>>
> >>> (Or this; it's not your code but if you submit a patch I'd happily
> >>> apply.)
> >>>
> >> No, I explicitly want this, I'd like to be able to force "nohv" mode
> >> on the command line for testing and profiling purposes.
> >>
> >
> > I think you're missing my point: I'm talking about initializing opt_nohv
> > and opt_earlygdb. These are global variables, and so they will land in
> > the .bss section.
> >
> >
>
>
>
> _______________________________________________
> Xen-ppc-devel mailing list
> Xen-ppc-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-ppc-devel
--
Hollis Blanchard
IBM Linux Technology Center
_______________________________________________
Xen-ppc-devel mailing list
Xen-ppc-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ppc-devel
|
Home