Michael Shapiro wrote:
On Mon, Jan 29, 2007 at 07:23:07PM -0800, David Powell wrote:
However, what I'd really, really like to see is a way to embed a keyword
that is taken from a build (say "snv54" or somesuch) via Makefile, for
production builds, and has some other text for unofficial builds (say
"debugYYYYMMDD" or somesuch).
Have you ever tried '::showrev -v' in mdb -k (or kmdb)? We store an
identifier for the build in (I believe) the CTF data for each
individual module.
Accessing this from places other than mdb is definitely possible.
If nothing else:
installed-machine$ what /kernel/drv/sparcv9/fbt
/kernel/drv/sparcv9/fbt:
SunOS 5.11 snv_49 October 2007
bfued-machine$ what /kernel/drv/sparcv9/fbt
/kernel/drv/sparcv9/fbt:
SunOS 5.11 onnv-gate:2007-01-26 October 2007
SunOS Internal Development: gk 2007-01-26 [onnv-gate]
But is that good enough for Services, or is it critical that the data be in
the modinfo output?
Danek
Just to chime in: the modinfo output is useless at worst and confusing at
best. It causes module revision changes when we update copyrights, it
doesn't show revisions when a module built from multiple src files changes
due to a change in some other source file that doesn't have the string.
It's just plain silly, and it should be deleted from the source base.
As Dave and Danek pointed out, the right answer is ::showrev / ::objects -v
in mdb and/or mcs -p and what output. In particular, the mdb commands
will have the exact patch number, which is usually what Service needs.
Yet this only works for consolidations using the ctf tools (which I believe
are still in theory consolidation private), and using them properly.
ON, obviously, does the right thing.
NWS use "NWSC" as the ctf label.
Wherever qlc(7D) comes from uses a qlc-specific date/version string.
Other consolidations shipping modules don't use the ctf tools.
While I'll accept most of this conversation is related to ON, it shouldn't
be forgotten that other consolidations, some of whom planning on migrating
to mercurial, will have similar choices to make.
(though the cynic in me fully expects them to all make different choices...
sigh)
The one missing piece is that historically yet another missing Patch process
was proper retrieval of the actual source IDs comprising the patch.
That is, if Patch 12345-67 is for the foo driver, you want either a snapshot
of the source tree for that Patch, or at least a list of the relevant source
files and their SCCS IDs against some gate.
-Mike
_______________________________________________
opensolaris-code mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
