All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rene Rebe <rene@exactcode.com>
To: Alexander Graf <agraf@suse.de>
Cc: Henrik Rydberg <rydberg@euromail.se>,
	Guenter Roeck <groeck-dsl@sbcglobal.net>,
	"Gabriel L. Somlo" <somlo@cmu.edu>,
	"khali@linux-fr.org" <khali@linux-fr.org>,
	"linux@roeck-us.net" <linux@roeck-us.net>,
	"lm-sensors@lm-sensors.org" <lm-sensors@lm-sensors.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [lm-sensors] [PATCH] applesmc: add sysfs file to report OSK
Date: Mon, 10 Dec 2012 21:30:08 +0000	[thread overview]
Message-ID: <F7D71BD5-59D8-4DDA-9537-606DF222DBA5@exactcode.com> (raw)
In-Reply-To: <28FE8A08-131B-4E20-BBC0-EEDDA129C1C8@suse.de>


On 10.12.2012, at 22:24, Alexander Graf wrote:

> On 10.12.2012, at 21:43, Rene Rebe <rene@exactcode.com> wrote:
> 
>> On 10.12.2012, at 21:19, Alexander Graf <agraf@suse.de> wrote:
>>> 
>>> On 10.12.2012, at 20:54, Henrik Rydberg wrote:
>>> 
>>>> Hi Guenter,
>>>> 
>>>>> On Mon, Dec 10, 2012 at 09:51:35AM -0500, Gabriel L. Somlo wrote:
>>>>>> The AppleSMC contains two char[32] keys, OSK0 and OSK1, which are not
>>>>>> reported in the key count and index by default. These keys are used by
>>>>>> the OS X boot sequence, and normally don't matter when running Linux.
>>>>>> 
>>>>>> This patch creates a sysfs entry which reports the value of these keys
>>>>>> as an ASCII string, to help emulators (such as QEMU) load OS X when
>>>>>> running on genuine Apple hardware.
>>>>>> 
>>>>>> Signed-off-by: Gabriel L. Somlo <somlo@cmu.edu>
>>>>>> ---
>>>>>> 
>>>>>> For extra context: To boot OS X as a guest, QEMU must (among others)
>>>>>> emulate the AppleSMC. To boot successfully, OS X insists on querying
>>>>>> the (emulated) SMC for the value of OSK0 and OSK1. Currently, these
>>>>>> values must be supplied on the QEMU command line as
>>>>>> 
>>>>>> -device applesmc,osk="...concatenated values of OSK0 and OSK1..."
>>>>>> 
>>>>>> With the availability of /sys/devices/platform/applesmc.768/osk, the
>>>>>> emulated QEMU AppleSMC could acquire this string directly from the
>>>>>> (Apple-manufactured) host machine.
>>>>> Hmm ... this is a non-hwmon attribute which doesn't really belong into hwmon
>>>>> in the first place ... like several other attributes in the same driver.
>>>>> 
>>>>> So I'll leave it up to the maintainer to decide if we should accept it. Henrik ?
>>>> 
>>>> Indeed, the reaons against this patch are too many. I was just about
>>>> to reply with the below:
>>>> 
>>>> Gabriel,
>>>> 
>>>> The OSK string seems constant accross machines, which renders the
>>>> patch rather pointless, no? And even if the OSK differs between a
>>>> couple of machines, the emulator could easily handle it gracefully.
>>> 
>>> The point is that the return value of the OSK is a copyrighted string, we can not include in any other layer. The only way to make this legally savvy is to read the key from the host.
>>> 
>>>> 
>>>> There are also some technical issues with the patch below, to keep in
>>>> mind for future submissions.
>>> 
>>> Sigh - most of the comments below go back to earlier review from me. He basically had a version almost exactly like what you're asking him to do :). Funny how code style taste differs.
>> 
>> And this is exactly the reason why I'm less and less motivated to waste my lifetime with upstream work ...
> 
> It's nit that bad really. Gabriel can just send his earlier version again with the ret variable name changed and then it shouldn't be an issue to get it in.
> 
> Reading the key really is an important bit in creating a legally safe and easy method to virtualize Mac OS X on Linux. Just believe us on this one :).

Sure, you do not need to convince me about that ;-)

-- 
  René Rebe, ExactCODE GmbH, Jaegerstr. 67, DE-10117 Berlin
  http://exactcode.com | http://t2-project.org | http://rene.rebe.de


