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
Getting started with the Userland Consolidation
Getting Started
This README provides a very brief overview of the gate, how to retrieve
a copy, and how to build it. Detailed documentation about the Userland
gate can be found in the 'doc' directory. Questions or comments about
the gate can be addressed to [email protected].
Overview
The Userland consolidation maintains a Mercurial gate at
ssh://[email protected]//hg/userland/gate
This gate contains build recipies, patches, IPS manifests, etc. necessary
to download, prep, build, test, package and publish open source software.
The build infrastructure is similiar to that of the SFW consolidation in
that it makes use of herarchical Makefiles which provide dependency and
recipe information for building the components. In order to build the
contents of the Userland gate, you need to clone it. Since you are
reading this, you probably already have.
Getting the Bits
As mentioned, the gate is stored in a Mercurial repository. In order to
build or develop in the gate, you will need to clone it. You can do so
with the following command
$ hg clone ssh://[email protected]//hg/userland/gate /scratch/clone
This will create a replica of the various pieces that are checked into the
source code management system, but it does not retrieve the community
source archives associated with the gate content. To download the
community source associated with your cloned workspace, you will need to
execute the following:
$ cd /scratch/clone/components
$ gmake download
This will use GNU make and the downloading tool in the gate to walk through
all of the component directories downloading and validating the community
source archives from the gate machine or their canonical source repository.
There are two variation to this that you may find interesting. First, you
can cause gmake(1) to perform it's work in parallel by adding '-j (jobs)'
to the command line. Second, if you are only interested in working on a
particular component, you can change directories to that component's
directory and use 'gmake download' from that to only get it's source
archive.
Building the Bits.
You can build individual components or the contents of the entire gate.
Component build
If you are only working on a single component, you can just build it using
following:
setup the workspace for building components
$ cd (your-workspace)/components ; gmake setup
build the individual component
$ cd (component-dir) ; gmake publish
Complete Top Down build
Complete top down builds are also possible by simply running
$ cd (your-workspace)/components
$ gmake publish
The 'publish' target will build each component and publish it to the
workspace IPS repo.
Tools to help facilitate build zone creation will be integrated
shortly. If the zone you create to build your workspace in does not have
networking enabled, you can pre-download any community source archives into
your workspace from the global with:
$ cd (your-workspace)/components
$ gmake download
You can add parallelism to your builds by adding '-j (jobs)' to your gmake
command line arguments.
The gate should only incrementally build what it needs to based on what has
changed since you last built it.