Vladimir Marek wrote:
>> There are much better and more reliable tools for determining which
>> revision of a particular binary you have than source keywords. They
>> include (either on their own or in combination) but are not limited to:
>> pkgchk, pkg(5) [IPS], digest, md5sum, bart, showrev, elfsign, the online
>> fingerprint database.
>
> Those won't show which module is actually loaded into kernel, will they
> ? (I don't know bart and online fingerprint database). I.e. you have
> crash dump, how can you find out which module version was loaded ?
Use the ::showrev dcmd in mdb
> utsname::print
{
sysname = [ "SunOS" ]
nodename = [ "arcmsr" ]
release = [ "5.11" ]
version = [ "snv_91" ]
machine = [ "i86pc" ]
}
> ::showrev -v
Version: NWSC Objects: fctl sbd stmf fct iscsi fcip fcp fcsm
Version: SunOS Development Objects: scsi arcmsr
Version: Unknown Objects: nvidia nskern ncall nsctl spuni sdbc sv ii rdc
rdcsrv rdcstub
Version: snv_91 Objects: unix genunix kmdbmod ctf specfs fifofs dtrace
devfs dev dls mac TS TS_DPTBL
pci_autoconfig acpica cpu.generic cpu_ms.AuthenticAMD.15 uppc pcplusmp
rootnex options pseudo clone
scsi_vhci scsi_vhci_f_asym_sun scsi_vhci_f_asym_lsi scsi_vhci_f_asym_emc
scsi_vhci_f_sym_emc
scsi_vhci_f_sym_hds scsi_vhci_f_sym scsi_vhci_f_tpgs isa busra zfs swrand
kcf sha1 idmap doorfs rpcmod
tlimod acpippm ppm npe pcihp hpcsvc pcie nv_sata sata sd cmlb ctfs procfs
mntfs tmpfs objfs sharefs
cpunex cpudrv sockfs ip md5 hook neti strplumb dld ip6 tcp tcp6 udp udp6
sctp sctp6 icmp icmp6 arp
timod sad consconfig_dacf usbser usba pci_pci atiatom gfx_private conskbd
kbtrans consms wc tem iwscn
ehci ohci hci1394 mc-amd s1394 elfexec hid hidparser pcie_pci usbkbm kssl
ldterm ttcompat ptsl ptc
ipsecesp ipsecah tl rts keysock nca spdsock rds sdp sysmsg cn mm pipe
namefs portfs intpexec sysevent
softmac lofs devinfo agpgart xsvc pit_beep st openeepr log audio810 sy
amsrc2 audiosup mixer ramdisk
pci-ide md nge lockstat llc1 cpc ata pcbe.AuthenticAMD.15 poll lofi
random ippctl crypto cryptoadm
profile systrace fbt sdt fasttrap bl kmdb vni cpuid aggr smbios power srn
smbsrv klmmod nfs rpcsec
lx_ptm lx_systrace lx_brand lx_audio physmem ucode vnic vscan logindmux
dump mac_ether ptm amd64_gart
pts ses fssnap fssnap_if ufs ksyms winlock kstat llc2 tnf pm sppp sppptun
rsm rsmops pool ipf nsmb md4
fdfs autofs pset ptem shmsys ipc kaio
>
> Not that the current keywords would be always ideal solution, but it was
> at least something ...
That's true, but we can't remain welded to it.
> Wouldn't it be solution to use hg log, something like
>
> hg log -l 1 --template '{node|short}\n' file
>
> It prints node id of last commit which changed given file (or even
> directory !). And it's much faster than 'hg id'. The only disadvantage I
> can see is that you can't find which node id is older than other just by
> looking at it.
I believe that's one of the proposals. The NWS Consolidation
(at least, they used to) uses a similar concept, by setting a
variable in the top-level makefile and embedding that in each
module's version info.
One other thing though- I don't think we're really concerned
about _age_ of the code so much as identifying which particular
revision it is - as long as you've got a tip id, you can find
the matching version of the code:
hg cat -r $TIP /path/to/file
James C. McPherson
--
Senior Kernel Software Engineer, Solaris
Sun Microsystems
http://blogs.sun.com/jmcp http://www.jmcp.homeunix.com/blog
