Skip site navigation (1)Skip section navigation (2)
Date:      18 Jul 2000 02:21:32 +0200
From:      Cyrille Lefevre <clefevre%no-spam@citeweb.net>
To:        nsayer@FreeBSD.ORG
Cc:        freebsd-hackers@FreeBSD.ORG, Warner Losh <imp@village.org>
Subject:   Re: sysctl interface for apm?
Message-ID:  <66q45lv7.fsf@pc166.gits.fr>
In-Reply-To: Nick Sayer's message of "Mon, 17 Jul 2000 11:15:18 -0700"
References:  <3971F574.B492B904@softweyr.com> <1884.963737703@critter.freebsd.dk> <200007171753.LAA62543@harmony.village.org> <39734D36.5FC7DDA@sftw.com>

next in thread | previous in thread | raw e-mail | index | archive | help
Nick Sayer <nsayer@sftw.com> writes:

> Warner Losh wrote:
> 
> > In message <3971F574.B492B904@softweyr.com> Wes Peters writes:
> > : Poul-Henning Kamp wrote:
> > : >
> > : > In message <200007160625.XAA92886@freefall.freebsd.org>, nsayer@FreeBSD.ORG wri
> > : > tes:
> > : >
> > : > >So what does everyone think? Is it suitable to add a read only
> > : > >sysctl 'machdep.apm_powerstate' that reports either AC, nn%,
> > : > >or N/A ? Or should the format be numeric (999 = AC, <=100 = battery %,
> > : > >-1 = N/A)? Or should we not bother? :-)
> > : >
> > : > yes it is suitable.
> > :
> > : Perhaps machdep.apm.powerstate, leaving room in the namespace for other
> > : apm parameters?  Charging state and battery life leap immediately to
> > : mind.
> >
> > No.  DO NOT CALL IT APM.  APM is i386 specific and is doing its best
> > to die off in favor acpi.
> >
> > If you must call it apm, do *NOT* cause being on AC power to override
> > the batery %.  These are two different things and should be reported
> > as such.
> >
> > machdep.apm.battery:    0..100  (for battery percentage)
> > machdep.apm.runtime:    0..     (for the reported battery life remaining)
> > machdep.apm.ac:         0 1     (1 means we're running off AC)
> > machdep.apm.charging:   0 1
> > machdep.apm.batteries:  0..     (number of batteries apm says are there)
> >
> > But why bother?  The apm command gives you this already. :-)
> 
> The "why bother" is easy -- one should not have to belong to group
> operator to determine the current battery state. Too many things
> already have to be sgid (at least) without making this another reason.
> 
> I took a middle ground. I have two ints, machdep.apm_battlevel
> and machdep.apm_powerstate. The power state number is
> -1 to 5 for unknown, critical, low, medium, high (which four imply
> battery power), AC or charging (which two imply AC power).
> 
> These patches are actually against -stable, but I will get this
> into -current shortly.
> 
> Suggestions as to how to correct the errors I probably made in
> the sysctl interface are welcome. :-)
> 
> 
[snip]
> +
> +SYSCTL_PROC(_machdep, OID_AUTO, apm_battlevel, CTLTYPE_INT|CTLFLAG_RD, 0,
> +	sizeof(sysctl_apm_battlevel), &sysctl_apm_battlevel,
> +	"I", "Current APM battery level");
> +SYSCTL_PROC(_machdep, OID_AUTO, apm_powerstate, CTLTYPE_INT|CTLFLAG_RD, 0,
> +	sizeof(sysctl_apm_powerstate), &sysctl_apm_powerstate,
> +	"I", "Current APM power state");
> +
>  /*
>   * return  0 if the function successfull,
>   * return  1 if the function unsuccessfull,
> 

could you implement the same thing using the sublevel machdep.apm.bla... ?

Cyrille.
-- 
home:mailto:clefevre%no-spam@citeweb.net Supprimer "%no-spam" pour me repondre.
work:mailto:Cyrille.Lefevre%no-spam@edf.fr Remove "%no-spam" to answer me back.


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?66q45lv7.fsf>