All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Henrik Rydberg" <rydberg@euromail.se>
To: "Gabriel L. Somlo" <somlo@cmu.edu>
Cc: Guenter Roeck <groeck-dsl@sbcglobal.net>,
	khali@linux-fr.org, linux@roeck-us.net,
	lm-sensors@lm-sensors.org, linux-kernel@vger.kernel.org,
	agraf@suse.de, rene@exactcode.com
Subject: Re: [lm-sensors] [PATCH v2] applesmc: add sysfs file to report OSK
Date: Thu, 13 Dec 2012 07:20:11 +0000	[thread overview]
Message-ID: <20121213072011.GA515@polaris.bitmath.org> (raw)
In-Reply-To: <20121212230128.GE16373@lobsang.ini.cmu.edu>

Hi Gabriel,

> I could try to hardcode the OSK inside QEMU, or I could try to include
> it as a default config file entry, but I'm quite certain the QEMU project
> would be uncomfortable "distributing" a string on which Apple claims
> copyright. Even if that happened, distros might then balk at shipping
> QEMU as part of their package repositories, for the exact same reason.

I understand this is frustrating, and I believe you have made a good
case for the rationale. However, the technical issues remain. Also,
there might still be other, simpler, solutions.

> The only viable (from a legal CYA standpoint) thing I can think of is
> to make it easy to acquire the OSK automatically, on demand, directly
> from the hardware. Right now, the logical place for that is applesmc.ko.
> It already controls access to the SMC, and already reports values for
> various keys.

How about encrypting the string with a key only found on an Apple
computer? There are strings available in both ACPI and EFI that could
serve such a purpose.

Regarding the patch, I agree with Guenter that putting more unrelated
things into the hwmon subsystem makes no sense. Most of the
information in applesmc should go into the hwmon, thermal, backlight
and input subsystems, but some strings should go somewhere else (maybe
/sys/firmware/smc/?). The reluctance you experience here is a
technical one; someone will need to make an effort to create a good
place for your string, and it does not help that the string is, in
fact, a constant. :-)

So, don't give up hope, but please do not expect an immediate solution.

Thanks.
Henrik

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

WARNING: multiple messages have this Message-ID (diff)
From: "Henrik Rydberg" <rydberg@euromail.se>
To: "Gabriel L. Somlo" <somlo@cmu.edu>
Cc: Guenter Roeck <groeck-dsl@sbcglobal.net>,
	khali@linux-fr.org, linux@roeck-us.net,
	lm-sensors@lm-sensors.org, linux-kernel@vger.kernel.org,
	agraf@suse.de, rene@exactcode.com
Subject: Re: [PATCH v2] applesmc: add sysfs file to report OSK
Date: Thu, 13 Dec 2012 08:20:11 +0100	[thread overview]
Message-ID: <20121213072011.GA515@polaris.bitmath.org> (raw)
In-Reply-To: <20121212230128.GE16373@lobsang.ini.cmu.edu>

Hi Gabriel,

> I could try to hardcode the OSK inside QEMU, or I could try to include
> it as a default config file entry, but I'm quite certain the QEMU project
> would be uncomfortable "distributing" a string on which Apple claims
> copyright. Even if that happened, distros might then balk at shipping
> QEMU as part of their package repositories, for the exact same reason.

I understand this is frustrating, and I believe you have made a good
case for the rationale. However, the technical issues remain. Also,
there might still be other, simpler, solutions.

> The only viable (from a legal CYA standpoint) thing I can think of is
> to make it easy to acquire the OSK automatically, on demand, directly
> from the hardware. Right now, the logical place for that is applesmc.ko.
> It already controls access to the SMC, and already reports values for
> various keys.

How about encrypting the string with a key only found on an Apple
computer? There are strings available in both ACPI and EFI that could
serve such a purpose.

Regarding the patch, I agree with Guenter that putting more unrelated
things into the hwmon subsystem makes no sense. Most of the
information in applesmc should go into the hwmon, thermal, backlight
and input subsystems, but some strings should go somewhere else (maybe
/sys/firmware/smc/?). The reluctance you experience here is a
technical one; someone will need to make an effort to create a good
place for your string, and it does not help that the string is, in
fact, a constant. :-)

So, don't give up hope, but please do not expect an immediate solution.

Thanks.
Henrik

  reply	other threads:[~2012-12-13  7:20 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-12-10 14:51 [lm-sensors] [PATCH] applesmc: add sysfs file to report OSK Gabriel L. Somlo
2012-12-10 14:51 ` Gabriel L. Somlo
2012-12-10 16:44 ` [lm-sensors] " Alexander Graf
2012-12-10 16:44   ` Alexander Graf
2012-12-10 19:09 ` [lm-sensors] " Guenter Roeck
2012-12-10 19:09   ` Guenter Roeck
2012-12-10 19:54   ` [lm-sensors] " Henrik Rydberg
2012-12-10 19:54     ` Henrik Rydberg
2012-12-10 20:19     ` [lm-sensors] " Alexander Graf
2012-12-10 20:19       ` Alexander Graf
2012-12-10 20:43       ` [lm-sensors] " Rene Rebe
2012-12-10 20:43         ` Rene Rebe
2012-12-10 21:24         ` [lm-sensors] " Alexander Graf
2012-12-10 21:24           ` Alexander Graf
2012-12-10 21:30           ` [lm-sensors] " Rene Rebe
2012-12-10 21:30             ` Rene Rebe
2012-12-10 22:23     ` [lm-sensors] [PATCH v2] " Gabriel L. Somlo
2012-12-10 22:23       ` Gabriel L. Somlo
2012-12-12 23:01       ` [lm-sensors] " Gabriel L. Somlo
2012-12-12 23:01         ` Gabriel L. Somlo
2012-12-13  7:20         ` Henrik Rydberg [this message]
2012-12-13  7:20           ` Henrik Rydberg
2012-12-13 19:07           ` [lm-sensors] " Gabriel L. Somlo
2012-12-13 19:07             ` Gabriel L. Somlo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20121213072011.GA515@polaris.bitmath.org \
    --to=rydberg@euromail.se \
    --cc=agraf@suse.de \
    --cc=groeck-dsl@sbcglobal.net \
    --cc=khali@linux-fr.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@roeck-us.net \
    --cc=lm-sensors@lm-sensors.org \
    --cc=rene@exactcode.com \
    --cc=somlo@cmu.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.