In message: <20100411192449.ga1...@dale.cnst.cs.uwaterloo.ca>
            "Constantine A. Murenin" <c...@freebsd.org> writes:
: On Tue, Apr 06, 2010 at 07:43:13AM -0600, M. Warner Losh wrote:
: > In message: <de573364-a7a7-4805-bcbc-665ae0e13...@freebsd.org>
: >             Rui Paulo <rpa...@freebsd.org> writes:
: > : Hi,
: > :
: > : On 5 Apr 2010, at 06:59, Constantine A. Murenin wrote:
: > :
: > : > Dear freebsd-{acpi,drivers,hardware}@,
: > : >
: > : > Attached patch provides support for the hardware monitoring
: > capabilities that are present in many modern desktop motherboards from
: > ASUS featuring the ATK0110 ACPI device.
: > : >
: > : > This driver, aibs(4), is a fresh replacement for FreeBSD's
: > existing acpi_aiboost(4).  The new aibs(4) driver has the following
: > advantages when compared to the old acpi_aiboost(4):
: > : > * the sensors are now provided through the user-serviceable
: > hw.acpi.aibs0 tree (with a subtree for each sensor type), instead of
: > the Newbus-internal dev.acpi_aiboost.0 tree that contains various
: > nonprime data at the same level as the actual sensors
: > :
: > : I was under the impression that this the right way in FreeBSD.
: >
: > To be clear, this is a regression.  They should be through the dev
: > tree.  We've been migrating exposed functionality from the hw. tree to
: > the dev. tree for quite some time now.  hw. isn't any more
: > user-serviceable than dev. is.
: > Warner
: 
: Thanks for your comments.  But what about the %desc, %driver,
: %location, %pnpinfo and %parent leaves that, for example, appear under
: the dev.aibs.0 tree? 

Yes.  They do.

: Don't they introduce the perception that the dev
: tree is not really user-serviceable, as most of the tree is
: practically entirely useless for the end-user?  

No, they shouldn't.  There's documented APIs for hooking into this
tree.  That sounds like it would be user-serviceable.  That certainly
was the intent when DES added them.

: Is there, or should
: there be, a way to tell sysctl(8) to not print such %driver leaves
: under the dev tree?  

sysctl dev.acpi | grep -v %

will do the trick.

: I've simply used acpi_thermal.c as the exemplar
: for hw.acpi attachment, as I've found it to produce more elegant
: results than the dev attachment.  Should acpi_thermal be also
: converted to use the dev tree?  I can write a patch.

I think it should be.

: In any case, I've modified aibs(4) to now use its dev tree (see the
: patch inline); aibs(4) is now even smaller than it was before, still
: supporting several additional features:

Woo Hoo!

: > ll /usr/c/src/sys/dev/acpi_support/{acpi_aiboost,atk0110}.c
: -rw-r--r-- 1 constant wheel 8919 Apr 3 20:31
: -/usr/c/src/sys/dev/acpi_support/acpi_aiboost.c
: -rw-r--r-- 1 constant wheel 8299 Apr 11 12:29
: -/usr/c/src/sys/dev/acpi_support/atk0110.c
: > ll /boot/kernel/*aib*s*
: -r-xr-xr-x 1 root wheel 11581 Apr 11 12:57 /boot/kernel/acpi_aiboost.ko
: -r-xr-xr-x 1 root wheel 24504 Apr 11 12:57
: -/boot/kernel/acpi_aiboost.ko.symbols
: -r-xr-xr-x  1 root  wheel   9801 Apr 11 12:57 /boot/kernel/aibs.ko
: -r-xr-xr-x 1 root wheel 21203 Apr 11 12:57 /boot/kernel/aibs.ko.symbols
: > sysctl dev.aibs.0.{volt,temp,fan}
: dev.aibs.0.volt.0: 1240 850 1600
: dev.aibs.0.volt.1: 3312 2970 3630
: dev.aibs.0.volt.2: 5017 4500 5500
: dev.aibs.0.volt.3: 12302 10200 13800
: dev.aibs.0.temp.0: 30.0C 80.0C 95.0C
: dev.aibs.0.temp.1: 56.0C 60.0C 95.0C
: dev.aibs.0.fan.0: 878 600 7200
: dev.aibs.0.fan.1: 0 700 7200

Cool.

Warner
_______________________________________________
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

Reply via email to