What's part of the ABI (breaking eeepc-wmi)

What's part of the ABI (breaking eeepc-wmi)

[Corentin Chary]

Hi,
I recently discovered that new Asus notebooks (eg: not Eeepc) are now
shipped with an ACPI WMI device instead of the old ACPI Atkd device.
Most of this device is similar to the Eeepc ACPI WMI device, except
for keymap and event GUID.

I could add support for these notebooks in eeepc-wmi, but that seems
really weird.

A first solution is to rename eeepc-wmi asus-wmi, and create an alias
to make eeepc-wmi work. Then this driver would handle asus-wmi and
eeepc-wmi platform drivers (it could also be splitted in 3
files/modules, common/notebook/eeepc).
But then, is it important to keep these strings ?
- hotplug string ("eeepc-wifi")
- rfkill names ("eeepc-xxxxx")
- led names ("eeepc::xxxxxx")
- input strings (.phys and .name)

If these strings should really be keeped for backward compatibility, I
was thinking of something like that:

----
struct module;
struct key_entry;

static struct asus_wmi_driver {
  const char                    *name;
  struct module                 *owner;

  const struct key_entry        *keymap;

  int (*probe) (struct asus_wmi *asus);
  int (*quirks) (struct asus_wmi *asus);

  struct {
    const char                  *input_name;
    const char                  *input_phys;
    const char                  *led_touchpad;
    const char                  *hotplug_wlan;
    const char                  *rfkill_wlan;
    const char                  *rfkill_bluetooth;
    const char                  *rfkill_wimax;
    const char                  *rfkill_wwan3g;
  } strings;

  struct asus_wmi *device;
};

int asus_wmi_register_driver(struct asus_wmi_driver *driver);
void asus_wmi_unregister_driver(struct asus_wmi_driver *driver);
----

Any thoughts on that ?

-- 
Corentin Chary
http://xf.iksaif.net

Re: What's part of the ABI (breaking eeepc-wmi)

[Matthew Garrett]

On Tue, Feb 08, 2011 at 08:51:27AM +0000, Corentin Chary wrote:

> A first solution is to rename eeepc-wmi asus-wmi, and create an alias
> to make eeepc-wmi work. Then this driver would handle asus-wmi and
> eeepc-wmi platform drivers (it could also be splitted in 3
> files/modules, common/notebook/eeepc).
> But then, is it important to keep these strings ?
> - hotplug string ("eeepc-wifi")
> - rfkill names ("eeepc-xxxxx")
> - input strings (.phys and .name)

I think that, realistically, these changes should be fine but may break 
some user code. We don't have a good way of enforcing proper sysfs 
usage.

> - led names ("eeepc::xxxxxx")

But I don't think there's any other way of identifying LEDs, so this 
probably has to stay.

> Any thoughts on that ?

Seems less ugly than the alternatives!

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: What's part of the ABI (breaking eeepc-wmi)

[Corentin Chary]

On Tue, Feb 8, 2011 at 2:53 PM, Matthew Garrett <mjg59@srcf.ucam.org> wrote:
> On Tue, Feb 08, 2011 at 08:51:27AM +0000, Corentin Chary wrote:
>
>> A first solution is to rename eeepc-wmi asus-wmi, and create an alias
>> to make eeepc-wmi work. Then this driver would handle asus-wmi and
>> eeepc-wmi platform drivers (it could also be splitted in 3
>> files/modules, common/notebook/eeepc).
>> But then, is it important to keep these strings ?
>> - hotplug string ("eeepc-wifi")
>> - rfkill names ("eeepc-xxxxx")
>> - input strings (.phys and .name)
>
> I think that, realistically, these changes should be fine but may break
> some user code. We don't have a good way of enforcing proper sysfs
> usage.

Unfortunatly, it would break udev (well.. only the touchpad key, which
probably never worked, does it really matters ?) ...

http://git.kernel.org/?p=linux/hotplug/udev.git;a=blobdiff;f=extras/keymap/95-keymap.rules;h=9059a8c41e4505f0d8088a90fc0c3a64fe8d5f2d;hp=053838d803d7142dd80fbca361ef65565c6189f2;hb=0d8b6be5f5238360d2d8e220d6da280f842c5358;hpb=e99cc72398d1d5057cc6d1e4c065799f8daaf29e

But your probably right for rfkill and hotplug slot name.

>> - led names ("eeepc::xxxxxx")
>
> But I don't think there's any other way of identifying LEDs, so this
> probably has to stay.

Yep .. but as this led probably never worked before the last patchset,
this is probably not the most important string to keep. And users
tends to use only the second part of the led name (*::touchpad,
*::kbd_backlight, etc...).

>> Any thoughts on that ?
>
> Seems less ugly than the alternatives!

Ok, I'll try to do something like that.

asus-wmi.ko - generic stuff
asus-nb-wmi.ko - used only on notebooks (bweark, asus-nb-wmi is an
horrible name :/)
eeepc-wmi.ko  - used only on eeepcs

And you'll be able to register only one asus_wmi_driver at a time,
since asus-wmi will have some static stuff in it (hotplug_slot_ops,
device_attribute, attribute, attribute_group, dev_pm_ops).

-- 
Corentin Chary
http://xf.iksaif.net

Re: What's part of the ABI (breaking eeepc-wmi)

[Dmitry Torokhov]

On Tue, Feb 08, 2011 at 03:17:35PM +0000, Corentin Chary wrote:
> On Tue, Feb 8, 2011 at 2:53 PM, Matthew Garrett <mjg59@srcf.ucam.org> wrote:
> > On Tue, Feb 08, 2011 at 08:51:27AM +0000, Corentin Chary wrote:
> >
> >> A first solution is to rename eeepc-wmi asus-wmi, and create an alias
> >> to make eeepc-wmi work. Then this driver would handle asus-wmi and
> >> eeepc-wmi platform drivers (it could also be splitted in 3
> >> files/modules, common/notebook/eeepc).
> >> But then, is it important to keep these strings ?
> >> - hotplug string ("eeepc-wifi")
> >> - rfkill names ("eeepc-xxxxx")
> >> - input strings (.phys and .name)
> >
> > I think that, realistically, these changes should be fine but may break
> > some user code. We don't have a good way of enforcing proper sysfs
> > usage.
> 
> Unfortunatly, it would break udev (well.. only the touchpad key, which
> probably never worked, does it really matters ?) ...
> 
> http://git.kernel.org/?p=linux/hotplug/udev.git;a=blobdiff;f=extras/keymap/95-keymap.rules;h=9059a8c41e4505f0d8088a90fc0c3a64fe8d5f2d;hp=053838d803d7142dd80fbca361ef65565c6189f2;hb=0d8b6be5f5238360d2d8e220d6da280f842c5358;hpb=e99cc72398d1d5057cc6d1e4c065799f8daaf29e
> 
> But your probably right for rfkill and hotplug slot name.
> 

As we can't be sure about individual user's set ups (they might very
well use their own rules and maps) we should try to keep the existign
setups intact, if at all possible.

Thanks.

-- 
Dmitry