2006-12-04 03:57:58

by Bela Lubkin

[permalink] [raw]
Subject: RE: [Openipmi-developer] [PATCH 9/12] IPMI: add pigeonpoint poweroff

Andrew Morton wrote:

> > Sometime, please go through the IPMI code looking for all these
> > statically-allocated things which are initialised to 0 or NULL and remove
> > all those intialisations? They're unneeded, they increase the vmlinux
> > image size and there are quite a number of them. Thanks.

Randy Dunlop replied:

> I was just about to send that patch. Here it is,
> on top of the series-of-12.
...
> -static int bt_debug = BT_DEBUG_OFF;
> +static int bt_debug;

Is it wise to significantly degrade code readability to work around a minor
compiler / linker bug?

>Bela<


2006-12-04 04:01:37

by Randy Dunlap

[permalink] [raw]
Subject: Re: [Openipmi-developer] [PATCH 9/12] IPMI: add pigeonpoint poweroff

Bela Lubkin wrote:
> Andrew Morton wrote:
>
>>> Sometime, please go through the IPMI code looking for all these
>>> statically-allocated things which are initialised to 0 or NULL and remove
>>> all those intialisations? They're unneeded, they increase the vmlinux
>>> image size and there are quite a number of them. Thanks.
>
> Randy Dunlop replied:
>
>> I was just about to send that patch. Here it is,
>> on top of the series-of-12.
> ...
>> -static int bt_debug = BT_DEBUG_OFF;
>> +static int bt_debug;
>
> Is it wise to significantly degrade code readability to work around a minor
> compiler / linker bug?

Is that the only one that is a problem?

I don't think it's a problem. We *know* that static data areas
are init to 0. Everything depends on that. If that didn't work
it would all break.

I could say that it's a nice coincidence that BT_DEBUG_OFF == 0,
but I think that it's more than coincidence.

--
~Randy

2006-12-04 04:12:47

by Randy Dunlap

[permalink] [raw]
Subject: Re: [Openipmi-developer] [PATCH 9/12] IPMI: add pigeonpoint poweroff

Randy Dunlap wrote:
> Bela Lubkin wrote:
>> Andrew Morton wrote:
>>
>>>> Sometime, please go through the IPMI code looking for all these
>>>> statically-allocated things which are initialised to 0 or NULL and
>>>> remove
>>>> all those intialisations? They're unneeded, they increase the vmlinux
>>>> image size and there are quite a number of them. Thanks.
>>
>> Randy Dunlop replied:
>>
>>> I was just about to send that patch. Here it is,
>>> on top of the series-of-12.
>> ...
>>> -static int bt_debug = BT_DEBUG_OFF;
>>> +static int bt_debug;
>>
>> Is it wise to significantly degrade code readability to work around a
>> minor
>> compiler / linker bug?
>
> Is that the only one that is a problem?
>
> I don't think it's a problem. We *know* that static data areas
> are init to 0. Everything depends on that. If that didn't work
> it would all break.
>
> I could say that it's a nice coincidence that BT_DEBUG_OFF == 0,
> but I think that it's more than coincidence.

It's Corey's decision. However, while code readability is also very
important to me, I disagree with "significantly" above.

--
~Randy

2006-12-05 15:41:43

by Corey Minyard

[permalink] [raw]
Subject: Re: [Openipmi-developer] [PATCH 9/12] IPMI: add pigeonpoint poweroff

Randy Dunlap wrote:
> Randy Dunlap wrote:
>> Bela Lubkin wrote:
>>> Andrew Morton wrote:
>>>
>>>>> Sometime, please go through the IPMI code looking for all these
>>>>> statically-allocated things which are initialised to 0 or NULL and
>>>>> remove
>>>>> all those intialisations? They're unneeded, they increase the
>>>>> vmlinux
>>>>> image size and there are quite a number of them. Thanks.
>>>
>>> Randy Dunlop replied:
>>>
>>>> I was just about to send that patch. Here it is,
>>>> on top of the series-of-12.
>>> ...
>>>> -static int bt_debug = BT_DEBUG_OFF;
>>>> +static int bt_debug;
>>>
>>> Is it wise to significantly degrade code readability to work around
>>> a minor
>>> compiler / linker bug?
>>
>> Is that the only one that is a problem?
>>
>> I don't think it's a problem. We *know* that static data areas
>> are init to 0. Everything depends on that. If that didn't work
>> it would all break.
>>
>> I could say that it's a nice coincidence that BT_DEBUG_OFF == 0,
>> but I think that it's more than coincidence.
>
> It's Corey's decision. However, while code readability is also very
> important to me, I disagree with "significantly" above.
>
I think the optimizations are probably important enough that this should
be done. Let's take Randy's patch and I will add a comment to
BT_DEBUG_OFF that says that the value must be zero to correspond to
the default uninitialized value.

-Corey