Re: Solving suspend-level confusion

[Pavel Machek <pavel@ucw.cz>]

Hi!

> > > > Maybe a better approach would be to describe the required features to
> > > > the drivers rather than encoding them in a single integer. Rather
> > > > like passing a request that states "lowest power level with device state
> > > > retained, must not do DMA, enable remote wake up"
> > > 
> > > A pointer to some sort of struct could be generic and typesafe;
> > > better than an integer or enum.
> > 
> > Well... if it gets that complicated, drivers will get it wrong...
> 
> It's already broken though!   Type-safe calls might at least
> trigger compiler warning when folk do things like, for example,
> pass a system power policy where a device power policy is
> needed.  So long as the API uses integers (or enums), it falls
> in the category of "oversimplified, impossible to get right".
> 
> But such a massive API change sounds to me like a 2.7
> thing.

Good.. So, for 2.6, can we agree on doing "enum xxx" thing? That at
least serves as a documentation. We could teach sparse to check for
it... (Anything that does 

enum foo x;
enum bar y = x;

is broken. If gcc does not warn about this, we should fix gcc...)

I believe "enum system_state" passed around, even to PCI drivers, and 
enum pci_state to_pci_state(enum system_state) helper is the right
thing to do for 2.6. Can we agree on that? 
								Pavel

-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!