Embedding $VERSION in stuff other then genunix might be kinda nice.
alan.
Garrett D'Amore wrote:
I have mixed opinions about %I% in modinfo output. I've used it, or a
cobbled version based on $Id$ (from RCS hosted trees) in the past, and
it can be useful. But in the world of branches and copied files, it can
also be misleading.
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).
Of course, modinfo has limits on output length, and as it is version
strings already are often truncated. Sticking the information in the
module ELF table is probably more useful, although then you have the
problem of verifying that the on-disk module is the same as what's in
kernel memory (perhaps a checksum could be more useful? This could be
returned by a new flag to modinfo(1m)?)
Actually, the more I think about it, the more I like it:
modinfo -s gives the checksum (MD5? SHA2?) of the kernel module
modinfo -f <file> -s gives the same checksum for the named ELF object <file>
modinfo -C gives a module version/comment as stored in the ELF .comment
section or somesuch
modinfo -f <file> -C can do the same for a named ELF object <file>
Perhaps also, some preprocessor macro "BUILD" or somesuch should be
available to describe the source repo and build environment, for use in
other places (like cmn_err() messages.) This might not be strictly
necessary given the other items above, though.
If we had these, then I fully believe the %I% used in drivers could
easily go away.
-- Garrett
Stephen Lau wrote:
Sending this to opensolaris-code for additional feedback, thoughts...
Stephen Lau wrote:
We've had contentious discussion on this already [1], but we need to
get resolution on this to move forward on the SCM Migration.
Mike Kupfer & Danek noted that the following are currently in use:
%?% (not an SCCS keyword)
%D% current date (yy/mm/dd)
%E% date of newest delta (yy/mm/dd)
%G% date of newest delta (mm/dd/yy)
%H% current date (mm/dd/yy)
%I% SID (%R%.%L%.%B%.%S%)
%L% level (see %I%)
%M% module name
%N% (not an SCCS keyword)
%R% release (see %I%)
%T% current time (hh:mm:ss)
%U% time of newest delta (hh:mm:ss)
%W% shorthand for %Z%%M%\t%I%
%X% (not an SCCS keyword)
%Z% what(1) marker ("@(#)")
%e% (not an SCCS keyword)
%s% (not an SCCS keyword)
The options I've seen are:
1) Eliminate the use of keywords entirely
2) Eliminate the #ident %Z% keywords (which is the bulk of the
keyword usage in onnv), and port the remaining ones to a new format
3) Port all keywords to a new format
The most contentious issue seems to be the use of %I% in modules such
as drivers. (James & Alan: this is why I've cc'd you, since I don't
know who else would know people in PTS who might have an opinion).
The general consensus from the ON developers I've talked to is that
the use of %I% to identify module versions is.... poor. That being
said, PTS uses it - for better or for worse. One thought that we had
was to replace it with the the Mercurial monotonically-increasing
revision number (not the 12 character hex hash). It gives the
ever-increasing factor that people may expect, but doesn't identify
uniqueness (since the revision number is relative to each
repository). However, this is the same behaviour as %I% - so perhaps
it's okay.
My personal vote is to:
- Eliminate the #ident %Z% keywords (since the what(1) string is
replaced by the build, anyway).
- Replace %I% for module versions with the Hg revision number
Thoughts? Flames?
cheers,
steve
[1] http://www.opensolaris.org/jive/thread.jspa?messageID=39328
--
Alan Hargreaves - http://blogs.sun.com/tpenta
Staff Engineer (Kernel/VOSJEC/Performance)
Systems Technical Service Center
Sun Microsystems
_______________________________________________
opensolaris-code mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
