Hm, sorry.
I thought it would have been weird to send patches 1-13 / 14 to
linux-arch, but not send 14 / 14. Perhaps I should set a Reply-to:
in the future?
These are not new tables -- they are methods that live underneath
processor objects in the namespace.
Yes, they are specific to HP, but because they are methods, there
shouldn't be any collision with other vendors defining methods
with the same name (with the DMI check).
Yeah, I'm not totally happy with it either. But I'd like to
clarify -- are you concerned with the name of the interface
(deconfigure) or the "nothing happens until next boot" behavior?
Would it help if I renamed it to "enabled" and had something
like:
echo 0 > enabled
echo 1 > enabled
cat enabled
And then that would map to vendor-specific behavior?
Or is it really the "nothing happens until next boot" thing that
bothers you?
Well, life would be a lot easier if we had a generic way to poke
at ACPI methods, but dev_acpi has been rejected multiple times.
;)
On a more serious note, my fear is that an interface like this is
not going to have agreement / clear semantics for a long time
because one vendor is going to want to call it 'deconfigured' and
another one might want to call it 'disabled' and a third might
want to call it 'puppy_dogs' and they'll all be kinda related but
not exactly the same.
That's why I was going down the road of creating at least one
generic interface, but with vendor-specific semantics.
Calling it 'enabled' might be a better idea.
We have HP ia64 systems shipping today that support this.
Thanks.
/ac
--
