From cindi@sac.sfbay.sun.com Tue Jul 8 13:23:13 2008 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m68KNC8E009870 for ; Tue, 8 Jul 2008 13:23:12 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m68KNA5k002094; Tue, 8 Jul 2008 13:23:12 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K3P00709FAOQI00@brm-avmta-1.central.sun.com>; Tue, 08 Jul 2008 14:23:12 -0600 (MDT) Received: from dm-sfbay-02.sfbay.sun.com ([129.146.11.31]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K3P002L9FANK450@brm-avmta-1.central.sun.com>; Tue, 08 Jul 2008 14:23:11 -0600 (MDT) Received: from sac.sfbay.sun.com (new-sac.SFBay.Sun.COM [129.146.175.65]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m68KNBMo007685; Tue, 08 Jul 2008 13:23:11 -0700 (PDT) Received: from sac.sfbay.sun.com (localhost [127.0.0.1]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m68KNAsK009865; Tue, 08 Jul 2008 13:23:10 -0700 (PDT) Received: (from cindi@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id m68KN9UO009861; Tue, 08 Jul 2008 13:23:09 -0700 (PDT) Date: Tue, 08 Jul 2008 13:23:09 -0700 (PDT) From: Cynthia McGuire Subject: Extending libnvpair for type double [PSARC/2008/428 FastTrack timeout 07/15/2008] To: PSARC-ext@sun.com Cc: robert.johnston@sun.com Message-id: <200807082023.m68KN9UO009861@sac.sfbay.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 19938 Template Version: @(#)sac_nextcase 1.66 04/17/08 SMI This information is Copyright 2008 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: Extending libnvpair for type double 1.2. Name of Document Author/Supplier: Author: Robert Johnston 1.3 Date of This Document: 08 July, 2008 4. Technical Description The key components of Solaris FMA (e.g.the fault manager and libtopo) maintain their property and state information using libnvpair. As part of the work to develop a sensor abstraction layer for FMA, we require the ability to represent analog sensor readings, which are typically expressed as floating point values. Therefore it has become necessary to extend libnvpair to allow floating point values. This case seeks to extend libnvpair with three new interfaces to : int nvlist_add_double(nvlist_t *nvl, const char *name, double val); int nvlist_lookup_double(nvlist_t *nvl , const char *name, double *); int nvpair_value_double(nvpair_t *nvpair, double *val); Because use of floating point types is discouraged in the kernel, and all of the FMA components that will be consuming these new interfaces live in userland, they will be made available via libnvpair but not in the kernel DDI. Preprocessor guards will be used to ensure the new code is not compiled into the kernel. The libnvpair(3LIB) man page will be updated to include the new functions. The man pages for the nvlist_add/lookup_* and nvpair_value_* functions all link to one of the following three man pages, respectively, which includes content that covers the various forms of the interfaces for all of the different data types: nvlist_add_boolean(3NVPAIR) nvlist_lookup_boolean(3NVPAIR) nvpair_value_byte(3NVPAIR) These three man pages will be updated to include the new interfaces for DATA_TYPE_DOUBLE. The updated man page conent is included below. Name-value Pair Library Functions nvlist_add_boolean(3NVPAIR) NAME nvlist_add_boolean, nvlist_add_boolean_value, nvlist_add_byte, nvlist_add_int8, nvlist_add_uint8, nvlist_add_int16, nvlist_add_uint16, nvlist_add_int32, nvlist_add_uint32, nvlist_add_int64, nvlist_add_uint64, nvlist_add_double, nvlist_add_string, nvlist_add_nvlist, nvlist_add_nvpair, nvlist_add_boolean_array, nvlist_add_byte_array, nvlist_add_int8_array, nvlist_add_uint8_array, nvlist_add_int16_array, nvlist_add_uint16_array, nvlist_add_int32_array, nvlist_add_uint32_array, nvlist_add_int64_array, nvlist_add_uint64_array, nvlist_add_string_array, nvlist_add_nvlist_array - add new name-value pair to nvlist_t SYNOPSIS cc [ flag... ] file... -lnvpair [ library... ] #include int nvlist_add_boolean(nvlist_t *nvl, const char *name); int nvlist_add_boolean_value(nvlist_t *nvl, const char *name, boolean_t val); int nvlist_add_byte(nvlist_t *nvl, const char *name, uchar_t val); int nvlist_add_int8(nvlist_t *nvl, const char *name, int8_t val); int nvlist_add_uint8(nvlist_t *nvl, const char *name, uint8_t val); int nvlist_add_int16(nvlist_t *nvl, const char *name, int16_t val); int nvlist_add_uint16(nvlist_t *nvl, const char *name, uint16_t val); int nvlist_add_int32(nvlist_t *nvl, const char *name, int32_t val); int nvlist_add_uint32(nvlist_t *nvl, const char *name, uint32_t val); int nvlist_add_int64(nvlist_t *nvl, const char *name, int64_t val); int nvlist_add_uint64(nvlist_t *nvl, const char *name, uint64_t val); int nvlist_add_double(nvlist_t *nvl, const char *name, double val); int nvlist_add_string(nvlist_t *nvl, const char *name, const char *val); int nvlist_add_nvlist(nvlist_t *nvl, const char *name, nvlist_t *val); int nvlist_add_nvpair(nvlist_t *nvl, nvpair_t *nvp); int nvlist_add_boolean_array(nvlist_t *nvl, const char *name, boolean_t *val, uint_t nelem); int nvlist_add_byte_array(nvlist_t *nvl, const char *name, uchar_t *val, uint_t nelem); int nvlist_add_int8_array(nvlist_t *nvl, const char *name, int8_t *val, uint_t nelem); int nvlist_add_uint8_array(nvlist_t *nvl, const char *name, uint8_t *val, uint_t nelem); int nvlist_add_int16_array(nvlist_t *nvl, const char *name, int16_t *val, uint_t nelem); int nvlist_add_uint16_array(nvlist_t *nvl, const char *name, uint16_t *val, uint_t nelem); int nvlist_add_int32_array(nvlist_t *nvl, const char *name, int32_t *val, uint_t nelem); int nvlist_add_uint32_array(nvlist_t *nvl, const char *name, uint32_t *val, uint_t nelem); int nvlist_add_int64_array(nvlist_t *nvl, const char *name, int64_t *val, uint_t nelem); int nvlist_add_uint64_array(nvlist_t *nvl, const char *name, uint64_t *val, uint_t nelem); int nvlist_add_string_array(nvlist_t *nvl, const char *name, char *const *val, uint_t nelem); int nvlist_add_nvlist_array(nvlist_t *nvl, const char *name, nvlist_t **val, uint_t nelem); PARAMETERS nvl The nvlist_t (name-value pair list) to be pro- cessed. nvp The nvpair_t (name-value pair) to be processed. name Name of the nvpair (name-value pair). nelem Number of elements in value (that is, array size). val Value or starting address of the array value. DESCRIPTION These functions add a new name-value pair to an nvlist_t. The uniqueness of nvpair name and data types follows the nvflag argument specified for nvlist_alloc(). See nvlist_alloc(3NVPAIR). If NV_UNIQUE_NAME was specified for nvflag, existing nvpairs with matching names are removed before the new nvpair is added. If NV_UNIQUE_NAME_TYPE was specified for nvflag, existing nvpairs with matching names and data types are removed before the new nvpair is added. If neither was specified for nvflag, the new nvpair is unconditionally added at the end of the list. The library preserves the order of the name-value pairs across packing, unpacking, and duplication. Multiple threads can simultaneously read the same nvlist_t, but only one thread can actively change a given nvlist_t at a time. The caller is responsible for the synchronization. The nvlist_add_boolean() function is deprecated. The nvlist_add_boolean_value() function should be used instead. RETURN VALUES These functions return 0 on success and an error value on failure. ERRORS These functions will fail if: EINVAL There is an invalid argument. ENOMEM There is insufficient memory. ATTRIBUTES See attributes(5) for descriptions of the following attri- butes: ____________________________________________________________ | ATTRIBUTE TYPE | ATTRIBUTE VALUE | |____________________________|______________________________| | Interface Stability | Evolving | |____________________________|______________________________| | MT-Level | MT-Safe | |____________________________|______________________________| SEE ALSO libnvpair(3LIB), attributes(5) Name-value Pair Library Functions nvlist_lookup_boolean(3NVPAIR) NAME nvlist_lookup_boolean, nvlist_lookup_boolean_value, nvlist_lookup_byte, nvlist_lookup_int8, nvlist_lookup_uint8, nvlist_lookup_int16, nvlist_lookup_uint16, nvlist_lookup_int32, nvlist_lookup_uint32, nvlist_lookup_int64, nvlist_lookup_uint64, nvlist_lookup_double, nvlist_lookup_string, nvlist_lookup_nvlist, nvlist_lookup_boolean_array, nvlist_lookup_byte_array, nvlist_lookup_int8_array, nvlist_lookup_uint8_array, nvlist_lookup_int16_array, nvlist_lookup_uint16_array, nvlist_lookup_int32_array, nvlist_lookup_uint32_array, nvlist_lookup_int64_array, nvlist_lookup_uint64_array, nvlist_lookup_nvlist_array, nvlist_lookup_string_array, nvlist_lookup_pairs - match name and type indicated by the interface name and retrieve data value SYNOPSIS cc [ flag... ] file... -lnvpair [ library... ] #include int nvlist_lookup_boolean(nvlist_t *nvl, const char *name); int nvlist_lookup_boolean_value(nvlist_t *nvl, const char *name, boolean_t *val); int nvlist_lookup_byte(nvlist_t *nvl, const char *name, uchar_t *val); int nvlist_lookup_int8(nvlist_t *nvl, const char *name, int8_t *val); int nvlist_lookup_uint8(nvlist_t *nvl, const char *name, uint8_t *val); int nvlist_lookup_int16(nvlist_t *nvl, const char *name, int16_t *val); int nvlist_lookup_uint16(nvlist_t *nvl, const char *name, uint16_t *val); int nvlist_lookup_int32(nvlist_t *nvl, const char *name, int32_t *val); int nvlist_lookup_uint32(nvlist_t *nvl, const char *name, uint32_t *val); int nvlist_lookup_int64(nvlist_t *nvl, const char *name, int64_t *val); int nvlist_lookup_uint64(nvlist_t *nvl, const char *name, uint64_t *val); int nvlist_lookup_double(nvlist_t *nvl , const char *name, double *); int nvlist_lookup_string(nvlist_t *nvl, const char *name, char **val); int nvlist_lookup_nvlist(nvlist_t *nvl, const char *name, nvlist_t **val); int nvlist_lookup_boolean_array(nvlist_t *nvl, const char *name, boolean_t **val, uint_t *nelem); int nvlist_lookup_byte_array(nvlist_t *nvl, const char *name, uchar_t **val, uint_t *nelem); int nvlist_lookup_int8_array(nvlist_t *nvl, const char *name, int8_t **val, uint_t *nelem); int nvlist_lookup_uint8_array(nvlist_t *nvl, const char *name, uint8_t **val, uint_t *nelem); int nvlist_lookup_int16_array(nvlist_t *nvl, const char *name, int16_t **val, uint_t *nelem); int nvlist_lookup_uint16_array(nvlist_t *nvl, const char *name, uint16_t **val, uint_t *nelem); int nvlist_lookup_int32_array(nvlist_t *nvl, const char *name, int32_t **val, uint_t *nelem); int nvlist_lookup_uint32_array(nvlist_t *nvl, const char *name, uint32_t **val, uint_t *nelem); int nvlist_lookup_int64_array(nvlist_t *nvl, const char *name, int64_t **val, uint_t *nelem); int nvlist_lookup_uint64_array(nvlist_t *nvl, const char *name, uint64_t **val, uint_t *nelem); int nvlist_lookup_string_array(nvlist_t *nvl, const char *name, char ***val, uint_t *nelem); int nvlist_lookup_nvlist_array(nvlist_t *nvl, const char *name, nvlist_t ***val, uint_t *nelem); int nvlist_lookup_pairs(nvlist_t *nvl, int flag...); PARAMETERS nvl The nvlist_t to be processed. name Name of the name-value pair to search. nelem Address to store the number of elements in value. val Address to store the starting address of the value. flag Specify bit fields defining lookup behavior: NV_FLAG_NOENTOK The retrival function will not fail if no matching name-value pair is found. DESCRIPTION These functions find the nvpair (name-value pair) that matches the name and type as indicated by the interface name. If one is found, nelem and val are modified to contain the number of elements in value and the starting address of data, respectively. These functions work for nvlists (lists of name-value pairs) allocated with NV_UNIQUE_NAME or NV_UNIQUE_NAME_TYPE speci- fied in nvlist_alloc(). (See nvlist_alloc(3NVPAIR).) If this is not the case, the function returns ENOTSUP because the list potentially contains multiple nvpairs with the same name and type. Multiple threads can simultaneously read the same nvlist_t but only one thread can actively change a given nvlist_t at a time. The caller is responsible for the synchronization. All memory required for storing the array elements, includ- ing string value, are managed by the library. References to such data remain valid until nvlist_free() is called on nvl. The nvlist_lookup_pairs() function retrieves a set of nvpairs. The arguments are a null-terminated list of pairs (data type DATA_TYPE_BOOLEAN), triples (non-array data types) or quads (array data types). The interpretation of the arguments depends on the value of type (see nvpair_type(3NVPAIR)) as follows: name Name of the name-value pair to search. type Data type (see nvpair_type(3NVPAIR)). val Address to store the starting address of the value. When using data type DATA_TYPE_BOOLEAN, the val argument is omitted. nelem Address to store the number of elements in value. Non-array data types have only one argument and nelem is omitted. The order of the arguments is name, type, [val], [nelem]. When using NV_FLAG_NOENTOK and no matching name-value pair is found, the memory pointed to by val and nelem is left untouched. RETURN VALUES These functions return 0 on success and an error value on failure. ERRORS These functions will fail if: EINVAL There is an invalid argument. ENOENT No matching name-value pair is found ENOTSUP An encode/decode method is not supported. ATTRIBUTES See attributes(5) for descriptions of the following attri- butes: ____________________________________________________________ | ATTRIBUTE TYPE | ATTRIBUTE VALUE | |____________________________|______________________________| | Interface Stability | Evolving | |____________________________|______________________________| | MT-Level | MT-Safe | |____________________________|______________________________| SEE ALSO libnvpair(3LIB), nvpair_type(3NVPAIR), attributes(5) Name-value Pair Library Functions nvpair_value_byte(3NVPAIR) NAME nvpair_value_byte, nvpair_value_boolean_value, nvpair_value_int8, nvpair_value_uint8, nvpair_value_int16, nvpair_value_uint16, nvpair_value_int32, nvpair_value_uint32, nvpair_value_int64, nvpair_value_uint64, nvpair_value_double, nvpair_value_string, nvpair_value_nvlist, nvpair_value_boolean_array, nvpair_value_byte_array, nvpair_value_int8_array, nvpair_value_uint8_array, nvpair_value_int16_array, nvpair_value_uint16_array, nvpair_value_int32_array, nvpair_value_uint32_array, nvpair_value_int64_array, nvpair_value_uint64_array, nvpair_value_string_array, nvpair_value_nvlist_array - retrieve value from a name-value pair SYNOPSIS cc [ flag... ] file... -lnvpair [ library... ] #include int nvpair_value_byte(nvpair_t *nvpair, uchar_t *val); int nvpair_value_boolean_value(nvpair_t *nvpair, boolean_t *val); int nvpair_value_int8(nvpair_t *nvpair, int8_t *val); int nvpair_value_uint8(nvpair_t *nvpair, uint8_t *val); int nvpair_value_int16(nvpair_t *nvpair, int16_t *val); int nvpair_value_uint16(nvpair_t *nvpair, uint16_t *val); int nvpair_value_int32(nvpair_t *nvpair, int32_t *val); int nvpair_value_uint32(nvpair_t *nvpair, uint32_t *val); int nvpair_value_int64(nvpair_t *nvpair, int64_t *val); int nvpair_value_uint64(nvpair_t *nvpair, uint64_t *val); int nvpair_value_double(nvpair_t *nvpair, double *val); int nvpair_value_string(nvpair_t *nvpair, char **val); int nvpair_value_nvlist(nvpair_t *nvpair, nvlist_t **val); int nvpair_value_boolean_array(nvpair_t *nvpair, boolean_t **val, uint_t *nelem); int nvpair_value_byte_array(nvpair_t *nvpair, uchar_t **val, uint_t *nelem); int nvpair_value_int8_array(nvpair_t *nvpair, int8_t **val, uint_t *nelem); int nvpair_value_uint8_array(nvpair_t *nvpair, uint8_t **val, uint_t *nelem); int nvpair_value_int16_array(nvpair_t *nvpair, int16_t **val, uint_t *nelem); int nvpair_value_uint16_array(nvpair_t *nvpair, uint16_t **val, uint_t *nelem); int nvpair_value_int32_array(nvpair_t *nvpair, int32_t **val, uint_t *nelem); int nvpair_value_uint32_array(nvpair_t *nvpair, uint32_t **val, uint_t *nelem); int nvpair_value_int64_array(nvpair_t *nvpair, int64_t **val, uint_t *nelem); int nvpair_value_uint64_array(nvpair_t *nvpair, uint64_t **val, uint_t *nelem); int nvpair_value_string_array(nvpair_t *nvpair, char ***val, uint_t *nelem); int nvpair_value_nvlist_array(nvpair_t *nvpair, nvlist_t ***val, uint_t *nelem); PARAMETERS nvpair Name-value pair to be processed. nelem Address to store the number of elements in value. val Address to store the value or the starting address of the array value. DESCRIPTION These functions retrieve the value of nvpair. The data type of nvpair must match the interface name for the call to be successful. There is no nvpair_value_boolean(); the existence of the name implies the value is true. For array data types, including string, the memory contain- ing the data is managed by the library and references to the value remains valid until nvlist_free() is called on the nvlist_t from which nvpair is obtained. See nvlist_free(3NVPAIR). The value of an nvpair may not be retrieved after the nvpair has been removed from or replaced in an nvlist. Replacement can occur during pair additions to nvlists created with NV_UNIQUE_NAME_TYPE and NV_UNIQUE_NAME. See nvlist_alloc(3NVPAIR). RETURN VALUES These functions return 0 on success and an error value on failure. ERRORS These functions will fail if: EINVAL Either one of the arguments is NULL or the type of nvpair does not match the function name. ATTRIBUTES See attributes(5) for descriptions of the following attri- butes: ____________________________________________________________ | ATTRIBUTE TYPE | ATTRIBUTE VALUE | |____________________________|______________________________| | Interface Stability | Evolving | |____________________________|______________________________| | MT-Level | MT-Safe | |____________________________|______________________________| SEE ALSO libnvpair(3LIB), nvlist_alloc(3NVPAIR), attributes(5) These interfaces are Committed and seek patch binding. 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: ON 6.5. ARC review type: FastTrack 6.6. ARC Exposure: open From gdamore@sun.com Tue Jul 8 14:49:48 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m68LnlTv013485 for ; Tue, 8 Jul 2008 14:49:48 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m68Lnk2Y025116 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 8 Jul 2008 22:49:46 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K3P0020JJAXGI00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.Com); Tue, 08 Jul 2008 14:49:45 -0700 (PDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K3P00M4HJAXEUF0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.Com); Tue, 08 Jul 2008 14:49:45 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m68LnjkU001878 for ; Tue, 08 Jul 2008 14:49:45 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K3P00H01J1UMQ00@fe-sfbay-09.sun.com> (original mail from gdamore@sun.com) for PSARC-ext@Sun.Com (ORCPT PSARC-ext@Sun.Com); Tue, 08 Jul 2008 14:49:45 -0700 (PDT) Received: from [192.168.251.106] ([76.174.83.55]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K3P000EXJAVWD70@fe-sfbay-09.sun.com>; Tue, 08 Jul 2008 14:49:43 -0700 (PDT) Date: Tue, 08 Jul 2008 14:46:47 -0700 From: "Garrett D'Amore" Subject: Re: Extending libnvpair for type double [PSARC/2008/428 FastTrack timeout 07/15/2008] In-reply-to: <200807082023.m68KN9UO009861@sac.sfbay.sun.com> Sender: Garrett.Damore@sun.com To: Cynthia McGuire Cc: PSARC-ext@sun.com, Robert.Johnston@sun.com Message-id: <4873E047.50208@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200807082023.m68KN9UO009861@sac.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.6 (X11/20071023) Status: RO Content-Length: 21692 I wonder if the divergence between the kernel and userland implementations might become a source of problems later. For sensor data, wouldn't it be easier to simply change the units? (This is what I've done in situations like this -- examples are battery voltages -- express the result in mV or uV instead of V.) That way consumers can be either in the kernel or userland -- especially if at some point in the future you wind up having a kernel entity that wants to participate in this stuff. Similar in 802.11, express frequencies as Hz instead of MHz, etc. Consider all this a weak objection, with a possible recommendation to look for alternatives. If there are compelling reasons why just changing the units won't work, then I've no objection. -- Garrett Cynthia McGuire wrote: > Template Version: @(#)sac_nextcase 1.66 04/17/08 SMI > This information is Copyright 2008 Sun Microsystems > 1. Introduction > 1.1. Project/Component Working Name: > Extending libnvpair for type double > 1.2. Name of Document Author/Supplier: > Author: Robert Johnston > 1.3 Date of This Document: > 08 July, 2008 > 4. Technical Description > > The key components of Solaris FMA (e.g.the fault manager and libtopo) > maintain their property and state information using libnvpair. As part of the > work to develop a sensor abstraction layer for FMA, we require the ability > to represent analog sensor readings, which are typically expressed as > floating point values. Therefore it has become necessary to extend libnvpair > to allow floating point values. > > This case seeks to extend libnvpair with three new interfaces to : > > int nvlist_add_double(nvlist_t *nvl, const char *name, double val); > int nvlist_lookup_double(nvlist_t *nvl , const char *name, double *); > int nvpair_value_double(nvpair_t *nvpair, double *val); > > Because use of floating point types is discouraged in the kernel, and all of > the FMA components that will be consuming these new interfaces live in > userland, they will be made available via libnvpair but not in the kernel DDI. > Preprocessor guards will be used to ensure the new code is not compiled > into the kernel. > > The libnvpair(3LIB) man page will be updated to include the new functions. > > The man pages for the nvlist_add/lookup_* and nvpair_value_* functions all > link to one of the following three man pages, respectively, which > includes content that covers the various forms of the interfaces for all > of the different data types: > > nvlist_add_boolean(3NVPAIR) > nvlist_lookup_boolean(3NVPAIR) > nvpair_value_byte(3NVPAIR) > > These three man pages will be updated to include the new interfaces for > DATA_TYPE_DOUBLE. The updated man page conent is included below. > > > Name-value Pair Library Functions nvlist_add_boolean(3NVPAIR) > > NAME > nvlist_add_boolean, nvlist_add_boolean_value, > nvlist_add_byte, nvlist_add_int8, nvlist_add_uint8, > nvlist_add_int16, nvlist_add_uint16, nvlist_add_int32, > nvlist_add_uint32, nvlist_add_int64, nvlist_add_uint64, > nvlist_add_double, nvlist_add_string, nvlist_add_nvlist, > nvlist_add_nvpair, nvlist_add_boolean_array, > nvlist_add_byte_array, nvlist_add_int8_array, > nvlist_add_uint8_array, nvlist_add_int16_array, > nvlist_add_uint16_array, nvlist_add_int32_array, > nvlist_add_uint32_array, nvlist_add_int64_array, > nvlist_add_uint64_array, nvlist_add_string_array, > nvlist_add_nvlist_array - add new name-value pair to nvlist_t > > SYNOPSIS > cc [ flag... ] file... -lnvpair [ library... ] > #include > > int nvlist_add_boolean(nvlist_t *nvl, const char *name); > > int nvlist_add_boolean_value(nvlist_t *nvl, > const char *name, boolean_t val); > > int nvlist_add_byte(nvlist_t *nvl, const char *name, > uchar_t val); > > int nvlist_add_int8(nvlist_t *nvl, const char *name, > int8_t val); > > int nvlist_add_uint8(nvlist_t *nvl, const char *name, > uint8_t val); > > int nvlist_add_int16(nvlist_t *nvl, const char *name, > int16_t val); > > int nvlist_add_uint16(nvlist_t *nvl, const char *name, > uint16_t val); > > int nvlist_add_int32(nvlist_t *nvl, const char *name, > int32_t val); > > int nvlist_add_uint32(nvlist_t *nvl, const char *name, > uint32_t val); > > int nvlist_add_int64(nvlist_t *nvl, const char *name, > int64_t val); > > int nvlist_add_uint64(nvlist_t *nvl, const char *name, > uint64_t val); > > int nvlist_add_double(nvlist_t *nvl, const char *name, > double val); > > int nvlist_add_string(nvlist_t *nvl, const char *name, > const char *val); > > int nvlist_add_nvlist(nvlist_t *nvl, const char *name, > nvlist_t *val); > > int nvlist_add_nvpair(nvlist_t *nvl, nvpair_t *nvp); > > int nvlist_add_boolean_array(nvlist_t *nvl, const char *name, > boolean_t *val, uint_t nelem); > > int nvlist_add_byte_array(nvlist_t *nvl, const char *name, > uchar_t *val, uint_t nelem); > > int nvlist_add_int8_array(nvlist_t *nvl, const char *name, > int8_t *val, uint_t nelem); > > int nvlist_add_uint8_array(nvlist_t *nvl, const char *name, > uint8_t *val, uint_t nelem); > > int nvlist_add_int16_array(nvlist_t *nvl, const char *name, > int16_t *val, uint_t nelem); > > int nvlist_add_uint16_array(nvlist_t *nvl, const char *name, > uint16_t *val, uint_t nelem); > > int nvlist_add_int32_array(nvlist_t *nvl, const char *name, > int32_t *val, uint_t nelem); > > int nvlist_add_uint32_array(nvlist_t *nvl, const char *name, > uint32_t *val, uint_t nelem); > > int nvlist_add_int64_array(nvlist_t *nvl, const char *name, > int64_t *val, uint_t nelem); > > int nvlist_add_uint64_array(nvlist_t *nvl, const char *name, > uint64_t *val, uint_t nelem); > > int nvlist_add_string_array(nvlist_t *nvl, const char *name, > char *const *val, uint_t nelem); > > int nvlist_add_nvlist_array(nvlist_t *nvl, const char *name, > nvlist_t **val, uint_t nelem); > > PARAMETERS > nvl The nvlist_t (name-value pair list) to be pro- > cessed. > > nvp The nvpair_t (name-value pair) to be processed. > > name Name of the nvpair (name-value pair). > > nelem Number of elements in value (that is, array size). > > val Value or starting address of the array value. > > DESCRIPTION > These functions add a new name-value pair to an nvlist_t. > The uniqueness of nvpair name and data types follows the > nvflag argument specified for nvlist_alloc(). See > nvlist_alloc(3NVPAIR). > > If NV_UNIQUE_NAME was specified for nvflag, existing nvpairs > with matching names are removed before the new nvpair is > added. > > If NV_UNIQUE_NAME_TYPE was specified for nvflag, existing > nvpairs with matching names and data types are removed > before the new nvpair is added. > > If neither was specified for nvflag, the new nvpair is > unconditionally added at the end of the list. The library > preserves the order of the name-value pairs across packing, > unpacking, and duplication. > > Multiple threads can simultaneously read the same nvlist_t, > but only one thread can actively change a given nvlist_t at > a time. The caller is responsible for the synchronization. > > The nvlist_add_boolean() function is deprecated. The > nvlist_add_boolean_value() function should be used instead. > > RETURN VALUES > These functions return 0 on success and an error value on > failure. > > ERRORS > These functions will fail if: > > EINVAL There is an invalid argument. > > ENOMEM There is insufficient memory. > > ATTRIBUTES > See attributes(5) for descriptions of the following attri- > butes: > > ____________________________________________________________ > | ATTRIBUTE TYPE | ATTRIBUTE VALUE | > |____________________________|______________________________| > | Interface Stability | Evolving | > |____________________________|______________________________| > | MT-Level | MT-Safe | > |____________________________|______________________________| > > SEE ALSO > libnvpair(3LIB), attributes(5) > > > > Name-value Pair Library Functions nvlist_lookup_boolean(3NVPAIR) > > NAME > nvlist_lookup_boolean, nvlist_lookup_boolean_value, > nvlist_lookup_byte, nvlist_lookup_int8, nvlist_lookup_uint8, > nvlist_lookup_int16, nvlist_lookup_uint16, > nvlist_lookup_int32, nvlist_lookup_uint32, > nvlist_lookup_int64, nvlist_lookup_uint64, > nvlist_lookup_double, nvlist_lookup_string, > nvlist_lookup_nvlist, nvlist_lookup_boolean_array, > nvlist_lookup_byte_array, nvlist_lookup_int8_array, > nvlist_lookup_uint8_array, nvlist_lookup_int16_array, > nvlist_lookup_uint16_array, nvlist_lookup_int32_array, > nvlist_lookup_uint32_array, nvlist_lookup_int64_array, > nvlist_lookup_uint64_array, nvlist_lookup_nvlist_array, > nvlist_lookup_string_array, > nvlist_lookup_pairs - match name and type indicated by the > interface name and retrieve data value > > SYNOPSIS > cc [ flag... ] file... -lnvpair [ library... ] > #include > > int nvlist_lookup_boolean(nvlist_t *nvl, const char *name); > > int nvlist_lookup_boolean_value(nvlist_t *nvl, > const char *name, boolean_t *val); > > int nvlist_lookup_byte(nvlist_t *nvl, const char *name, > uchar_t *val); > > int nvlist_lookup_int8(nvlist_t *nvl, const char *name, > int8_t *val); > > int nvlist_lookup_uint8(nvlist_t *nvl, const char *name, > uint8_t *val); > > int nvlist_lookup_int16(nvlist_t *nvl, const char *name, > int16_t *val); > > int nvlist_lookup_uint16(nvlist_t *nvl, const char *name, > uint16_t *val); > > int nvlist_lookup_int32(nvlist_t *nvl, const char *name, > int32_t *val); > > int nvlist_lookup_uint32(nvlist_t *nvl, const char *name, > uint32_t *val); > > int nvlist_lookup_int64(nvlist_t *nvl, const char *name, > int64_t *val); > > int nvlist_lookup_uint64(nvlist_t *nvl, const char *name, > uint64_t *val); > > int nvlist_lookup_double(nvlist_t *nvl , const char *name, > double *); > > int nvlist_lookup_string(nvlist_t *nvl, const char *name, > char **val); > > int nvlist_lookup_nvlist(nvlist_t *nvl, const char *name, > nvlist_t **val); > > int nvlist_lookup_boolean_array(nvlist_t *nvl, const char *name, > boolean_t **val, uint_t *nelem); > > int nvlist_lookup_byte_array(nvlist_t *nvl, const char *name, > uchar_t **val, uint_t *nelem); > > int nvlist_lookup_int8_array(nvlist_t *nvl, const char *name, > int8_t **val, uint_t *nelem); > > int nvlist_lookup_uint8_array(nvlist_t *nvl, const char *name, > uint8_t **val, uint_t *nelem); > > int nvlist_lookup_int16_array(nvlist_t *nvl, const char *name, > int16_t **val, uint_t *nelem); > > int nvlist_lookup_uint16_array(nvlist_t *nvl, const char *name, > uint16_t **val, uint_t *nelem); > > int nvlist_lookup_int32_array(nvlist_t *nvl, const char *name, > int32_t **val, uint_t *nelem); > > int nvlist_lookup_uint32_array(nvlist_t *nvl, const char *name, > uint32_t **val, uint_t *nelem); > > int nvlist_lookup_int64_array(nvlist_t *nvl, const char *name, > int64_t **val, uint_t *nelem); > > int nvlist_lookup_uint64_array(nvlist_t *nvl, const char *name, > uint64_t **val, uint_t *nelem); > > int nvlist_lookup_string_array(nvlist_t *nvl, const char *name, > char ***val, uint_t *nelem); > > int nvlist_lookup_nvlist_array(nvlist_t *nvl, const char *name, > nvlist_t ***val, uint_t *nelem); > > int nvlist_lookup_pairs(nvlist_t *nvl, int flag...); > > PARAMETERS > nvl The nvlist_t to be processed. > > name Name of the name-value pair to search. > > nelem Address to store the number of elements in value. > > val Address to store the starting address of the value. > > flag Specify bit fields defining lookup behavior: > > NV_FLAG_NOENTOK The retrival function will not > fail if no matching name-value > pair is found. > > DESCRIPTION > These functions find the nvpair (name-value pair) that > matches the name and type as indicated by the interface > name. If one is found, nelem and val are modified to contain > the number of elements in value and the starting address of > data, respectively. > > These functions work for nvlists (lists of name-value pairs) > allocated with NV_UNIQUE_NAME or NV_UNIQUE_NAME_TYPE speci- > fied in nvlist_alloc(). (See nvlist_alloc(3NVPAIR).) If this > is not the case, the function returns ENOTSUP because the > list potentially contains multiple nvpairs with the same > name and type. > > Multiple threads can simultaneously read the same nvlist_t > but only one thread can actively change a given nvlist_t at > a time. The caller is responsible for the synchronization. > > All memory required for storing the array elements, includ- > ing string value, are managed by the library. References to > such data remain valid until nvlist_free() is called on nvl. > > The nvlist_lookup_pairs() function retrieves a set of > nvpairs. The arguments are a null-terminated list of pairs > (data type DATA_TYPE_BOOLEAN), triples (non-array data > types) or quads (array data types). The interpretation of > the arguments depends on the value of type (see > nvpair_type(3NVPAIR)) as follows: > > name Name of the name-value pair to search. > > type Data type (see nvpair_type(3NVPAIR)). > > val Address to store the starting address of the value. > When using data type DATA_TYPE_BOOLEAN, the val > argument is omitted. > > nelem Address to store the number of elements in value. > Non-array data types have only one argument and > nelem is omitted. > > The order of the arguments is name, type, [val], [nelem]. > > When using NV_FLAG_NOENTOK and no matching name-value pair > is found, the memory pointed to by val and nelem is left > untouched. > > RETURN VALUES > These functions return 0 on success and an error value on > failure. > > ERRORS > These functions will fail if: > > EINVAL There is an invalid argument. > > ENOENT No matching name-value pair is found > > ENOTSUP An encode/decode method is not supported. > > ATTRIBUTES > See attributes(5) for descriptions of the following attri- > butes: > > ____________________________________________________________ > | ATTRIBUTE TYPE | ATTRIBUTE VALUE | > |____________________________|______________________________| > | Interface Stability | Evolving | > |____________________________|______________________________| > | MT-Level | MT-Safe | > |____________________________|______________________________| > > SEE ALSO > libnvpair(3LIB), nvpair_type(3NVPAIR), attributes(5) > > > Name-value Pair Library Functions nvpair_value_byte(3NVPAIR) > > NAME > nvpair_value_byte, nvpair_value_boolean_value, > nvpair_value_int8, nvpair_value_uint8, nvpair_value_int16, > nvpair_value_uint16, nvpair_value_int32, > nvpair_value_uint32, nvpair_value_int64, > nvpair_value_uint64, nvpair_value_double, > nvpair_value_string, nvpair_value_nvlist, > nvpair_value_boolean_array, nvpair_value_byte_array, > nvpair_value_int8_array, nvpair_value_uint8_array, > nvpair_value_int16_array, nvpair_value_uint16_array, > nvpair_value_int32_array, nvpair_value_uint32_array, > nvpair_value_int64_array, nvpair_value_uint64_array, > nvpair_value_string_array, > nvpair_value_nvlist_array - retrieve value from a name-value > pair > > SYNOPSIS > cc [ flag... ] file... -lnvpair [ library... ] > #include > > int nvpair_value_byte(nvpair_t *nvpair, uchar_t *val); > > int nvpair_value_boolean_value(nvpair_t *nvpair, > boolean_t *val); > > int nvpair_value_int8(nvpair_t *nvpair, int8_t *val); > > int nvpair_value_uint8(nvpair_t *nvpair, uint8_t *val); > > int nvpair_value_int16(nvpair_t *nvpair, int16_t *val); > > int nvpair_value_uint16(nvpair_t *nvpair, uint16_t *val); > > int nvpair_value_int32(nvpair_t *nvpair, int32_t *val); > > int nvpair_value_uint32(nvpair_t *nvpair, uint32_t *val); > > int nvpair_value_int64(nvpair_t *nvpair, int64_t *val); > > int nvpair_value_uint64(nvpair_t *nvpair, uint64_t *val); > > int nvpair_value_double(nvpair_t *nvpair, double *val); > > int nvpair_value_string(nvpair_t *nvpair, char **val); > > int nvpair_value_nvlist(nvpair_t *nvpair, nvlist_t **val); > > int nvpair_value_boolean_array(nvpair_t *nvpair, > boolean_t **val, uint_t *nelem); > > int nvpair_value_byte_array(nvpair_t *nvpair, uchar_t **val, > uint_t *nelem); > > int nvpair_value_int8_array(nvpair_t *nvpair, int8_t **val, > uint_t *nelem); > > int nvpair_value_uint8_array(nvpair_t *nvpair, uint8_t **val, > uint_t *nelem); > > int nvpair_value_int16_array(nvpair_t *nvpair, int16_t **val, > uint_t *nelem); > > int nvpair_value_uint16_array(nvpair_t *nvpair, > uint16_t **val, uint_t *nelem); > > int nvpair_value_int32_array(nvpair_t *nvpair, > int32_t **val, uint_t *nelem); > > int nvpair_value_uint32_array(nvpair_t *nvpair, > uint32_t **val, uint_t *nelem); > > int nvpair_value_int64_array(nvpair_t *nvpair, > int64_t **val, uint_t *nelem); > > int nvpair_value_uint64_array(nvpair_t *nvpair, > uint64_t **val, uint_t *nelem); > > int nvpair_value_string_array(nvpair_t *nvpair, > char ***val, uint_t *nelem); > > int nvpair_value_nvlist_array(nvpair_t *nvpair, > nvlist_t ***val, uint_t *nelem); > > PARAMETERS > nvpair Name-value pair to be processed. > > nelem Address to store the number of elements in value. > > val Address to store the value or the starting address > of the array value. > > DESCRIPTION > These functions retrieve the value of nvpair. The data type > of nvpair must match the interface name for the call to be > successful. > > There is no nvpair_value_boolean(); the existence of the > name implies the value is true. > > For array data types, including string, the memory contain- > ing the data is managed by the library and references to the > value remains valid until nvlist_free() is called on the > nvlist_t from which nvpair is obtained. See > nvlist_free(3NVPAIR). > > The value of an nvpair may not be retrieved after the nvpair > has been removed from or replaced in an nvlist. Replacement > can occur during pair additions to nvlists created with > NV_UNIQUE_NAME_TYPE and NV_UNIQUE_NAME. See > nvlist_alloc(3NVPAIR). > > RETURN VALUES > These functions return 0 on success and an error value on > failure. > > ERRORS > These functions will fail if: > > EINVAL Either one of the arguments is NULL or the type of > nvpair does not match the function name. > > ATTRIBUTES > See attributes(5) for descriptions of the following attri- > butes: > > > ____________________________________________________________ > | ATTRIBUTE TYPE | ATTRIBUTE VALUE | > |____________________________|______________________________| > | Interface Stability | Evolving | > |____________________________|______________________________| > | MT-Level | MT-Safe | > |____________________________|______________________________| > > SEE ALSO > libnvpair(3LIB), nvlist_alloc(3NVPAIR), attributes(5) > > > > > These interfaces are Committed and seek patch binding. > > 6. Resources and Schedule > 6.4. Steering Committee requested information > 6.4.1. Consolidation C-team Name: > ON > 6.5. ARC review type: FastTrack > 6.6. ARC Exposure: open > > From Robert.Johnston@sun.com Tue Jul 8 15:07:37 2008 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m68M7aoZ013970 for ; Tue, 8 Jul 2008 15:07:36 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m68M7WW8028558 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 8 Jul 2008 15:07:36 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K3P00403K4FHP00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.Com); Tue, 08 Jul 2008 15:07:27 -0700 (PDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K3P00M48K4FF2E0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.Com); Tue, 08 Jul 2008 15:07:27 -0700 (PDT) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m68M7Rvj003617 for ; Tue, 08 Jul 2008 22:07:27 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K3P00801J87KS00@mail-amer.sun.com> (original mail from Robert.Johnston@Sun.COM) for PSARC-ext@Sun.Com (ORCPT PSARC-ext@Sun.Com); Tue, 08 Jul 2008 16:07:27 -0600 (MDT) Received: from [192.168.2.2] ([67.181.50.241]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K3P008A8K4BD090@mail-amer.sun.com>; Tue, 08 Jul 2008 16:07:24 -0600 (MDT) Date: Tue, 08 Jul 2008 15:07:23 -0700 From: Rob Johnston Subject: Re: Extending libnvpair for type double [PSARC/2008/428 FastTrack timeout 07/15/2008] In-reply-to: <4873E047.50208@sun.com> Sender: Robert.Johnston@sun.com To: "Garrett D'Amore" Cc: Cynthia McGuire , PSARC-ext@sun.com Message-id: <4873E51B.8010604@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200807082023.m68KN9UO009861@sac.sfbay.sun.com> <4873E047.50208@sun.com> User-Agent: Thunderbird 2.0.0.14 (X11/20080602) Status: RO Content-Length: 22896 Garrett D'Amore wrote: > I wonder if the divergence between the kernel and userland > implementations might become a source of problems later. For sensor > data, wouldn't it be easier to simply change the units? (This is what > I've done in situations like this -- examples are battery voltages -- > express the result in mV or uV instead of V.) That way consumers can be > either in the kernel or userland -- especially if at some point in the > future you wind up having a kernel entity that wants to participate in > this stuff. Similar in 802.11, express frequencies as Hz instead of > MHz, etc. If we were dealing with a small, known set of unit types this would definitely be a reasonable option. The problem is that we're extending libtopo to generically support a very large variety of sensors with many different types of units. Adding code to convert all of those cases to use a smaller unit type to remove the fractional component would be quite burdensome. Additionally, not all of the unit types have nice power of ten metric conversion rules (english measurements, temperature units, etc...) > Consider all this a weak objection, with a possible recommendation to > look for alternatives. If there are compelling reasons why just > changing the units won't work, then I've no objection. Cool - thanks, rob > > -- Garrett > > Cynthia McGuire wrote: >> Template Version: @(#)sac_nextcase 1.66 04/17/08 SMI >> This information is Copyright 2008 Sun Microsystems >> 1. Introduction >> 1.1. Project/Component Working Name: >> Extending libnvpair for type double >> 1.2. Name of Document Author/Supplier: >> Author: Robert Johnston >> 1.3 Date of This Document: >> 08 July, 2008 >> 4. Technical Description >> >> The key components of Solaris FMA (e.g.the fault manager and libtopo) >> maintain their property and state information using libnvpair. As >> part of the >> work to develop a sensor abstraction layer for FMA, we require the >> ability >> to represent analog sensor readings, which are typically expressed as >> floating point values. Therefore it has become necessary to extend >> libnvpair >> to allow floating point values. >> >> This case seeks to extend libnvpair with three new interfaces to >> : >> >> int nvlist_add_double(nvlist_t *nvl, const char *name, double val); >> int nvlist_lookup_double(nvlist_t *nvl , const char *name, double *); >> int nvpair_value_double(nvpair_t *nvpair, double *val); >> >> Because use of floating point types is discouraged in the kernel, and >> all of >> the FMA components that will be consuming these new interfaces live in >> userland, they will be made available via libnvpair but not in the >> kernel DDI. >> Preprocessor guards will be used to ensure the new code is not compiled >> into the kernel. >> >> The libnvpair(3LIB) man page will be updated to include the new >> functions. >> >> The man pages for the nvlist_add/lookup_* and nvpair_value_* functions >> all >> link to one of the following three man pages, respectively, which >> includes content that covers the various forms of the interfaces for all >> of the different data types: >> >> nvlist_add_boolean(3NVPAIR) >> nvlist_lookup_boolean(3NVPAIR) >> nvpair_value_byte(3NVPAIR) >> >> These three man pages will be updated to include the new interfaces for >> DATA_TYPE_DOUBLE. The updated man page conent is included below. >> >> >> Name-value Pair Library Functions nvlist_add_boolean(3NVPAIR) >> >> NAME >> nvlist_add_boolean, nvlist_add_boolean_value, >> nvlist_add_byte, nvlist_add_int8, nvlist_add_uint8, >> nvlist_add_int16, nvlist_add_uint16, nvlist_add_int32, >> nvlist_add_uint32, nvlist_add_int64, nvlist_add_uint64, >> nvlist_add_double, nvlist_add_string, nvlist_add_nvlist, >> nvlist_add_nvpair, nvlist_add_boolean_array, >> nvlist_add_byte_array, nvlist_add_int8_array, >> nvlist_add_uint8_array, nvlist_add_int16_array, >> nvlist_add_uint16_array, nvlist_add_int32_array, >> nvlist_add_uint32_array, nvlist_add_int64_array, >> nvlist_add_uint64_array, nvlist_add_string_array, >> nvlist_add_nvlist_array - add new name-value pair to nvlist_t >> >> SYNOPSIS >> cc [ flag... ] file... -lnvpair [ library... ] >> #include >> >> int nvlist_add_boolean(nvlist_t *nvl, const char *name); >> >> int nvlist_add_boolean_value(nvlist_t *nvl, >> const char *name, boolean_t val); >> >> int nvlist_add_byte(nvlist_t *nvl, const char *name, >> uchar_t val); >> >> int nvlist_add_int8(nvlist_t *nvl, const char *name, >> int8_t val); >> >> int nvlist_add_uint8(nvlist_t *nvl, const char *name, >> uint8_t val); >> >> int nvlist_add_int16(nvlist_t *nvl, const char *name, >> int16_t val); >> >> int nvlist_add_uint16(nvlist_t *nvl, const char *name, >> uint16_t val); >> >> int nvlist_add_int32(nvlist_t *nvl, const char *name, >> int32_t val); >> >> int nvlist_add_uint32(nvlist_t *nvl, const char *name, >> uint32_t val); >> >> int nvlist_add_int64(nvlist_t *nvl, const char *name, >> int64_t val); >> >> int nvlist_add_uint64(nvlist_t *nvl, const char *name, >> uint64_t val); >> >> int nvlist_add_double(nvlist_t *nvl, const char *name, >> double val); >> >> int nvlist_add_string(nvlist_t *nvl, const char *name, >> const char *val); >> >> int nvlist_add_nvlist(nvlist_t *nvl, const char *name, >> nvlist_t *val); >> >> int nvlist_add_nvpair(nvlist_t *nvl, nvpair_t *nvp); >> >> int nvlist_add_boolean_array(nvlist_t *nvl, const char *name, >> boolean_t *val, uint_t nelem); >> >> int nvlist_add_byte_array(nvlist_t *nvl, const char *name, >> uchar_t *val, uint_t nelem); >> >> int nvlist_add_int8_array(nvlist_t *nvl, const char *name, >> int8_t *val, uint_t nelem); >> >> int nvlist_add_uint8_array(nvlist_t *nvl, const char *name, >> uint8_t *val, uint_t nelem); >> >> int nvlist_add_int16_array(nvlist_t *nvl, const char *name, >> int16_t *val, uint_t nelem); >> >> int nvlist_add_uint16_array(nvlist_t *nvl, const char *name, >> uint16_t *val, uint_t nelem); >> >> int nvlist_add_int32_array(nvlist_t *nvl, const char *name, >> int32_t *val, uint_t nelem); >> >> int nvlist_add_uint32_array(nvlist_t *nvl, const char *name, >> uint32_t *val, uint_t nelem); >> >> int nvlist_add_int64_array(nvlist_t *nvl, const char *name, >> int64_t *val, uint_t nelem); >> >> int nvlist_add_uint64_array(nvlist_t *nvl, const char *name, >> uint64_t *val, uint_t nelem); >> >> int nvlist_add_string_array(nvlist_t *nvl, const char *name, >> char *const *val, uint_t nelem); >> >> int nvlist_add_nvlist_array(nvlist_t *nvl, const char *name, >> nvlist_t **val, uint_t nelem); >> >> PARAMETERS >> nvl The nvlist_t (name-value pair list) to be pro- >> cessed. >> >> nvp The nvpair_t (name-value pair) to be processed. >> >> name Name of the nvpair (name-value pair). >> >> nelem Number of elements in value (that is, array size). >> >> val Value or starting address of the array value. >> >> DESCRIPTION >> These functions add a new name-value pair to an nvlist_t. >> The uniqueness of nvpair name and data types follows the >> nvflag argument specified for nvlist_alloc(). See >> nvlist_alloc(3NVPAIR). >> >> If NV_UNIQUE_NAME was specified for nvflag, existing nvpairs >> with matching names are removed before the new nvpair is >> added. >> >> If NV_UNIQUE_NAME_TYPE was specified for nvflag, existing >> nvpairs with matching names and data types are removed >> before the new nvpair is added. >> >> If neither was specified for nvflag, the new nvpair is >> unconditionally added at the end of the list. The library >> preserves the order of the name-value pairs across packing, >> unpacking, and duplication. >> >> Multiple threads can simultaneously read the same nvlist_t, >> but only one thread can actively change a given nvlist_t at >> a time. The caller is responsible for the synchronization. >> >> The nvlist_add_boolean() function is deprecated. The >> nvlist_add_boolean_value() function should be used instead. >> >> RETURN VALUES >> These functions return 0 on success and an error value on >> failure. >> >> ERRORS >> These functions will fail if: >> >> EINVAL There is an invalid argument. >> >> ENOMEM There is insufficient memory. >> >> ATTRIBUTES >> See attributes(5) for descriptions of the following attri- >> butes: >> >> ____________________________________________________________ >> | ATTRIBUTE TYPE | ATTRIBUTE VALUE | >> |____________________________|______________________________| >> | Interface Stability | Evolving | >> |____________________________|______________________________| >> | MT-Level | MT-Safe | >> |____________________________|______________________________| >> >> SEE ALSO >> libnvpair(3LIB), attributes(5) >> >> >> >> Name-value Pair Library Functions nvlist_lookup_boolean(3NVPAIR) >> >> NAME >> nvlist_lookup_boolean, nvlist_lookup_boolean_value, >> nvlist_lookup_byte, nvlist_lookup_int8, nvlist_lookup_uint8, >> nvlist_lookup_int16, nvlist_lookup_uint16, >> nvlist_lookup_int32, nvlist_lookup_uint32, >> nvlist_lookup_int64, nvlist_lookup_uint64, >> nvlist_lookup_double, nvlist_lookup_string, >> nvlist_lookup_nvlist, nvlist_lookup_boolean_array, >> nvlist_lookup_byte_array, nvlist_lookup_int8_array, >> nvlist_lookup_uint8_array, nvlist_lookup_int16_array, >> nvlist_lookup_uint16_array, nvlist_lookup_int32_array, >> nvlist_lookup_uint32_array, nvlist_lookup_int64_array, >> nvlist_lookup_uint64_array, nvlist_lookup_nvlist_array, >> nvlist_lookup_string_array, >> nvlist_lookup_pairs - match name and type indicated by the >> interface name and retrieve data value >> >> SYNOPSIS >> cc [ flag... ] file... -lnvpair [ library... ] >> #include >> >> int nvlist_lookup_boolean(nvlist_t *nvl, const char *name); >> >> int nvlist_lookup_boolean_value(nvlist_t *nvl, >> const char *name, boolean_t *val); >> >> int nvlist_lookup_byte(nvlist_t *nvl, const char *name, >> uchar_t *val); >> >> int nvlist_lookup_int8(nvlist_t *nvl, const char *name, >> int8_t *val); >> >> int nvlist_lookup_uint8(nvlist_t *nvl, const char *name, >> uint8_t *val); >> >> int nvlist_lookup_int16(nvlist_t *nvl, const char *name, >> int16_t *val); >> >> int nvlist_lookup_uint16(nvlist_t *nvl, const char *name, >> uint16_t *val); >> >> int nvlist_lookup_int32(nvlist_t *nvl, const char *name, >> int32_t *val); >> >> int nvlist_lookup_uint32(nvlist_t *nvl, const char *name, >> uint32_t *val); >> >> int nvlist_lookup_int64(nvlist_t *nvl, const char *name, >> int64_t *val); >> >> int nvlist_lookup_uint64(nvlist_t *nvl, const char *name, >> uint64_t *val); >> >> int nvlist_lookup_double(nvlist_t *nvl , const char *name, >> double *); >> >> int nvlist_lookup_string(nvlist_t *nvl, const char *name, >> char **val); >> >> int nvlist_lookup_nvlist(nvlist_t *nvl, const char *name, >> nvlist_t **val); >> >> int nvlist_lookup_boolean_array(nvlist_t *nvl, const char *name, >> boolean_t **val, uint_t *nelem); >> >> int nvlist_lookup_byte_array(nvlist_t *nvl, const char *name, >> uchar_t **val, uint_t *nelem); >> >> int nvlist_lookup_int8_array(nvlist_t *nvl, const char *name, >> int8_t **val, uint_t *nelem); >> >> int nvlist_lookup_uint8_array(nvlist_t *nvl, const char *name, >> uint8_t **val, uint_t *nelem); >> >> int nvlist_lookup_int16_array(nvlist_t *nvl, const char *name, >> int16_t **val, uint_t *nelem); >> >> int nvlist_lookup_uint16_array(nvlist_t *nvl, const char *name, >> uint16_t **val, uint_t *nelem); >> >> int nvlist_lookup_int32_array(nvlist_t *nvl, const char *name, >> int32_t **val, uint_t *nelem); >> >> int nvlist_lookup_uint32_array(nvlist_t *nvl, const char *name, >> uint32_t **val, uint_t *nelem); >> >> int nvlist_lookup_int64_array(nvlist_t *nvl, const char *name, >> int64_t **val, uint_t *nelem); >> >> int nvlist_lookup_uint64_array(nvlist_t *nvl, const char *name, >> uint64_t **val, uint_t *nelem); >> >> int nvlist_lookup_string_array(nvlist_t *nvl, const char *name, >> char ***val, uint_t *nelem); >> >> int nvlist_lookup_nvlist_array(nvlist_t *nvl, const char *name, >> nvlist_t ***val, uint_t *nelem); >> >> int nvlist_lookup_pairs(nvlist_t *nvl, int flag...); >> >> PARAMETERS >> nvl The nvlist_t to be processed. >> >> name Name of the name-value pair to search. >> >> nelem Address to store the number of elements in value. >> >> val Address to store the starting address of the value. >> >> flag Specify bit fields defining lookup behavior: >> >> NV_FLAG_NOENTOK The retrival function will not >> fail if no matching name-value >> pair is found. >> >> DESCRIPTION >> These functions find the nvpair (name-value pair) that >> matches the name and type as indicated by the interface >> name. If one is found, nelem and val are modified to contain >> the number of elements in value and the starting address of >> data, respectively. >> >> These functions work for nvlists (lists of name-value pairs) >> allocated with NV_UNIQUE_NAME or NV_UNIQUE_NAME_TYPE speci- >> fied in nvlist_alloc(). (See nvlist_alloc(3NVPAIR).) If this >> is not the case, the function returns ENOTSUP because the >> list potentially contains multiple nvpairs with the same >> name and type. >> >> Multiple threads can simultaneously read the same nvlist_t >> but only one thread can actively change a given nvlist_t at >> a time. The caller is responsible for the synchronization. >> >> All memory required for storing the array elements, includ- >> ing string value, are managed by the library. References to >> such data remain valid until nvlist_free() is called on nvl. >> >> The nvlist_lookup_pairs() function retrieves a set of >> nvpairs. The arguments are a null-terminated list of pairs >> (data type DATA_TYPE_BOOLEAN), triples (non-array data >> types) or quads (array data types). The interpretation of >> the arguments depends on the value of type (see >> nvpair_type(3NVPAIR)) as follows: >> >> name Name of the name-value pair to search. >> >> type Data type (see nvpair_type(3NVPAIR)). >> >> val Address to store the starting address of the value. >> When using data type DATA_TYPE_BOOLEAN, the val >> argument is omitted. >> >> nelem Address to store the number of elements in value. >> Non-array data types have only one argument and >> nelem is omitted. >> >> The order of the arguments is name, type, [val], [nelem]. >> >> When using NV_FLAG_NOENTOK and no matching name-value pair >> is found, the memory pointed to by val and nelem is left >> untouched. >> >> RETURN VALUES >> These functions return 0 on success and an error value on >> failure. >> >> ERRORS >> These functions will fail if: >> >> EINVAL There is an invalid argument. >> >> ENOENT No matching name-value pair is found >> >> ENOTSUP An encode/decode method is not supported. >> >> ATTRIBUTES >> See attributes(5) for descriptions of the following attri- >> butes: >> >> ____________________________________________________________ >> | ATTRIBUTE TYPE | ATTRIBUTE VALUE | >> |____________________________|______________________________| >> | Interface Stability | Evolving | >> |____________________________|______________________________| >> | MT-Level | MT-Safe | >> |____________________________|______________________________| >> >> SEE ALSO >> libnvpair(3LIB), nvpair_type(3NVPAIR), attributes(5) >> >> >> Name-value Pair Library Functions nvpair_value_byte(3NVPAIR) >> >> NAME >> nvpair_value_byte, nvpair_value_boolean_value, >> nvpair_value_int8, nvpair_value_uint8, nvpair_value_int16, >> nvpair_value_uint16, nvpair_value_int32, >> nvpair_value_uint32, nvpair_value_int64, >> nvpair_value_uint64, nvpair_value_double, >> nvpair_value_string, nvpair_value_nvlist, >> nvpair_value_boolean_array, nvpair_value_byte_array, >> nvpair_value_int8_array, nvpair_value_uint8_array, >> nvpair_value_int16_array, nvpair_value_uint16_array, >> nvpair_value_int32_array, nvpair_value_uint32_array, >> nvpair_value_int64_array, nvpair_value_uint64_array, >> nvpair_value_string_array, >> nvpair_value_nvlist_array - retrieve value from a name-value >> pair >> >> SYNOPSIS >> cc [ flag... ] file... -lnvpair [ library... ] >> #include >> >> int nvpair_value_byte(nvpair_t *nvpair, uchar_t *val); >> >> int nvpair_value_boolean_value(nvpair_t *nvpair, >> boolean_t *val); >> >> int nvpair_value_int8(nvpair_t *nvpair, int8_t *val); >> >> int nvpair_value_uint8(nvpair_t *nvpair, uint8_t *val); >> >> int nvpair_value_int16(nvpair_t *nvpair, int16_t *val); >> >> int nvpair_value_uint16(nvpair_t *nvpair, uint16_t *val); >> >> int nvpair_value_int32(nvpair_t *nvpair, int32_t *val); >> >> int nvpair_value_uint32(nvpair_t *nvpair, uint32_t *val); >> >> int nvpair_value_int64(nvpair_t *nvpair, int64_t *val); >> >> int nvpair_value_uint64(nvpair_t *nvpair, uint64_t *val); >> >> int nvpair_value_double(nvpair_t *nvpair, double *val); >> >> int nvpair_value_string(nvpair_t *nvpair, char **val); >> >> int nvpair_value_nvlist(nvpair_t *nvpair, nvlist_t **val); >> >> int nvpair_value_boolean_array(nvpair_t *nvpair, >> boolean_t **val, uint_t *nelem); >> >> int nvpair_value_byte_array(nvpair_t *nvpair, uchar_t **val, >> uint_t *nelem); >> >> int nvpair_value_int8_array(nvpair_t *nvpair, int8_t **val, >> uint_t *nelem); >> >> int nvpair_value_uint8_array(nvpair_t *nvpair, uint8_t **val, >> uint_t *nelem); >> >> int nvpair_value_int16_array(nvpair_t *nvpair, int16_t **val, >> uint_t *nelem); >> >> int nvpair_value_uint16_array(nvpair_t *nvpair, >> uint16_t **val, uint_t *nelem); >> >> int nvpair_value_int32_array(nvpair_t *nvpair, >> int32_t **val, uint_t *nelem); >> >> int nvpair_value_uint32_array(nvpair_t *nvpair, >> uint32_t **val, uint_t *nelem); >> >> int nvpair_value_int64_array(nvpair_t *nvpair, >> int64_t **val, uint_t *nelem); >> >> int nvpair_value_uint64_array(nvpair_t *nvpair, >> uint64_t **val, uint_t *nelem); >> >> int nvpair_value_string_array(nvpair_t *nvpair, >> char ***val, uint_t *nelem); >> >> int nvpair_value_nvlist_array(nvpair_t *nvpair, >> nvlist_t ***val, uint_t *nelem); >> >> PARAMETERS >> nvpair Name-value pair to be processed. >> >> nelem Address to store the number of elements in value. >> >> val Address to store the value or the starting address >> of the array value. >> >> DESCRIPTION >> These functions retrieve the value of nvpair. The data type >> of nvpair must match the interface name for the call to be >> successful. >> >> There is no nvpair_value_boolean(); the existence of the >> name implies the value is true. >> >> For array data types, including string, the memory contain- >> ing the data is managed by the library and references to the >> value remains valid until nvlist_free() is called on the >> nvlist_t from which nvpair is obtained. See >> nvlist_free(3NVPAIR). >> >> The value of an nvpair may not be retrieved after the nvpair >> has been removed from or replaced in an nvlist. Replacement >> can occur during pair additions to nvlists created with >> NV_UNIQUE_NAME_TYPE and NV_UNIQUE_NAME. See >> nvlist_alloc(3NVPAIR). >> >> RETURN VALUES >> These functions return 0 on success and an error value on >> failure. >> >> ERRORS >> These functions will fail if: >> >> EINVAL Either one of the arguments is NULL or the type of >> nvpair does not match the function name. >> >> ATTRIBUTES >> See attributes(5) for descriptions of the following attri- >> butes: >> >> >> ____________________________________________________________ >> | ATTRIBUTE TYPE | ATTRIBUTE VALUE | >> |____________________________|______________________________| >> | Interface Stability | Evolving | >> |____________________________|______________________________| >> | MT-Level | MT-Safe | >> |____________________________|______________________________| >> >> SEE ALSO >> libnvpair(3LIB), nvlist_alloc(3NVPAIR), attributes(5) >> >> >> >> >> These interfaces are Committed and seek patch binding. >> >> 6. Resources and Schedule >> 6.4. Steering Committee requested information >> 6.4.1. Consolidation C-team Name: >> ON >> 6.5. ARC review type: FastTrack >> 6.6. ARC Exposure: open >> >> > From Darren.Moffat@sun.com Wed Jul 9 03:45:24 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m69AjOYG002186 for ; Wed, 9 Jul 2008 03:45:24 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m69AjNM3024319 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 9 Jul 2008 04:45:23 -0600 (MDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K3Q0070LJ7NUT00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 09 Jul 2008 04:45:23 -0600 (MDT) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K3Q00791J7MHA00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 09 Jul 2008 04:45:22 -0600 (MDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-2-fe3.eu.sun.com [192.18.6.12]) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m69AjL1B025150 for ; Wed, 09 Jul 2008 10:45:21 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K3Q00C01J575C00@fe-emea-10.sun.com> (original mail from Darren.Moffat@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 09 Jul 2008 11:45:21 +0100 (BST) Received: from [129.156.173.21] by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K3Q00H4NJ79N250@fe-emea-10.sun.com>; Wed, 09 Jul 2008 11:45:10 +0100 (BST) Date: Wed, 09 Jul 2008 11:45:09 +0100 From: Darren J Moffat Subject: Re: Extending libnvpair for type double [PSARC/2008/428 FastTrack timeout 07/15/2008] In-reply-to: <200807082023.m68KN9UO009861@sac.sfbay.sun.com> Sender: Darren.Moffat@sun.com To: Cynthia McGuire Cc: PSARC-ext@sun.com, Robert.Johnston@sun.com Message-id: <487496B5.4010209@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200807082023.m68KN9UO009861@sac.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.14 (X11/20080602) Status: RO Content-Length: 716 Cynthia McGuire wrote: > Because use of floating point types is discouraged in the kernel, and all of Discouraged yes but it does work and it is used in places. Care needs to be taken though. The only place I know of that does it is the sun4u/sparcv9 optimised version of the bignum module. > the FMA components that will be consuming these new interfaces live in > userland, they will be made available via libnvpair but not in the kernel DDI. > Preprocessor guards will be used to ensure the new code is not compiled > into the kernel. I don't have a current use for them but rather than just not making them available wouldn't it be better to but a nice big warning in the man page ? -- Darren J Moffat From Robert.Johnston@sun.com Wed Jul 9 14:36:57 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m69LauLT027202 for ; Wed, 9 Jul 2008 14:36:56 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m69LatL0029350 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 9 Jul 2008 22:36:55 +0100 (BST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K3R00907DDIRU00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 09 Jul 2008 15:36:54 -0600 (MDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K3R005F2DDIO160@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 09 Jul 2008 15:36:54 -0600 (MDT) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m69Las2X003128 for ; Wed, 09 Jul 2008 21:36:54 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K3R00601D1U6P00@mail-amer.sun.com> (original mail from Robert.Johnston@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 09 Jul 2008 15:36:54 -0600 (MDT) Received: from [129.146.226.55] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K3R00KZ5DDEHGB0@mail-amer.sun.com>; Wed, 09 Jul 2008 15:36:50 -0600 (MDT) Date: Wed, 09 Jul 2008 14:30:52 -0700 From: Rob Johnston Subject: Re: Extending libnvpair for type double [PSARC/2008/428 FastTrack timeout 07/15/2008] In-reply-to: <487496B5.4010209@Sun.COM> Sender: Robert.Johnston@sun.com To: Darren J Moffat Cc: Cynthia McGuire , PSARC-ext@sun.com Message-id: <48752E0C.9060108@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200807082023.m68KN9UO009861@sac.sfbay.sun.com> <487496B5.4010209@Sun.COM> User-Agent: Thunderbird 2.0.0.12 (X11/20080325) Status: RO Content-Length: 1233 Darren J Moffat wrote: > Cynthia McGuire wrote: >> Because use of floating point types is discouraged in the kernel, and >> all of > > Discouraged yes but it does work and it is used in places. Care needs > to be taken though. The only place I know of that does it is the > sun4u/sparcv9 optimised version of the bignum module. > >> the FMA components that will be consuming these new interfaces live in >> userland, they will be made available via libnvpair but not in the >> kernel DDI. >> Preprocessor guards will be used to ensure the new code is not compiled >> into the kernel. > > I don't have a current use for them but rather than just not making them > available wouldn't it be better to but a nice big warning in the man page ? > I suppose we could do that. However, like I said, there aren't any current consumers for it in the kernel so the kernel version would go untested. Not sure how good that is. If a kernel consumer comes along some time down the road, it's a straightforward code change to enable the kernel interface (mostly just a matter of removing the preprocessor guards) At which time, they can go to psarc and folks here can decide if what they're doing is a good idea or not :) rob