Re: apmd: add on demand adjustement mode
That code was fixed in -current, and will be in 5.7. Now, the kernel does the measurements and scaling. On 2015 Mar 02 (Mon) at 15:04:09 + (+), Jérôme Frgacic wrote: :Hello, : :At present, there is no middle between cool running and automatic adjustement mode. :I would suggest to add an on demand adjustement mode which set hw.setperf to :maximum when CPU idle is lesser then 10% and reduce it when CPU idle is greater than :30%. Also, when hw.setperf is at maximum, verification of CPU idle is slow down. : :This is based on a previous suggestion of Laurence Tratt. : :PS : please add me to recepient if you reply. : -- SHIFT TO THE LEFT! SHIFT TO THE RIGHT! POP UP, PUSH DOWN, BYTE, BYTE, BYTE!
redundant code in reboot/halt and init?
Hi there, i read the code of init.c and reboot.c and was asking myself why reboot is not just sending SIGINT to init? The whole reboot code seems to be redundant, or am i missing something here? Why not just determine if im running as halt or reboot and send the correct signal to init. Let init handle everything else. But maybe there is something i don't see at the moment though. BR Simon
Testing LibreSSL Windows binaries
Hi, Based on difficulty people have had building LibreSSL on Windows and desire for integration with Visual Studio, I have made a test package with LibreSSL Windows binaries available here: https://github.com/libressl-portable/portable/releases/tag/untagged-1124b2dee438a382b881 These should work with Microsoft tools, and the debug information should be compatible with most Windows debuggers. This is not an official release, but I would be interested in feedback/success/failure stories. No fruit throwing please! The build script that generates these is here: https://github.com/libressl-portable/portable/blob/master/dist-win.sh With some initial build notes here: https://github.com/libressl-portable/portable/blob/master/README.windows - Brent
qsort.3 big O notation
i was looking at the qsort(3) man page, and saw O N lg N, etc. first i thought, maybe there should be some fancy utf8 math parentheses around, but looking at the source, no, it's plain ascii. a quick search in other man pages reveals an arguably more readable style: ./share/man/man3/queue.3:overhead at the expense of O(n) removal for arbitrary elements. ./share/man/man3/tree.3:and n inserts on an initially empty tree as O((m + n)lg n). ./share/man/man3/tree.3:The amortized cost for a sequence of m accesses to a splay tree is O(lg n). ./share/man/man3/tree.3:Every operation on a red-black tree is bounded as O(lg n). ./share/man/man5/pf.conf.5:If there are 50 rules, all of them are evaluated sequentially in O(n). ./share/man/man5/pf.conf.5:searches in O(log2 n). i leave the battle about lg vs log to others, but i prefer 'log' as there is a man page for that and there is none for 'lg'... -f -- if it wasn't for time everything would happen at once. Index: ./lib/libc/stdlib/qsort.3 === RCS file: /cvs/src/lib/libc/stdlib/qsort.3,v retrieving revision 1.18 diff -u -p -r1.18 qsort.3 --- ./lib/libc/stdlib/qsort.3 29 Jan 2015 01:46:31 - 1.18 +++ ./lib/libc/stdlib/qsort.3 3 Mar 2015 15:56:42 - @@ -109,9 +109,9 @@ algorithm, a variant of partition-exchange sorting; in particular, see D.E. Knuth's Algorithm Q. .Fn qsort -takes O N lg N average time. +takes O(n log n) average time. This implementation uses median selection to avoid its -O N**2 worst-case behavior. +O(n**2) worst-case behavior. .Pp The .Fn heapsort @@ -120,7 +120,7 @@ function is an implementation of J.W.J. algorithm, a variant of selection sorting; in particular, see D.E. Knuth's Algorithm H. .Fn heapsort -takes O N lg N worst-case time. +takes O(n log n) worst-case time. This implementation of .Fn heapsort is implemented without recursive function calls. @@ -133,7 +133,7 @@ requires additional memory of size bytes; it should be used only when space is not at a premium. .Fn mergesort is optimized for data with pre-existing order; its worst case -time is O N lg N; its best case is O N. +time is O(n log n); its best case is O(n). .Pp Normally, .Fn qsort
Re: qsort.3 big O notation
frantisek holop wrote: i was looking at the qsort(3) man page, and saw O N lg N, etc. first i thought, maybe there should be some fancy utf8 math parentheses around, but looking at the source, no, it's plain ascii. a quick search in other man pages reveals an arguably more readable style: ./share/man/man3/queue.3:overhead at the expense of O(n) removal for arbitrary elements. ./share/man/man3/tree.3:and n inserts on an initially empty tree as O((m + n)lg n). ./share/man/man3/tree.3:The amortized cost for a sequence of m accesses to a splay tree is O(lg n). ./share/man/man3/tree.3:Every operation on a red-black tree is bounded as O(lg n). ./share/man/man5/pf.conf.5:If there are 50 rules, all of them are evaluated sequentially in O(n). ./share/man/man5/pf.conf.5:searches in O(log2 n). i leave the battle about lg vs log to others, but i prefer 'log' as there is a man page for that and there is none for 'lg'... If that's the argument to be made, it should be log2 as in pf.conf.
Re: qsort.3 big O notation
On Tue, Mar 03, 2015 at 05:02:39PM +0100, frantisek holop wrote: i leave the battle about lg vs log to others, but i prefer 'log' as there is a man page for that and there is none for 'lg'... If anything, it should be log because that is the name of the mathematical function. libm is completely irrelevant in this context. Joerg
Re: qsort.3 big O notation
Ted Unangst, 03 Mar 2015 11:13: frantisek holop wrote: i was looking at the qsort(3) man page, and saw O N lg N, etc. first i thought, maybe there should be some fancy utf8 math parentheses around, but looking at the source, no, it's plain ascii. a quick search in other man pages reveals an arguably more readable style: ./share/man/man3/queue.3:overhead at the expense of O(n) removal for arbitrary elements. ./share/man/man3/tree.3:and n inserts on an initially empty tree as O((m + n)lg n). ./share/man/man3/tree.3:The amortized cost for a sequence of m accesses to a splay tree is O(lg n). ./share/man/man3/tree.3:Every operation on a red-black tree is bounded as O(lg n). ./share/man/man5/pf.conf.5:If there are 50 rules, all of them are evaluated sequentially in O(n). ./share/man/man5/pf.conf.5:searches in O(log2 n). i leave the battle about lg vs log to others, but i prefer 'log' as there is a man page for that and there is none for 'lg'... If that's the argument to be made, it should be log2 as in pf.conf. oops. (my compsci classes were in another millenium) -f -- if practice makes perfect, and nobody's perfect, why practice?
Re: Testing LibreSSL Windows binaries
On Mar 3, 2015, at 9:22 AM, Brent Cook bust...@gmail.com wrote: Hi, Based on difficulty people have had building LibreSSL on Windows and desire for integration with Visual Studio, I have made a test package with LibreSSL Windows binaries available here: https://github.com/libressl-portable/portable/releases/tag/untagged-1124b2dee438a382b881 I apparently linked to the 'Draft' URL. Here is a public one. https://github.com/libressl-portable/portable/releases/tag/v2.1.4-pre These should work with Microsoft tools, and the debug information should be compatible with most Windows debuggers. This is not an official release, but I would be interested in feedback/success/failure stories. No fruit throwing please! The build script that generates these is here: https://github.com/libressl-portable/portable/blob/master/dist-win.sh With some initial build notes here: https://github.com/libressl-portable/portable/blob/master/README.windows - Brent
Re: qsort.3 big O notation
Joerg Sonnenberger, 03 Mar 2015 17:28: On Tue, Mar 03, 2015 at 05:02:39PM +0100, frantisek holop wrote: i leave the battle about lg vs log to others, but i prefer 'log' as there is a man page for that and there is none for 'lg'... If anything, it should be log because that is the name of the mathematical function. libm is completely irrelevant in this context. 'lg' is also a valid name (altough i admit i didn't know, i was used to log2) https://en.wikipedia.org/wiki/Logarithm#Particular_bases as Tedu pointed out lg = log2 and lg != log but i think my point is still kind of valid, as there is log2(3) and no lg(3). i find it relevant that libm should also use the most common, easiest names where possible... it is kind of nice to be able to do 'man log2' after reading 'man qsort', a kind of indirect cross reference. -f -- illiterate? write for a free brochure!
Re: qsort.3 big O notation
On March 3, 2015 at 5:48 PM frantisek holop min...@obiit.org wrote: If anything, it should be log because that is the name of the mathematical function. libm is completely irrelevant in this context. 'lg' is also a valid name When talking about big O notation, you want to trim as many constants as possible. I would go for log, too: log2(x) can be written as log(x)/log(2), which means that 1/log(2) is the constant that you can remove: log(x) is left.
Re: qsort.3 big O notation
On 3 March 2015, frantisek holop min...@obiit.org wrote: Joerg Sonnenberger, 03 Mar 2015 17:28: On Tue, Mar 03, 2015 at 05:02:39PM +0100, frantisek holop wrote: i leave the battle about lg vs log to others, but i prefer 'log' as there is a man page for that and there is none for 'lg'... If anything, it should be log because that is the name of the mathematical function. libm is completely irrelevant in this context. 'lg' is also a valid name (altough i admit i didn't know, i was used to log2) https://en.wikipedia.org/wiki/Logarithm#Particular_bases as Tedu pointed out lg = log2 and lg != log Actually, that isn't what Tedu said, and it isn't the generally accepted convention. The usual convention is: * log = ln = log_e * lg = log_10 As somebody else points out, they differ from each other by multiplicative constants, so either are correct for O-notation. (Full disclosure: I'm a mathematician. :)) but i think my point is still kind of valid, as there is log2(3) and no lg(3). i find it relevant that libm should also use the most common, easiest names where possible... it is kind of nice to be able to do 'man log2' after reading 'man qsort', a kind of indirect cross reference. Regards, Liviu Daia
Re: qsort.3 big O notation
In the most recent algorithms lecture I heard we used log for base 2, ln for base e, and lg for base 10. But asymptotically the base doesn't matter and the notation coventions differ. So I'd also go for consistency with other documentation. On March 3, 2015 5:48:20 PM CET, frantisek holop min...@obiit.org wrote: Joerg Sonnenberger, 03 Mar 2015 17:28: On Tue, Mar 03, 2015 at 05:02:39PM +0100, frantisek holop wrote: i leave the battle about lg vs log to others, but i prefer 'log' as there is a man page for that and there is none for 'lg'... If anything, it should be log because that is the name of the mathematical function. libm is completely irrelevant in this context. 'lg' is also a valid name (altough i admit i didn't know, i was used to log2) https://en.wikipedia.org/wiki/Logarithm#Particular_bases as Tedu pointed out lg = log2 and lg != log but i think my point is still kind of valid, as there is log2(3) and no lg(3). i find it relevant that libm should also use the most common, easiest names where possible... it is kind of nice to be able to do 'man log2' after reading 'man qsort', a kind of indirect cross reference. -f -- illiterate? write for a free brochure! -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: qsort.3 big O notation
Liviu Daia, 03 Mar 2015 19:26: 'lg' is also a valid name (altough i admit i didn't know, i was used to log2) https://en.wikipedia.org/wiki/Logarithm#Particular_bases as Tedu pointed out lg = log2 and lg != log Actually, that isn't what Tedu said, and it isn't the generally accepted convention. The usual convention is: my mistake. * log = ln = log_e * lg = log_10 As somebody else points out, they differ from each other by multiplicative constants, so either are correct for O-notation. (Full disclosure: I'm a mathematician. :)) yes, these are the ISO notations from that wikipedia page. that Other notations for binary are quite liberal (ld, log, log2, lg) if all is the same, then i find 'log' the most readable in a man page. -f -- all computers wait at the same speed.
Re: Questions about 802.11n support
From: T. Jameson Little beatgam...@gmail.com Date: Tue, 3 Mar 2015 23:44:44 -0700 From what I've been able to gather, there is no 802.11n support in OpenBSD because more work is needed in ieee80211(9). I would greatly appreciate it if someone could answer a few questions for me: * Is anyone working on this? * If so, is there any way that I could help? * If not, who would be the best to ask about where to get started? Nobody is really working on this. For most developers 11a/11g seems to be good enough. * How much work is required? Is the work required in the order of days, weeks, months? Depends. 11n station support is probably something of the order of days to a couple of -weeks. AP support is likely to be significantly more work. * Would parts of FreeBSD's implementation be useful, or are the two network stacks different enough that a new implementation is required? The OpenBSD 802.11 stack already has 11n bits in it. They have not really been tested though, so more fixes will be necessay. I don't think the FreeBSD code is going to help much. I expect most of the work to be in driver code. I'm a relatively competent C programmer, but I have very little experience with kernel code, much less network protocols. I would like to use OpenBSD as an access point, but I need wireless-n @ 5GHz in order to do so, so I'm motivated enough to allocate some time for testing and even writing code. I could probably also supply some basic hardware if that would help, though I don't have a big budget. I don't want to discourage you, but AP support for 11n will be quite an effort. Even if somebody gets 11n to work, I think it will be hard work to make it work well. Some people here will claim that OpenBSD 11a/11g APs don't really work very well.
Questions about 802.11n support
From what I've been able to gather, there is no 802.11n support in OpenBSD because more work is needed in ieee80211(9). I would greatly appreciate it if someone could answer a few questions for me: * Is anyone working on this? * If so, is there any way that I could help? * If not, who would be the best to ask about where to get started? * How much work is required? Is the work required in the order of days, weeks, months? * Would parts of FreeBSD's implementation be useful, or are the two network stacks different enough that a new implementation is required? I'm a relatively competent C programmer, but I have very little experience with kernel code, much less network protocols. I would like to use OpenBSD as an access point, but I need wireless-n @ 5GHz in order to do so, so I'm motivated enough to allocate some time for testing and even writing code. I could probably also supply some basic hardware if that would help, though I don't have a big budget.
errata for X server infoleak
Patches are now available to fix an information leak in the XkbSetGeometry
request of X servers. For more information, see the X.org advisory.
We experienced a slight delay getting patches out, as you can see from the
date in the patch. This is a comparatively minor issue so we didn't rush
things until correctly signed patches were available.
http://www.x.org/wiki/Development/Security/Advisory-2015-02-10/
http://ftp.openbsd.org/pub/OpenBSD/patches/5.5/common/021_xserver.patch.sig
http://ftp.openbsd.org/pub/OpenBSD/patches/5.6/common/016_xserver.patch.sig
untrusted comment: signature from openbsd 5.6 base private key
RWR0EANmo9nqholgu2GQCCaaJuP9HvfU/V5+SgCtPaxbMZfHJRNbbCXzdsIWAL0Dfr9kMeNbiOs21lUgA4Ej3AFsptAdQsB9JQk=
OpenBSD 5.6 errata 16, February 20, 2015:
Information leak in the XkbSetGeometry request of X servers
Olivier Fourdan from Red Hat has discovered a protocol handling issue
in the way the X server code base handles the XkbSetGeometry request.
Apply patch using:
signify -Vep /etc/signify/openbsd-56-base.pub -x 016_xserver.patch.sig \
-m - | (cd /usr/xenocara patch -p0)
Then build and install a new xserver:
cd /usr/xenocara/xserver
make -f Makefile.bsd-wrapper obj
make -f Makefile.bsd-wrapper build
Index: xserver/xkb/xkb.c
diff -u xserver/xkb/xkb.c:1.10 xenocara/xserver/xkb/xkb.c:1.10.2.1
--- xserver/xkb/xkb.c:1.10 Fri May 2 21:27:51 2014
+++ xserver/xkb/xkb.c Thu Feb 12 08:29:20 2015
@@ -4957,26 +4957,29 @@
/******/
-static char *
-_GetCountedString(char **wire_inout, Bool swap)
+static Status
+_GetCountedString(char **wire_inout, ClientPtr client, char **str)
{
-char *wire, *str;
-CARD16 len, *plen;
+char *wire, *next;
+CARD16 len;
wire = *wire_inout;
-plen = (CARD16 *) wire;
-if (swap) {
-swaps(plen);
-}
-len = *plen;
-str = malloc(len + 1);
-if (str) {
-memcpy(str, wire[2], len);
-str[len] = '\0';
+len = *(CARD16 *) wire;
+if (client-swapped) {
+swaps(len);
}
-wire += XkbPaddedSize(len + 2);
-*wire_inout = wire;
-return str;
+next = wire + XkbPaddedSize(len + 2);
+/* Check we're still within the size of the request */
+if (client-req_len
+bytes_to_int32(next - (char *) client-requestBuffer))
+return BadValue;
+*str = malloc(len + 1);
+if (!*str)
+return BadAlloc;
+memcpy(*str, wire[2], len);
+*(*str + len) = '\0';
+*wire_inout = next;
+return Success;
}
static Status
@@ -4985,25 +4988,29 @@
{
char *wire;
xkbDoodadWireDesc *dWire;
+xkbAnyDoodadWireDesc any;
+xkbTextDoodadWireDesc text;
XkbDoodadPtr doodad;
+Status status;
dWire = (xkbDoodadWireDesc *) (*wire_inout);
+any = dWire-any;
wire = (char *) dWire[1];
if (client-swapped) {
-swapl(dWire-any.name);
-swaps(dWire-any.top);
-swaps(dWire-any.left);
-swaps(dWire-any.angle);
+swapl(any.name);
+swaps(any.top);
+swaps(any.left);
+swaps(any.angle);
}
CHK_ATOM_ONLY(dWire-any.name);
-doodad = XkbAddGeomDoodad(geom, section, dWire-any.name);
+doodad = XkbAddGeomDoodad(geom, section, any.name);
if (!doodad)
return BadAlloc;
doodad-any.type = dWire-any.type;
doodad-any.priority = dWire-any.priority;
-doodad-any.top = dWire-any.top;
-doodad-any.left = dWire-any.left;
-doodad-any.angle = dWire-any.angle;
+doodad-any.top = any.top;
+doodad-any.left = any.left;
+doodad-any.angle = any.angle;
switch (doodad-any.type) {
case XkbOutlineDoodad:
case XkbSolidDoodad:
@@ -5026,15 +5033,22 @@
dWire-text.colorNdx);
return BadMatch;
}
+text = dWire-text;
if (client-swapped) {
-swaps(dWire-text.width);
-swaps(dWire-text.height);
+swaps(text.width);
+swaps(text.height);
}
-doodad-text.width = dWire-text.width;
-doodad-text.height = dWire-text.height;
+doodad-text.width = text.width;
+doodad-text.height = text.height;
doodad-text.color_ndx = dWire-text.colorNdx;
-doodad-text.text = _GetCountedString(wire, client-swapped);
-doodad-text.font = _GetCountedString(wire, client-swapped);
+status = _GetCountedString(wire, client, doodad-text.text);
+if (status != Success)
+return status;
+status = _GetCountedString(wire, client, doodad-text.font);
+if (status != Success) {
+free (doodad-text.text);
+return status;
+}
break;
case XkbIndicatorDoodad:
if (dWire-indicator.onColorNdx = geom-num_colors) {
@@ -5069,7 +5083,9 @@
}
doodad-logo.color_ndx = dWire-logo.colorNdx;
LibreSSL 2.1.4 released
We have released LibreSSL 2.1.4, which will be arriving in the LibreSSL directory of your local OpenBSD mirror soon. This release adds a number of new security features, makes building privilege-separated programs simpler, and improves the libtls API. This release also includes a binary package for convenience integrating LibreSSL on Windows platforms, and the latest source tarball is signed with GPG and signify for easier integration into existing build systems. Feedback is welcome. Bugs, patches, and features requests can be reported to tech@openbsd.org or at https://github.com/libressl-portable/portable/issues As the OpenBSD 5.7 development effort comes to a close, so does the LibreSSL 2.1.x branch. The next release will begin the 2.2.x development branch. User-visible features: * Improvements to libtls: - a new API for loading CA chains directly from memory instead of a file, allowing verification with privilege separation in a chroot without direct access to CA certificate files. - Ciphers default to TLSv1.2 with AEAD and PFS. - Improved error handling and message generation - New APIs and improved documentation * Added X509_STORE_load_mem API for loading certificates from memory. This facilitates accessing certificates from a chrooted environment. * New AEAD MAC alias allows configuring TLSv1.2 AEAD ciphers by using 'TLSv1.2+AEAD' as the cipher selection string. * New openssl(1) command 'certhash' replaces the c_rehash script. * Server-side support for TLS_FALLBACK_SCSV for compatibility with various auditor and vulnerability scanners. Code improvements: * Dead and disabled code removal including MD5, Netscape workarounds, non-POSIX IO, SCTP, RFC 3779 support, #if 0 sections, and more. * The ASN1 macros are expanded to aid readability and maintainability. * Various NULL pointer asserts removed in favor of letting the OS/signal handler catch them. * Refactored argument handling in openssl(1) for consistency and maintainability. * Support for building with OPENSSL_NO_DEPRECATED * Dozens of issues found with the Coverity scanner fixed. Security updates: - Fix a minor information leak that was introduced in t1_lib.c r1.71, whereby an additional 28 bytes of .rodata (or .data) is provided to the network. In most cases this is a non-issue since the memory content is already public. Issue found and reported by Felix Groebert of the Google Security Team. - Fixes for the following low-severity issues were integrated into LibreSSL from OpenSSL 1.0.1k: CVE-2015-0205 - DH client certificates accepted without verification CVE-2014-3570 - Bignum squaring may produce incorrect results CVE-2014-8275 - Certificate fingerprints can be modified CVE-2014-3572 - ECDHE silently downgrades to ECDH [Client] Reported by Karthikeyan Bhargavan of the PROSECCO team at INRIA. The following CVEs were fixed in earlier LibreSSL releases: CVE-2015-0206 - Memory leak handling repeated DLTS records CVE-2014-3510 - Flaw handling DTLS anonymous EC(DH) ciphersuites. The following CVEs did not apply to LibreSSL: CVE-2014-3571 - DTLS segmentation fault in dtls1_get_record CVE-2014-3569 - no-ssl3 configuration sets method to NULL CVE-2015-0204 - RSA silently downgrades to EXPORT_RSA The LibreSSL project continues improvement of the codebase to reflect modern, safe programming practices. We welcome feedback and improvements from the broader community. Thanks to all of the contributors who helped make this release possible.
Re: pax/tar/cpio: use stdout if TAPE is set to -
On Sun, Mar 1, 2015 at 12:41 AM, Dmitrij D. Czarkoff czark...@gmail.com wrote: The diff below makes tar treat - in TAPE environment variable as stdout, making it consistant with -f argument. Could be a sane default for those who have no tape device. Frankly, I think someone using TAPE=- would be *in*sane. If a program/script depends on tar writing to $TAPE (because it invokes tar without 'f' option), then it probably also writes to stdout, which will break the tar file in the suggested usage. I would *almost* rather make using tar without the -f option an error... Also, the diff has a bug: TAPE=- tar cv won't behave correctly. Philip Guenther
Async upd(4)
With much help from mpi@, I have made a first big step towards improving
upd(4). I’m not sure when tree lock ends, but I’m still happy to accept
feedback if right now isn’t the time to commit. There’s plenty more to do, but
I’d like to get this ironed out before moving on.
New behavior with this diff:
- Leverage new USB async reporting (must have up-to-date tree)
- Sensor dependencies ensure reports are gathered in useful order
- Track pending reports to minimize USB queries
- Relevant sensors immediately invalidated when battery is removed (instead of
waiting for the next refresh)
Things that may need sanity checks:
- Simplified upd_attach; the old code seemed to have redundant / confusing logic
- Integer promotion/truncation with batpres and hdata/adjust variables
Suggestions, bug reports, and feedback welcome.
--david
Index: upd.c
===
RCS file: /cvs/src/sys/dev/usb/upd.c,v
retrieving revision 1.13
diff -u -p -r1.13 upd.c
--- upd.c 11 Jan 2015 03:08:38 - 1.13
+++ upd.c 20 Feb 2015 02:28:04 -
@@ -39,44 +39,15 @@
#define DPRINTF(x)
#endif
-struct upd_usage_entry {
- uint8_t usage_pg;
- uint8_t usage_id;
- enum sensor_typesenstype;
- char*usage_name; /* sensor string */
-};
-
-static struct upd_usage_entry upd_usage_table[] = {
- { HUP_BATTERY, HUB_REL_STATEOF_CHARGE,
- SENSOR_PERCENT, RelativeStateOfCharge },
- { HUP_BATTERY, HUB_ABS_STATEOF_CHARGE,
- SENSOR_PERCENT, AbsoluteStateOfCharge },
- { HUP_BATTERY, HUB_REM_CAPACITY,
- SENSOR_PERCENT, RemainingCapacity },
- { HUP_BATTERY, HUB_FULLCHARGE_CAPACITY,
- SENSOR_PERCENT, FullChargeCapacity },
- { HUP_BATTERY, HUB_CHARGING,
- SENSOR_INDICATOR,Charging },
- { HUP_BATTERY, HUB_DISCHARGING,
- SENSOR_INDICATOR,Discharging },
- { HUP_BATTERY, HUB_BATTERY_PRESENT,
- SENSOR_INDICATOR,BatteryPresent },
- { HUP_POWER,HUP_SHUTDOWN_IMMINENT,
- SENSOR_INDICATOR,ShutdownImminent },
- { HUP_BATTERY, HUB_AC_PRESENT,
- SENSOR_INDICATOR,ACPresent },
- { HUP_BATTERY, HUB_ATRATE_TIMETOFULL,
- SENSOR_TIMEDELTA,AtRateTimeToFull }
-};
-
struct upd_report {
size_t size;
- int enabled;
+ int pending;
};
struct upd_sensor {
struct ksensor ksensor;
struct hid_item hitem;
+ struct upd_usage_entry *entry;
int attached;
};
@@ -85,6 +56,7 @@ struct upd_softc {
int sc_num_sensors;
u_intsc_max_repid;
u_intsc_max_sensors;
+ char sc_buf[256];
/* sensor framework */
struct ksensordevsc_sensordev;
@@ -93,6 +65,17 @@ struct upd_softc {
struct upd_sensor *sc_sensors;
};
+struct upd_usage_entry {
+ uint8_t usage_pg;
+ uint8_t usage_id;
+ uint8_t parent_pg;
+ uint8_t parent_id;
+ enum sensor_typesenstype;
+ char*usage_name; /* sensor string */
+ void (*update_sensor)(struct upd_softc *, struct upd_sensor *,
+ uint8_t *, int);
+};
+
int upd_match(struct device *, void *, void *);
void upd_attach(struct device *, struct device *, void *);
int upd_detach(struct device *, int);
@@ -100,8 +83,58 @@ int upd_detach(struct device *, int);
void upd_refresh(void *);
void upd_update_sensors(struct upd_softc *, uint8_t *, unsigned int, int);
void upd_intr(struct uhidev *, void *, uint);
+void upd_refresh_sensor_tree(struct upd_softc *, uint8_t, uint8_t, int);
+void upd_get_report_async_cb(void *, int, void *, int);
struct upd_usage_entry *upd_lookup_usage_entry(const struct hid_item *);
struct upd_sensor *upd_lookup_sensor(struct upd_softc *, int, int);
+void upd_update_batdep_sensor(struct upd_softc *, struct upd_sensor *,
+uint8_t *, int);
+void upd_update_sensor_value(struct upd_softc *, struct upd_sensor *,
+uint8_t *, int);
+
+/* dependency order only for developer sanity */
+static struct upd_usage_entry upd_usage_table[] = {
+ { HUP_POWER,HUP_SHUTDOWN_IMMINENT,
+ HUP_UNDEFINED, 0,
+ SENSOR_INDICATOR, ShutdownImminent,
+ upd_update_sensor_value },
+ { HUP_BATTERY, HUB_BATTERY_PRESENT,
+ HUP_UNDEFINED, 0,
+ SENSOR_INDICATOR, BatteryPresent,
+ upd_update_sensor_value },
+ { HUP_BATTERY, HUB_AC_PRESENT,
+ HUP_UNDEFINED, 0,
+ SENSOR_INDICATOR, ACPresent,
+ upd_update_sensor_value },
+ { HUP_BATTERY,
