この間、Linuxもくもく会に行ってきました。

2点後悔しました。晩飯を事前に食べておけばよかったという点がひとつ、もうひとつはもっとバッテリーの持ちが良いノートPCを買うべきです。
MBA持つ人が増えつつあるのもわかります...。
まあ、それは措いて。もくもく会でソース読んだ記録を残します。

ACPI周り

組み込みとかでこのあたりに関わった人は、色々と面倒なことになります(笑)。ちょっとバグるとストールする、まさにスペランカーのような世界が展開されます。
私は職業柄NetBSDがメインですが、Linuxはどうなってるのかなー、と気になった次第。

キーワードで思いつくのは...Power Managementモードの一つ、S3 Stateをキーワードにソースの在り処を探ってみます。

eria@eria-thinkpad:~/source/linux-3.19 % grep -rIi "S3 state" *
arch/x86/include/asm/cpufeature.h:#define X86_FEATURE_NONSTOP_TSC_S3 ( 3*32+30) /* TSC doesn't stop in S3 state */
drivers/ide/Kconfig:      machines ACPI support is required to properly handle ACPI S3 states.
kernel/power/Kconfig:     suspend-to-RAM state (e.g. the ACPI S3 state).

kernel/powerの下を覗けば良さそうです。

eria@eria-thinkpad:~/source/linux-3.19/kernel/power % ls
Kconfig         console.c       poweroff.c      suspend.c       wakelock.c
Makefile        hibernate.c     process.c       suspend_test.c
autosleep.c     main.c          qos.c           swap.c
block_io.c      power.h         snapshot.c      user.c
eria@eria-thinkpad:~/source/linux-3.19/kernel/power % pwd
/usr/home/eria/source/linux-3.19/kernel/power

さっそくソースをチラ見しましょう。(書き忘れましたが、ソースのバージョンは、3.19を基にしています。)
まずは、最初に見ろといわんばかりの、main.cを見ます。

kernel/power/main.c

#ifdef CONFIG_PM_SLEEP

/* Routines for PM-transition notifications */

static BLOCKING_NOTIFIER_HEAD(pm_chain_head);

int register_pm_notifier(struct notifier_block *nb)
{
    return blocking_notifier_chain_register(&pm_chain_head, nb);
}
EXPORT_SYMBOL_GPL(register_pm_notifier);

int unregister_pm_notifier(struct notifier_block *nb)
{
    return blocking_notifier_chain_unregister(&pm_chain_head, nb);
}
EXPORT_SYMBOL_GPL(unregister_pm_notifier);

int pm_notifier_call_chain(unsigned long val)
{
    int ret = blocking_notifier_call_chain(&pm_chain_head, val, NULL);

    return notifier_to_errno(ret);
}

/* 略 */

/* If set, devices may be suspended and resumed asynchronously. */
int pm_async_enabled = 1;

static ssize_t pm_async_show(struct kobject *kobj, struct kobj_attribute *attr,
                 char *buf)
{
    return sprintf(buf, "%d\n", pm_async_enabled);
}

static ssize_t pm_async_store(struct kobject *kobj, struct kobj_attribute *attr,
                  const char *buf, size_t n)
{
    unsigned long val;

    if (kstrtoul(buf, 10, &val))
        return -EINVAL;

    if (val > 1)
        return -EINVAL;

    pm_async_enabled = val;
    return n;
}

suspendとresume、BSD系のACPI実装読んだ経験から、Power Managementモード遷移時に呼ばれるフック関数と推定。
(main.c読んで、グローバル変数の別コードからの直アクセスは個人的に気になった・・・)

次に来るのは、ifdefのラベル名からデバッグコードと思われるので、省略します。

kernel/power/main.c

struct kobject *power_kobj;


/**
 * state - control system sleep states.
 *
 * show() returns available sleep state labels, which may be "mem", "standby",
 * "freeze" and "disk" (hibernation).  See Documentation/power/states.txt for a
 * description of what they mean.
 *
 * store() accepts one of those strings, translates it into the proper
 * enumerated value, and initiates a suspend transition.
 */

