Danek Duvall 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?
What problem is this actually attempting to solve ?
If the problem is identifying where the binary came from then
the fingerprint database stored on sunsolve.sun.com solves that problem
using MD5 hashes of the files. It does however only work for Solaris
not all distros. It works for all officially distributed bits,
including patches and releases back at least as far as 2.5.1 and some
unbundled products as well.
Another way to find out if the binary is "official" and not rouge is to
use elfsign(1) verify. I don't believe distros other than Sun's sign
non crypto binaries - but they could if the wanted to (the instructions
for doing so are on my blog).
We also have the /system/object file system where you can check hashes
of the currently in kernel files.
My vote is to remove ALL version numbers from kernel modules they aren't
actually meaningfull in my opinion.
The output of what(1) on the other hand is reasonable to keep.
--
Darren J Moffat
_______________________________________________
opensolaris-code mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
