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<
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
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
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