[lkml]   [2012]   [Dec]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH v2] applesmc: add sysfs file to report OSK
    On Thu, Dec 13, 2012 at 08:20:11AM +0100, Henrik Rydberg wrote:
    > > 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.

    I'd still be distributing the copyrighted string. I don't expect
    encryption to placate the proverbial lawyers, nor the project/distro
    maintainers who want to avoid them :)

    Plus, now I'd also be taking on the responsibility of deciding when
    it's (legally) OK to let QEMU boot OS X and when it isn't.

    Besides, the most obvious Apple-only key that fits your description
    is the OSK itself ! :)

    > 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.

    OK, so if we agree that for legal-CYA reasons we must pretend to
    ignore the constant-ness of the key value, are we now talking about
    simply where in the sysfs hierarchy to place the node that will
    spit it out ?

    Right now it's under /sys/devices/platform/applesmc.768/
    (i.e., it's a device, it's platform specific, and it's name is

    The only ties to "hwmon" are that:
    - there's a "/sys/class/hwmon/hwmonX" symlink to the above
    directory (among others, such as the graphics card and two
    instances of "coretemp", at least on my MacPro5,1);
    - *most* of the files in it are indeed reporting sensor
    - the applesmc.c device driver source file itself lives under
    drivers/hwmon/ in the kernel source tree.

    Is it common practice to split off a subset of the values reported
    by such a chip and make them show up elsehere (i.e. besides the
    /sys/devices/platform/<chipname> folder) ? Does the relative size
    of the subsets involved count as input into that decision proces ? :)

    I personally don't know enough to have an opinion on where the best
    place for this might be. You suggested "/sys/firmware/smc/", and I'd
    be perfectly happy with that one too. Do you know who would decide
    whether that's an acceptable alternative to /sys/devices/platform/applesmc ?

    Thanks again,

     \ /
      Last update: 2012-12-13 20:41    [W:0.128 / U:1.316 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site