[linux-pm] PM:Different idea for callbacks, smoother evolution

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi!

> > I think you meant Darwin (evolution theory), not Darwin (MAC OS X
> > part)?
> 
> I meant OS X :)
> 
> > > The idea is simple. Drivers describe their possible power states in an
> > > array, which contains:
> > > 
> > >  - state name (ascii) for use by sysfs (see below)
> > >  - some flags (for later use mostly)
> > >  - matching system state
> > >  - additional infos (see below), that is struct can be extended for
> > > later uses.
> > 
> > These arrays are going to get big and ugly over time.
> 
> Actually, that's what I though at first, but after pondering it for a
> while, I think not. Most drivers will ever only have 2 entries (and we
> can probably provide a default macro that would create the simple 2
> entries array for these even). Drivers with more subtle power management
> capabilities will have the ability here to expose them in a consistent
> way to userland.

I do not see it being that easy. If I have long and ugly suspend
routine (similar to radeonfb), and want to base some detail on
pm_message.flags, I can just do if (pm_message.flags) ... .

With table approach, I'd have to add new state to the table (say
duplicate 2 into 3), and than fix  all if(state == 2) to if ((state ==
2) || (state == 3)).

I guess it could work for simple drivers, through.
								Pavel
-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!


[Index of Archives]     [Linux ACPI]     [Netdev]     [Ethernet Bridging]     [Linux Wireless]     [CPU Freq]     [Kernel Newbies]     [Fedora Kernel]     [Security]     [Linux for Hams]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux Admin]     [Samba]

  Powered by Linux