6926434 ib_read_bw, ib_read_lat: OFED utilities sometimes hang when using "-e" (event) flag
6996726 "rds-stress --show-perfdata" option is broken.
7003185 rds-stress man page needs cleanup
7005654 qperf: 32bit only: qperf fails in all RC/UD streaming tests
7024095 set_nodedesc.sh: heading whitespace of HCA specific desc string is ignored if '-N' not specified
7043392 OFED 1.5.3: test_verbs: 'resize CQ' test failed on tavor
7043758 OFED 1.5.3: test_verbs: core dump while during async test on tavor with snv_166
7044543 ibsysstat server process fails to get cpu info
7046730 ibstatus needs to clean up after itself
7050802 OFED 1.5.3: ib_send_bw/ib_send_lat doesn't work with '-g' option
7061241 OFED 1.5.3 ib_read_lat/ib_read_bw don't work between tavor and hermon
7087339 modify solaris changes to libmlx4 to use returned inline size from hermon driver
7090343 solaris_set_nodedesc: the -N option does not work
7091277 /usr/man/man3/ibnd_debug.3 and ibnd_destroy_fabric.3 refer to non-existence ibnd_discover_fabric.3
7091649 OFED 1.5.3: ibdiagnet: "-vlr -r" shows file open failure messages on Solaris
7093499 ib_rdma_lat, ib_read_lat, ib_write_lat and other IB verb latency tools should use gethrtime
7095000 mem leak in libibvers ibv_read_sysfs_file()
7095879 resize cq in libmlx4 incorrect
7095943 rdma_lat & rdma_bw core dump on non ib system
7099692 Add man pages for OFUV perftest utilities
7108873 definitions in sol_uverbs_ioctl.h & sol_umad_ioctl.h are duplicated in solaris_compatibility.c
7119924 ibportstate: operations enable, disable, and reset should only be allowed on switch ports
7120891 ibv_devinfo should report a valid active_mtu instead of 'Unknown'
7141996 sol_uverbs should provide ioctl calls to get GIDs and PKEYs for libibverbs (userland changes)
7144445 setnodedesc.sh -v white space issue
7146479 qperf --cpu_affinity doesn't match with solaris cpu no.
7146482 qperf -cm1 sometimes failed with "rdma_listen failed" message
Userland Consolidation Packaging Guidelines.
Each component that integrates into the Userland consolidation must have at
least one package manifest that describes the content to be delivered. In some
cases components *may* deliver through multiple packages. Canonical component
package manifests must be placed in the component's build directory. They also
must be named *.p5m.
In order to understand what must go in the content of a package manifest,
it's useful to have an understanding of how a canonical manifest is transformed
into a final manifest used for package publication. Manifest transformation
takes the following basic path:
canonical manifest
(.../{component}/{component}.p5m)
|
v
mogrified manifest
(.../{component}/{build-dir}/manifest-$(MACH)-{component}.mogrified)
|
v
mangled manifest file contents
(.../{component}/{build-dir}/manifest-$(ARCH)-{component}.mangled)
|
v
dependencies generated
(.../{component}/{build-dir}/manifest-$(MACH)-{component}.depend)
|
v
dependencies resolved
(.../{component}/{build-dir}/manifest-$(MACH)-{component}.depend.res)
|
v
manifest validation
(.../{component}/{build-dir}/.linted-$(MACH))
|
v
publication manifest
(.../{component}/{build-dir}/manifest-$(MACH)-{component}.published)
|
v
publication
Canonical Manifest
The canonical manifest contains actions that can't otherwise be generated
automatically from the data encapsulated in the component Makefile, gate
transformations, build tree, and packaging tools. This includes actions
for license information, some path related attributes, legacy actions,
non-discoverable dependencies, users, groups, drivers, and others.
Actions that are associated with objects that are specific to a single
architecture should be tagged with a 'variant.arch' attribute specific to
the architecture that applied to the action. Ex:
file path=/usr/lib/$(MACH64)/libx86onlybits.so variant.arch=i386
Actions for editable files must include an appropriate 'preserve' attribute:
file path=etc/gnu/a2ps.cfg preserve=true mode=0644
license actions should be placed in the canonical manifest.
Mogrified Manifest
The canonical manifest is combined with a set of the transforms
in $(WS_TOP)/transforms, and a set of macros to more complete
package manifest using pkgmogrify(1). The transforms apply default
attributes to the various actions in the canonical manifest(s). More
detail about the attributes can be found in the transform file themselves.
The macros applied at the time of mogrification are as follows:
$(MACH)
$(MACH32)
$(MACH64)
$(PUBLISHER)
$(CONSOLIDATION)
$(BUILD_VERSION)
$(SOLARIS_VERSION)
$(OS_VERSION)
$(IPS_COMPONENT_VERSION)
$(COMPONENT_VERSION)
$(COMPONENT_PROJECT_URL)
$(COMPONENT_ARCHIVE_URL)
Dependencies Generated
The mogrified manifest and the prototype install tree are passed through
pkgdepend(1) to generate a set of dependencies for the package content.
These dependencies are only those that "pkgdepend generate" can determine
on its own. Additional dependencies that cannot be automatically
determined by pkgdepend(1) should be placed in the canonical manifest.
Statically defined dependencies should be described in a canonical manifest
in an unresolved form (ie. the form generated by "pkgdepend generate").
Ex:
depend fmri=__TBD pkg.debug.depend.file=etc/passwd \
pkg.debug.reason=usr/bin/vipw type=require
depend fmri=__TBD pkg.debug.depend.file=sh \
pkg.debug.depend.path=usr/bin \
pkg.debug.depend.reason=usr/bin/psmandup \
pkg.debug.depend.type=script type=require
This will allow the next step to resolve all dependencies to their proper
package(s).
Dependencies Resolved
The manifest with unresolved dependencies is passed through pkgdepend(1)
again to resolve dependencies against the package repositories. The
result is a manifest that is suitable for publication. All these
manifests are processed together in a single step, which is more
efficient than resolving dependencies in each manifest separately.
While each manifest ends up with a .depend.res copy in the build
directory, the umbrella dependency resolution target is
{build-dir}/.resolved-$(MACH).
Manifest Validation
The resolved manifest(s) and prototype install tree are passed through
a set of validations. This includes running pkglint(1), comparing the
manifest content to the prototype install tree, and validation of the file
content of the prototype install tree. Any anomalies are reported.
Content validation is performed by extension to pkglint(1) in
$(WS_TOP)/tools/python/userland-lint
Publication.
Once manifest validation has occurred, the package(s) is/are finally
published to the workspace package repository.
# vi:set fdm=marker expandtab ts=4: