Messages in this thread | | | Date | Wed, 2 Feb 2005 10:57:39 +0100 | From | Pavel Machek <> | Subject | Re: [linux-pm] Re: driver model u32 -> pm_message_t conversion: help needed |
| |
Hi!
> > Pavel> Hi! Two Long time ago, BenH said that making patches is easy, > > Pavel> so I hope to get his help now... And will probably need more. > > > > Pavel> Suspend routines change, slowly. > > > > Pavel> - int (*suspend)(struct device * dev, u32 state); + int > > Pavel> (*suspend)(struct device * dev, pm_message_t state); > > > > Pavel> For now u32 is typedef-ed to pm_message_t, but that is not > > Pavel> going to be the case for 2.6.12. What needs to be done is > > Pavel> changing all state parameters from u32 to > > Pavel> pm_message_t. suspend() functions should not use state variable > > Pavel> for now (except for PCI ones, those are allowed to call > > Pavel> pci_choose_state and convert state into pci_power_t, and use > > Pavel> that). > > > > Sorry for being late responding to this, but I'd say this is a prime > > example for typedef's considered evil (see Greg's OLS talk ;). > > > > It would be a lot cleaner if it was made a struct and then passing a > > struct pointer as the argument instead of passing the struct by value > > as you do right now. > > Sorry, can't do that. That would require flag day and change > everything at once. That is just not feasible. When things are > settled, it is okay to change it to struct passed by value.. It is > small anyway and at least we will not have problems with freeing it > etc.
Well, we could switch to passing struct by reference
(typedef struct pm_message *pm_message_t)
, but AFAICS it would only bring us problems with lifetime rules etc. Lets not do it. Pavel
-- People were complaining that M$ turns users into beta-testers... ...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |