Greg,

This has been done to death here before.  

Embedding ASCII format strings in an in-kernel filesystem makes i18n
rather difficult.

Embedding information in an in-kernel filesystem makes it hard to
extract that information from a coredump in ways that're compatible
with _any_ userland tools. And the people who use those tools on
coredumps are a significant fraction of our kernel developers.
If the people who actually produce the code want to use those regular
tools userland rather than GDB scripts, then that's what they'll do.

Some of the people who've said this, repeatedly, are Core members;
your opinion on what's aesthetically right or wrong just isnt going to
outweigh their sense of what's important or even "necessary" to them,
as developers.  OTOH, if you're acutally volunteering to replace
netstat and ps and arp and other libkvm-based utilities with
kernfs-based versions, then you have my apologies.

But it's still very far from clear that that's a good solution for
Darren's problem: making the symbols in one LKM available to another
LKM.  The symbol-to-address mappings have to be segmented by module,
so they can be garbage-cllected when a module is unloaded.  I think
the Linux model, where an LKM gets to programatically export some of
its external symbols to the globally-visible kernel symbol table, is
actually pretty good, here.

But presenting these via a kernfs-like filesystem misses the point:
you need to provide them in a format that BFD understands, both for
linking in new LKMs that depend on already-loaded ones, _and_ to
get the symbols into GDB. 

I think it's pointless saying "write GDB scripts to present info from
a kernfs", when the debugging info GDB needs in order to say anything
sensible about LKMs -- like, doing source listings or examining
variables -- is inside akernfs in the first place!