_______________________________________________
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: Rene Rebe <rene@exactcode.com>
To: Alexander Graf <agraf@suse.de>
Cc: Henrik Rydberg <rydberg@euromail.se>,
	Guenter Roeck <groeck-dsl@sbcglobal.net>,
	"Gabriel L. Somlo" <somlo@cmu.edu>,
	"khali@linux-fr.org" <khali@linux-fr.org>,
	"linux@roeck-us.net" <linux@roeck-us.net>,
	"lm-sensors@lm-sensors.org" <lm-sensors@lm-sensors.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] applesmc: add sysfs file to report OSK
Date: Mon, 10 Dec 2012 22:30:08 +0100	[thread overview]
Message-ID: <F7D71BD5-59D8-4DDA-9537-606DF222DBA5@exactcode.com> (raw)
In-Reply-To: <28FE8A08-131B-4E20-BBC0-EEDDA129C1C8@suse.de>


On 10.12.2012, at 22:24, Alexander Graf wrote:

> On 10.12.2012, at 21:43, Rene Rebe <rene@exactcode.com> wrote:
> 
>> On 10.12.2012, at 21:19, Alexander Graf <agraf@suse.de> wrote:
>>> 
>>> On 10.12.2012, at 20:54, Henrik Rydberg wrote:
>>> 
>>>> Hi Guenter,
>>>> 
>>>>> On Mon, Dec 10, 2012 at 09:51:35AM -0500, Gabriel L. Somlo wrote:
>>>>>> The AppleSMC contains two char[32] keys, OSK0 and OSK1, which are not
>>>>>> reported in the key count and index by default. These keys are used by
>>>>>> the OS X boot sequence, and normally don't matter when running Linux.
>>>>>> 
>>>>>> This patch creates a sysfs entry which reports the value of these keys
>>>>>> as an ASCII string, to help emulators (such as QEMU) load OS X when
>>>>>> running on genuine Apple hardware.
>>>>>> 
>>>>>> Signed-off-by: Gabriel L. Somlo <somlo@cmu.edu>
>>>>>> ---
>>>>>> 
>>>>>> For extra context: To boot OS X as a guest, QEMU must (among others)
>>>>>> emulate the AppleSMC. To boot successfully, OS X insists on querying
>>>>>> the (emulated) SMC for the value of OSK0 and OSK1. Currently, these
>>>>>> values must be supplied on the QEMU command line as
>>>>>> 
>>>>>> -device applesmc,osk="...concatenated values of OSK0 and OSK1..."
>>>>>> 
>>>>>> With the availability of /sys/devices/platform/applesmc.768/osk, the
>>>>>> emulated QEMU AppleSMC could acquire this string directly from the
>>>>>> (Apple-manufactured) host machine.
>>>>> Hmm ... this is a non-hwmon attribute which doesn't really belong into hwmon
>>>>> in the first place ... like several other attributes in the same driver.
>>>>> 
>>>>> So I'll leave it up to the maintainer to decide if we should accept it. Henrik ?
>>>> 
>>>> Indeed, the reaons against this patch are too many. I was just about
>>>> to reply with the below:
>>>> 
>>>> Gabriel,
>>>> 
>>>> The OSK string seems constant accross machines, which renders the
>>>> patch rather pointless, no? And even if the OSK differs between a
>>>> couple of machines, the emulator could easily handle it gracefully.
>>> 
>>> The point is that the return value of the OSK is a copyrighted string, we can not include in any other layer. The only way to make this legally savvy is to read the key from the host.
>>> 
>>>> 
>>>> There are also some technical issues with the patch below, to keep in
>>>> mind for future submissions.
>>> 
>>> Sigh - most of the comments below go back to earlier review from me. He basically had a version almost exactly like what you're asking him to do :). Funny how code style taste differs.
>> 
>> And this is exactly the reason why I'm less and less motivated to waste my lifetime with upstream work ...
> 
> It's nit that bad really. Gabriel can just send his earlier version again with the ret variable name changed and then it shouldn't be an issue to get it in.
> 
> Reading the key really is an important bit in creating a legally safe and easy method to virtualize Mac OS X on Linux. Just believe us on this one :).

Sure, you do not need to convince me about that ;-)

-- 
  René Rebe, ExactCODE GmbH, Jaegerstr. 67, DE-10117 Berlin
  http://exactcode.com | http://t2-project.org | http://rene.rebe.de


  reply	other threads:[~2012-12-10 21:30 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           ` Rene Rebe [this message]
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         ` [lm-sensors] " Henrik Rydberg
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=F7D71BD5-59D8-4DDA-9537-606DF222DBA5@exactcode.com \
    --to=rene@exactcode.com \
    --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=rydberg@euromail.se \
    --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.