show()は単なる情報表示と思われ、読んでもあまり面白くなさそうです。なので、次のstore()を読みます。

kernel/power/main.c

static ssize_t state_store(struct kobject *kobj, struct kobj_attribute *attr,
               const char *buf, size_t n)
{
    suspend_state_t state;
    int error;

    error = pm_autosleep_lock();
    if (error)
        return error;

    if (pm_autosleep_state() > PM_SUSPEND_ON) {
        error = -EBUSY;
        goto out;
    }

    state = decode_state(buf, n);
    if (state < PM_SUSPEND_MAX)
        error = pm_suspend(state);
    else if (state == PM_SUSPEND_MAX)
        error = hibernate();
    else
        error = -EINVAL;

 out:
    pm_autosleep_unlock();
    return error ? error : n;
}

つまり、stateがPM_SUSPEND_MAXなら、hibernate()が呼ばれ、そうでないのならpm_suspend()が呼ばれる実に簡単なコード。

今は措いて、main.cを先に進む。
コメントが長い。

kernel/power/main.c

/*
 * The 'wakeup_count' attribute, along with the functions defined in
 * drivers/base/power/wakeup.c, provides a means by which wakeup events can be
 * handled in a non-racy way.
 *

この記述で、LinuxのPower Management機能はkernelの機能だけでなく、ドライバが介在していそうなことがわかる。

kernel/power/main.c

 * If a wakeup event occurs when the system is in a sleep state, it simply is
 * woken up.  In turn, if an event that would wake the system up from a sleep
 * handled in a non-racy way.
 *
 * If a wakeup event occurs when the system is in a sleep state, it simply is
 * woken up.  In turn, if an event that would wake the system up from a sleep
 * state occurs when it is undergoing a transition to that sleep state, the
 * transition should be aborted.  Moreover, if such an event occurs when the
 * system is in the working state, an attempt to start a transition to the
 * given sleep state should fail during certain period after the detection of
 *
 * If a wakeup event occurs when the system is in a sleep state, it simply is
 * woken up.  In turn, if an event that would wake the system up from a sleep
 * state occurs when it is undergoing a transition to that sleep state, the
 * transition should be aborted.  Moreover, if such an event occurs when the
 * system is in the working state, an attempt to start a transition to the
 * given sleep state should fail during certain period after the detection of
 * the event.  Using the 'state' attribute alone is not sufficient to satisfy
 * these requirements, because a wakeup event may occur exactly when 'state'
 * is being written to and may be delivered to user space right before it is
 * frozen, so the event will remain only partially processed until the system is
 * woken up by another event.  In particular, it won't cause the transition to
 * a sleep state to be aborted.
 *
 * This difficulty may be overcome if user space uses 'wakeup_count' before
 * writing to 'state'.  It first should read from 'wakeup_count' and store
 * the read value.  Then, after carrying out its own preparations for the system
 * transition to a sleep state, it should write the stored value to
 * 'wakeup_count'.  If that fails, at least one wakeup event has occurred since
 * 'wakeup_count' was read and 'state' should not be written to.  Otherwise, it
 * is allowed to write to 'state', but the transition will be aborted if there
 * are any wakeup events detected after 'wakeup_count' was written to.
 */

超長いが、要するに「Wake -> sleepに遷移する途中のWakeupイベント...sleep遷移をアボートすべき」「Working state時にWakeupイベントが起きたら、sleepに遷移すべきでない」ということ。
要するにPower Managementの状態遷移時に、さらに状態遷移の要因となるイベントが起きたときのポリシーが述べられています。
ユーザがシステムを使うのだから、極力使えるような状態にすべし、というポリシーが読み取れますね。
コメントの続き読みます。

kernel/power/main.c

 * This difficulty may be overcome if user space uses 'wakeup_count' before
 * writing to 'state'.  It first should read from 'wakeup_count' and store
 * the read value.  Then, after carrying out its own preparations for the system
 * transition to a sleep state, it should write the stored value to
 * 'wakeup_count'.

