Hi!
> > This can also handle the user-dictated policy, which I haven't seen
> > discussed yet. For instance, when you close the lid or press the power
> > button, the system can enter suspend or it can power off. If the kernel
> > simply exported the event, the userspace daemon could simply check
Patrick Mochel <[EMAIL PROTECTED]> writes:
[...]
> > > I can see at least two types of events - (forgive the lack of colorful
> > > terminology) passive and active. Passive events are simply providing
> > > status updates, much like the events described above. These are simply so
> > > some UI c
> > > > (1) Battery status, power status, UPS status polling. It
> > > > should be possible for lots of processes to do this
> > > > simultaneously. [That does not prohibit a single process
> > > > querying the kernel and all the others querying it.]
> > >
> > > S
Patrick Mochel <[EMAIL PROTECTED]> writes:
[...]
> > Solution. Have a special procfs or dev node that any number of people
> > can select(2) or read(2). Protocol text. Syntax:
> >
> >
> >
> > Where is one of the strings
> > OFF,SLEEP,WAKE,EMERGENCY,POWERCHANGE, is a space char
Patrick Mochel <[EMAIL PROTECTED]> writes:
> > > IMHO the pm interface should be split up as following:
> >
> > Nobody has disagreed: therefore this separation must be perfect ;-)
>
> I once heard that patience is a virtue. :)
>
> > > (1) Battery status, power status, UPS status polli
> > IMHO the pm interface should be split up as following:
>
> Nobody has disagreed: therefore this separation must be perfect ;-)
I once heard that patience is a virtue. :)
> > (1) Battery status, power status, UPS status polling. It
> > should be possible for lots of processe
> This is flexible and simple. It means a reasonable default behaviour
> can be suggested by the kernel (OFF,SLEEP,etc.) for events that
> userspace doesn't know about and yet userspace can choose fine grained
> policy and provide helpful error messages based on the exact event by
The entire PM l
7 matches
Mail list logo
