[PATCH RFC] Introduce one machine_desc instance and get_machine_desc()
Eric Miao
eric.miao at canonical.com
Wed Jul 7 10:14:12 EDT 2010
On Wed, Jul 7, 2010 at 9:32 PM, Nicolas Pitre <nico at fluxnic.net> wrote:
> On Wed, 7 Jul 2010, Eric Miao wrote:
>
>> commit 5d5d90e5d41bb0842559dd2b00f00f2a0f532a3a
>> Author: Eric Miao <eric.miao at canonical.com>
>> Date: Wed Jul 7 16:47:20 2010 +0800
>>
>> [ARM] Introduce one machine_desc instance and get_machine_desc()
>>
>> If some of the fields remains useful in 'struct machine_desc', it's
>> normally a bit convenient to keep one instance there for reference.
>>
>> (along with more and more machine specific fields coming into this
>> structure, e.g. pcibios_min_{io,mem})
>>
>> It also improves modularity a bit by not exporting variables like
>> system_timer, init_arch_irq etc.
>>
>> However, the drawbacks are 1) a bit increased data and 2) increased
>> risk of accessing those fields which are marked as __init.
>
> That makes me worried. Access to __init data/functions after __init
> stuff is freed is amongst the nastiest subtle bugs that are hard to
> reproduce and therefore fix. And copying such pointers is probably
> defeating the simple compile time checks we currently have against that.
Indeed I was upset as well :-)
>
> Maybe those fields should be partitioned differently. Having a new
> structure to encapsulate all fields that should be kept after __init
> stuff is gone might be a better way.
That's going to invent another similar structure and produce more code
when copying over. What about keeping those __init function pointers
as NULL, and copying the rest?
>
>
> Nicolas
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
More information about the linux-arm-kernel
mailing list