Crisson Hu writes:
> On Mon, 2008-11-24 at 22:11 -0500, Peter Memishian wrote:
> >
> > What about "::showrev -v" in mdb? That gives the build date and the
> > name of the gate that built it.
>
> I got different output from sparc and x86 system, but both don't contain
> a number alike information. It's preferable to have a one-liner command
> to show the revision of the driver module. Maybe it could reside in the
> mdb/kstat outputs. Or should I add such information?
I don't know what "number alike information" means.
The output of that command shows you all the information you need to
know to track down the exact source and revision that was used to
build each of the kernel modules on the system, and even handles the
case where someone copies binaries from another system. What more
would you need?
Another thing you can do is use "mcs -p" on the binary. That will
also give you build information.
Still another thing you can do is check the packaging and patch
information. On Nevada and older releases:
pkginfo -l SUNWbge
On OpenSolaris:
pkg search /kernel/drv/bge
This information could be improved by having the build process add 'hg
tip' to the data retained, but what's there is generally enough.
For instance, on my Nevada machine, I see:
PSTAMP: elpaso20081111021705
The 'elpaso' stamp means that this package came from the gate machine
on November 11th, 2008, at 02:17:05, and searching the gate shows that
this came from build 103:
% grep elpaso20081111021705
/ws/onnv-gate/packages/i386/snv_*-pit-nd/SUNWbge/pkginfo
/ws/onnv-gate/packages/i386/snv_103-pit-nd/SUNWbge/pkginfo:PSTAMP=elpaso20081111021705
(Though I did know that already because I know I've installed snv_103
on the machine.)
On an OpenSolaris machine, it's even easier. The version number from
packaging is readable and gives you the build number, which precisely
identifies what you're using.
As I said, this has all been discussed ad nauseum on the SCM migration
list and on other lists, and the consensus was simple: remove the
version numbers; they do no good, and represent a maintenance burden
and a distraction since only *SOME* binaries still have them.
--
James Carlson, Solaris Networking <[EMAIL PROTECTED]>
Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
_______________________________________________
networking-discuss mailing list
[email protected]