ここから伺えることは、「何らかのユーザプロセスが、Power Managementの制御に関わっている。そして、状態遷移のハンドリングはwakeup_countとstateを使ってユーザプロセスが行っているということ」が読み取れます。
仕様書がないソフトを読む際に、コメントは面倒臭がらずに読む。
特にOSSのコード内の長いコメントは残念SIerの「iに1を代入する」的なコメントと違い、何らかの重要な意味があると心得るところ、大事ですね。

kernel/power/main.c

static ssize_t wakeup_count_store(struct kobject *kobj,
                struct kobj_attribute *attr,
                const char *buf, size_t n)
{
/* 略 */
    if (sscanf(buf, "%u", &val) == 1) {
        if (pm_save_wakeup_count(val))
            error = n;
        else
            pm_print_active_wakeup_sources();
    }

基本は受け取ったsigned integerをwakeup_countというパラメータにセットするということね。これが何かは今後わかってくるでしょう。

kernel/power/main.c

#ifdef CONFIG_PM_AUTOSLEEP

このifdefで囲まれているコードは何だろうか。
やっていることは先に記載したshowとsetとあまり変わらない。
このような感じで、数個のifdefが並び、同じようなことが繰り返されている。

kernel/power/main.c

static struct attribute * g[] = {
    &state_attr.attr,
#ifdef CONFIG_PM_TRACE
    &pm_trace_attr.attr,
    &pm_trace_dev_match_attr.attr,
#endif
#ifdef CONFIG_PM_SLEEP
    &pm_async_attr.attr,
    &wakeup_count_attr.attr,
#ifdef CONFIG_PM_AUTOSLEEP
    &autosleep_attr.attr,
#endif
#ifdef CONFIG_PM_WAKELOCKS
    &wake_lock_attr.attr,
    &wake_unlock_attr.attr,
#endif
#ifdef CONFIG_PM_DEBUG
    &pm_test_attr.attr,
#endif
#ifdef CONFIG_PM_SLEEP_DEBUG
    &pm_print_times_attr.attr,
#endif
#ifdef CONFIG_FREEZER
    &pm_freeze_timeout_attr.attr,
#endif
    NULL,
};

これで同じような実装が続く謎が解けた。show()とset()を関数ポインタ使って呼び分けている。
これらI/Fをsysfsを用いてユーザランドに見せているのが、以下の初期化コードであると思われる。

kernel/power/main.c

static struct attribute_group attr_group = {
    .attrs = g,
};

struct workqueue_struct *pm_wq;
EXPORT_SYMBOL_GPL(pm_wq);

static int __init pm_start_workqueue(void)
{
    pm_wq = alloc_workqueue("pm", WQ_FREEZABLE, 0);

    return pm_wq ? 0 : -ENOMEM;
}

static int __init pm_init(void)
{
    int error = pm_start_workqueue();
    if (error)
        return error;
    hibernate_image_size_init();
    hibernate_reserved_size_init();
    hibernate_reserved_size_init();
    power_kobj = kobject_create_and_add("power", NULL);
    if (!power_kobj)
        return -ENOMEM;
    error = sysfs_create_group(power_kobj, &attr_group);
    if (error)
        return error;
    pm_print_times_init();
    return pm_autosleep_init();
}

sysfsは、以下のとおり、BSDのsysctlのようなものです。
http://ja.wikipedia.org/wiki/Sysfs

あと、kobjectも以下補足します。
http://wiki.bit-hive.com/north/pg/sysfs%A4%C8kobject
http://dev.ariel-networks.com/Members/ohyama/i-o-30b930b130e530fc30e9306e-sysfs-30a830f330c830ea306b306430443066306e307e30683081/

「sysfs のディレクトリファイルは kobject というデータ構造で表現され、各 kobject に属性 (attribute) 情報がぶら下がり、これがファイルという形でユーザに提供されています。」という記述から、先の推定は正しそうです。