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
>
>
--
Garrett D'Amore, Principal Software Engineer
Tadpole Computer / Computing Technologies Division,
General Dynamics C4 Systems
http://www.tadpolecomputer.com/
Phone: 951 325-2134 Fax: 951 325-2191
_______________________________________________
opensolaris-code mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
