> 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.

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

-- 
Mike Shapiro, Solaris Kernel Development. blogs.sun.com/mws/
_______________________________________________
opensolaris-code mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code

Reply via email to