On Tue, Jun 26, 2007 at 09:00:05AM -0700, Jason Thorpe wrote:
> 
> Having the library change its behavior based on an environment  
> variable is just plain offensive.

I don't think anyone likes the environment variable controlling which
externalization is used.  But I also haven't seen a better suggestion
for how to provide a truly universal knob that applies to all consumers
of the library -- which is probably why the crummy environment variable
method is still presently in use.

> Besides, what happens if you have a  
> file in one of these alternate formats and you then need to have the  
> boot loader read it?  So, we need to support all of these random  
> encodings for those environments, too?  The code soon gets too big to  
> be useful in some environments.

This is a completely sensible objection if the number of formats is
actually large -- and, for example, it's probably why some initially
interesting ideas like loadable codec modules are actually very bad
ideas indeed.

But what one should note, of course, is that two or three are not very
large numbers.  Heck, I think any number less than about five is probably
sustainable with minimal code bloat and user confusion, if the encodings
are carefully chosen.  All three of XML, SCN, and the binary encoding seem
good to me for inclusion by default -- and I can't see why the kernel
actually needs any more encodings than just one (would the binary one be
better than XML for this purpose)?

Thor