On 10.12.2012, at 21:43, Rene Rebe <r...@exactcode.com> wrote: > > On 10.12.2012, at 21:19, Alexander Graf <ag...@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 <so...@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 :). Alex -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
