From Electron Cloud
Jump to: navigation, search
(The ELF approach)
Line 39: Line 39:
 
  00d0 636b2053 4d502070 7265656d 7074206d  ck SMP preempt m
 
  00d0 636b2053 4d502070 7265656d 7074206d  ck SMP preempt m
 
</pre>
 
</pre>
 +
 +
So there we go... seems that it's probably possible to do the same thing with any shared object, but I think I would choose ".metadata" instead of ".modinfo" just in case there are tools which assume that anything with a .modinfo section is really a kernel module, and also to make it clear that any kind of metadata that you like can be stored there.
  
 
==Filesystem metadata==
 
==Filesystem metadata==

Revision as of 14:17, 2 December 2010

One nice thing on Windows is the ability to see useful metadata in the "properties" of a DLL. I think executables and libraries on Linux should have this feature too.

The ELF approach

It seems to me there should be an ELF section with arbitrary name/value pairs, and some of the names should be standardized so that they can be displayed in file managers like Nautilus, Konqueror etc.

This has already been done for kernel modules, e.g.

[i7][02:03:30 PM] modinfo /lib/modules/2.6.36-ck/kernel/lib/libcrc32c.ko 
filename:       /lib/modules/2.6.36-ck/kernel/lib/libcrc32c.ko
license:        GPL
description:    CRC32c (Castagnoli) calculations
author:         Clay Haapala <chaapala@cisco.com>
depends:        crypto_hash
vermagic:       2.6.36-ck SMP preempt mod_unload 

Here's some info about that.

[i7][02:10:54 PM] objdump --full-contents --section=.modinfo /lib/modules/2.6.36-ck/kernel/lib/libcrc32c.ko

/lib/modules/2.6.36-ck/kernel/lib/libcrc32c.ko:     file format elf64-x86-64

Contents of section .modinfo:
 0000 6c696365 6e73653d 47504c00 00000000  license=GPL.....
 0010 00000000 00000000 00000000 00000000  ................
 0020 64657363 72697074 696f6e3d 43524333  description=CRC3
 0030 32632028 43617374 61676e6f 6c692920  2c (Castagnoli) 
 0040 63616c63 756c6174 696f6e73 00000000  calculations....
 0050 00000000 00000000 00000000 00000000  ................
 0060 61757468 6f723d43 6c617920 48616170  author=Clay Haap
 0070 616c6120 3c636861 6170616c 61406369  ala <chaapala@ci
 0080 73636f2e 636f6d3e 00000000 00000000  sco.com>........
 0090 00000000 00000000 00000000 00000000  ................
 00a0 64657065 6e64733d 63727970 746f5f68  depends=crypto_h
 00b0 61736800 00000000 00000000 00000000  ash.............
 00c0 7665726d 61676963 3d322e36 2e33362d  vermagic=2.6.36-
 00d0 636b2053 4d502070 7265656d 7074206d  ck SMP preempt m

So there we go... seems that it's probably possible to do the same thing with any shared object, but I think I would choose ".metadata" instead of ".modinfo" just in case there are tools which assume that anything with a .modinfo section is really a kernel module, and also to make it clear that any kind of metadata that you like can be stored there.

Filesystem metadata

Alternatively if filesystems and file-management tools (tar, cp etc.) evolve to handle metadata robustly, this info could just be stored on the filesystem - in the resource fork, if implemented that way. The trouble with resource forks is that they have to be moved along with the file, so every tool that is routinely used for file management has to support it.