Re: 2.5.47bk2 + current modutils == broken hotplug

[David Brownell]

>> And it'd be handy if the text format for that information didn't change;
>> how it's stored in object modules doesn't matter.
> 
> Correction -- the tools that read the text format are buggy if they do 
> not transparently support changes to the text format.

That's not a correction, it's a tangent!   Either way, it's still
"handy" ... since supporting new formats requires new tools, and it's
clearly "handy" not to need to write, debug, and deploy new tools
(including teaching, documenting, etc).

> I am planning on adding PCI revision id to the information exported via 
> MODULE_DEVICE_TABLE(pci,...).  Tools which correctly read the 
> first-line-format-definition will continue to function as before, 
> regardless of additional fields I want to add.  Tools which make silly 
> assumptions will have those assumptions come back to bite them ;-)

The "silly assumption" seems to be that the current "modules.*map"
format can reasonably be extended ... when no rules for extending those
file formats were really defined, and the _only_ precedent for even
changing them involved incompatibility between "versions".

I'd far rather have a decent file format for that data, and move
away from that ungainly syntax, than try to retrofit rules about
how to extend that syntax.  Such a format should:

  - allow comments
  - not have as much garbage (zeroes, 0xffffffff, etc)
  - still be easily parsable from shell scripts (*)
  - be easier for site admins to edit (insert vi/emacs flamewar)
  - have an explicit version code, and rules about evolution

Alternatively, the tried'n'true approach of coupling the format
to the filename works:  don't reuse "modules.*map", use "*.modules"
or something.
- Dave

(*) This is the annoying requirement.  Maybe worth relaxing.
     For example, an XML format could easily support all the
     other requirements ... but not (AFAIK) that one.