Patch to remove smbios.* keys

[Richard Hughes]

On Sun, 2007-01-21 at 23:39 +0100, Danny Kukawka wrote:
> On Sunday 21 January 2007 22:41, Richard Hughes wrote:
> > Patch attached just moves the smbios.* keys to system.* and documents
> > them.
> >
> > Is there actually using the smbios.* keys apart from HAL internally and
> > hal-info? Do we need to provide backwards compat code?
> 
> I'm against removing these keys. They are not only used in HAL internally 
> (please note: only because keys are maybe not in the spec does not mean 
> nobody use them, at least not because the spec is never complete!), we use 
> these keys for several applications on SUSE as e.g. hwinfo and yast/sax.

Sure, so we can provide the old smbios keys for one year. I just wanted
some feedback on this.

> This is the same as before, HAL is already to important and central in the 
> system to change the API without consequences. Because of this there should 
> be a clear policy for API changes:
> 1.) avoid changes

Hmm. Even if the API is broken? We've done this before with the
laptop_panel keys when the percentage values couldn't work.
I've done a fair bit of work with ARM and HAL, and in some places HAL
isn't abstracting the info, but making it very i386 specific.

Should ARM devices (that don't use SMBIOS, or have a BIOS for that
matter) be setting keys smbios.system.manufacturer?

> 2.) don't delete keys and replace them without a transition period under 12 
> months

Sure, I was just testing the water with this patch.

> At least we can't remove these keys because this produce problems with the 
> intention of the hal-info package if you also change/remove the keys there: 
> you can't update hal-info for older HAL versions anymore - without lose 
> functionality.

hal-info is only for hal >= 0.5.9 so that doesn't apply. I also wanted
to make these changes before hal-info and hal 0.5.9 were released so we
can support hal-info for many years for lots of hal-versions.

Also, removing the smbios prefix saves 1.5K of memory in the binary
cache, although that's not exactly a huge saving. :-)

Richard.