On Wed, 2008-03-12 at 23:29 -0500, Manish Ahuja wrote: > If Mike and Paul are okay, then I will leave this bit as is and fix all > other issues and comments.
Well I still don't like it - it uglifies the code _now_, for a potential future benefit that may never come. But I don't care that much, if Paul's happy with it let it go in. cheers > Linas Vepstas wrote: > > On 10/03/2008, Michael Ellerman <[EMAIL PROTECTED]> wrote: > >> On Thu, 2008-02-28 at 18:24 -0600, Manish Ahuja wrote: > > > >> > + > >> > +/* Global, used to communicate data between early boot and late boot */ > >> > +static struct phyp_dump phyp_dump_global; > >> > +struct phyp_dump *phyp_dump_info = &phyp_dump_global; > >> > >> I don't see the point of this. You have a static (ie. non-global) struct > >> called phyp_dump_global, then you create a pointer to it and pass that > >> around. > > > > I did this. This is a style used to minimize disruption due to future > > design changes. Basically, the idea is that, at some later time, for > > some unknown reason, we decide that this structure shouldn't > > be global, or maybe shouldn't be statically allocated, or maybe > > should be per-cpu, or who knows. By creating a pointer, and > > just passing that around, you isolate other code from this change. > > > > I learned this trick after spending too many months of my life hunting > > down globals and replacing them by dynamically allocated structs. > > Its a long and painful process, on many levels, often requiring major > > code restructuring. Code that touches globals directly is often > > poorly thought out, designed. But going in the opposite direction > > is easy: if your code always passes everything it needs as args > > to subroutines, then you are free & clear ... if one of those args > > just happens to be a pointer to a global, there's no loss (not even > > a performance loss -- the arg passing overhead is about the same > > as a global TOC lookup!) > > > > So it may look weird if you're not used to seeing it; but the alternative > > is almost always worse. -- Michael Ellerman OzLabs, IBM Australia Development Lab wwweb: http://michael.ellerman.id.au phone: +61 2 6212 1183 (tie line 70 21183) We do not inherit the earth from our ancestors, we borrow it from our children. - S.M.A.R.T Person
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
