Patch to remove smbios.* keys

[Danny Kukawka]

On Sunday 21 January 2007 23:54, Richard Hughes wrote:
> On Sun, 2007-01-21 at 23:39 +0100, Danny Kukawka wrote:
[...]
> > 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.

Avoid in the meaning of the word does not mean don't fix, but avoid not needed 
changes and be really carefully with each change.

> 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.

This can happen ... at least not all keys are mandatory. HAL was developed as 
first for x86 arch (I'm not feel confident that it's always a good idea to 
share/provide everything for each arch/platform under the same key ... but 
this something complete other) so there can be historical reasons for such 
keys. 

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

I didn't say that, but if they don't have a BIOS: there is no reason to 
provide these information.

> > 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.

This is a general issue. It can be that this change work if both get shipped 
together, but with future changes this can be a problem. As I already said in 
the past: IMO hal-info make no sense at least because of these problems and 
maintenance for distributions especially with such key remove/change tasks.

Danny