Re: [PATCH]: Prevent sn2 ptc code from executing on all ia64 subarches

[Prarit Bhargava <prarit@sgi.com>]

Luck, Tony wrote:
>>I'm not thrilled about this approach.
>>
>>I'd *like* to be able to assume that "changes in arch/ia64/sn/* clearly
>>don't affect non-SN platforms".  But this style breaks that.  Every ia64
>>box calls all these SN init functions, and if somebody forgets the
>>ia64_platform_is("sn2") check, bad things will happen.
>>
>>I'd like it a whole lot better if all these initialization-type things
>>could be hidden inside sn_setup() or some other machine vector.

The issue is that the initcalls are not executed at the same point in the boot 
-- there are seven levels of these and each level needs to be honoured. 
Placing them inside sn_setup() or some other machine vector is not the right 
thing to do (IMO -- there might be away to code around the levels that I'm 
unaware of).

> 
> 
> Me too ... these ia64_platform_is("sn2") are getting sprinkled in
> more and more places.
> 

I've been thinking about this and am wondering if the following solution might 
be more acceptable?

I'm also concerned about plugging in many ia64_platform_is checks into the code 
-- as Tony and Bjorn point out it seems that this approach is fraught with 
peril.  I'm also concerned about the possiblity of executing non-SGI code on one 
of my systems.

What if we added wrappers to the existing initcall functions to accept another 
argument?

Instead of subsys_initcall(fn) we would do

subarch_subsys_initcall (fn, arch) and this wrapper would do a platform check of 
the machine vector info?

ie)

subarch_subsys_initcall (init_foo, sn2)?


This seems a lot cleaner and would clean up other modular code as well.

I haven't completed my investigation yet -- the first patch that I submitted was 
in response to (what appeared to be) a minor issue reported by a colleague at 
another vendor and as Robin points out, is clearly only the start of the fix.

P.