mirror of
https://github.com/ukui/kernel.git
synced 2026-03-09 10:07:04 -07:00
Merge branch 'driver-core-next' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core-2.6
* 'driver-core-next' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core-2.6: (44 commits) debugfs: Silence DEBUG_STRICT_USER_COPY_CHECKS=y warning sysfs: remove "last sysfs file:" line from the oops messages drivers/base/memory.c: fix warning due to "memory hotplug: Speed up add/remove when blocks are larger than PAGES_PER_SECTION" memory hotplug: Speed up add/remove when blocks are larger than PAGES_PER_SECTION SYSFS: Fix erroneous comments for sysfs_update_group(). driver core: remove the driver-model structures from the documentation driver core: Add the device driver-model structures to kerneldoc Translated Documentation/email-clients.txt RAW driver: Remove call to kobject_put(). reboot: disable usermodehelper to prevent fs access efivars: prevent oops on unload when efi is not enabled Allow setting of number of raw devices as a module parameter Introduce CONFIG_GOOGLE_FIRMWARE driver: Google Memory Console driver: Google EFI SMI x86: Better comments for get_bios_ebda() x86: get_bios_ebda_length() misc: fix ti-st build issues params.c: Use new strtobool function to process boolean inputs debugfs: move to new strtobool ... Fix up trivial conflicts in fs/debugfs/file.c due to the same patch being applied twice, and an unrelated cleanup nearby.
This commit is contained in:
Linus Torvalds
@@ -14,14 +14,15 @@ Description:
|
||||
|
||||
DMI is structured as a large table of entries, where
|
||||
each entry has a common header indicating the type and
|
||||
length of the entry, as well as 'handle' that is
|
||||
supposed to be unique amongst all entries.
|
||||
length of the entry, as well as a firmware-provided
|
||||
'handle' that is supposed to be unique amongst all
|
||||
entries.
|
||||
|
||||
Some entries are required by the specification, but many
|
||||
others are optional. In general though, users should
|
||||
never expect to find a specific entry type on their
|
||||
system unless they know for certain what their firmware
|
||||
is doing. Machine to machine will vary.
|
||||
is doing. Machine to machine experiences will vary.
|
||||
|
||||
Multiple entries of the same type are allowed. In order
|
||||
to handle these duplicate entry types, each entry is
|
||||
@@ -67,25 +68,24 @@ Description:
|
||||
and the two terminating nul characters.
|
||||
type : The type of the entry. This value is the same
|
||||
as found in the directory name. It indicates
|
||||
how the rest of the entry should be
|
||||
interpreted.
|
||||
how the rest of the entry should be interpreted.
|
||||
instance: The instance ordinal of the entry for the
|
||||
given type. This value is the same as found
|
||||
in the parent directory name.
|
||||
position: The position of the entry within the entirety
|
||||
of the entirety.
|
||||
position: The ordinal position (zero-based) of the entry
|
||||
within the entirety of the DMI entry table.
|
||||
|
||||
=== Entry Specialization ===
|
||||
|
||||
Some entry types may have other information available in
|
||||
sysfs.
|
||||
sysfs. Not all types are specialized.
|
||||
|
||||
--- Type 15 - System Event Log ---
|
||||
|
||||
This entry allows the firmware to export a log of
|
||||
events the system has taken. This information is
|
||||
typically backed by nvram, but the implementation
|
||||
details are abstracted by this table. This entries data
|
||||
details are abstracted by this table. This entry's data
|
||||
is exported in the directory:
|
||||
|
||||
/sys/firmware/dmi/entries/15-0/system_event_log
|
||||
|
||||
58
Documentation/ABI/testing/sysfs-firmware-gsmi
Normal file
58
Documentation/ABI/testing/sysfs-firmware-gsmi
Normal file
@@ -0,0 +1,58 @@
|
||||
What: /sys/firmware/gsmi
|
||||
Date: March 2011
|
||||
Contact: Mike Waychison <mikew@google.com>
|
||||
Description:
|
||||
Some servers used internally at Google have firmware
|
||||
that provides callback functionality via explicit SMI
|
||||
triggers. Some of the callbacks are similar to those
|
||||
provided by the EFI runtime services page, but due to
|
||||
historical reasons this different entry-point has been
|
||||
used.
|
||||
|
||||
The gsmi driver implements the kernel's abstraction for
|
||||
these firmware callbacks. Currently, this functionality
|
||||
is limited to handling the system event log and getting
|
||||
access to EFI-style variables stored in nvram.
|
||||
|
||||
Layout:
|
||||
|
||||
/sys/firmware/gsmi/vars:
|
||||
|
||||
This directory has the same layout (and
|
||||
underlying implementation as /sys/firmware/efi/vars.
|
||||
See Documentation/ABI/*/sysfs-firmware-efi-vars
|
||||
for more information on how to interact with
|
||||
this structure.
|
||||
|
||||
/sys/firmware/gsmi/append_to_eventlog - write-only:
|
||||
|
||||
This file takes a binary blob and passes it onto
|
||||
the firmware to be timestamped and appended to
|
||||
the system eventlog. The binary format is
|
||||
interpreted by the firmware and may change from
|
||||
platform to platform. The only kernel-enforced
|
||||
requirement is that the blob be prefixed with a
|
||||
32bit host-endian type used as part of the
|
||||
firmware call.
|
||||
|
||||
/sys/firmware/gsmi/clear_config - write-only:
|
||||
|
||||
Writing any value to this file will cause the
|
||||
entire firmware configuration to be reset to
|
||||
"factory defaults". Callers should assume that
|
||||
a reboot is required for the configuration to be
|
||||
cleared.
|
||||
|
||||
/sys/firmware/gsmi/clear_eventlog - write-only:
|
||||
|
||||
This file is used to clear out a portion/the
|
||||
whole of the system event log. Values written
|
||||
should be values between 1 and 100 inclusive (in
|
||||
ASCII) representing the fraction of the log to
|
||||
clear. Not all platforms support fractional
|
||||
clearing though, and this writes to this file
|
||||
will error out if the firmware doesn't like your
|
||||
submitted fraction.
|
||||
|
||||
Callers should assume that a reboot is needed
|
||||
for this operation to complete.
|
||||
7
Documentation/ABI/testing/sysfs-firmware-log
Normal file
7
Documentation/ABI/testing/sysfs-firmware-log
Normal file
@@ -0,0 +1,7 @@
|
||||
What: /sys/firmware/log
|
||||
Date: February 2011
|
||||
Contact: Mike Waychison <mikew@google.com>
|
||||
Description:
|
||||
The /sys/firmware/log is a binary file that represents a
|
||||
read-only copy of the firmware's log if one is
|
||||
available.
|
||||
8
Documentation/ABI/testing/sysfs-kernel-fscaps
Normal file
8
Documentation/ABI/testing/sysfs-kernel-fscaps
Normal file
@@ -0,0 +1,8 @@
|
||||
What: /sys/kernel/fscaps
|
||||
Date: February 2011
|
||||
KernelVersion: 2.6.38
|
||||
Contact: Ludwig Nussel <ludwig.nussel@suse.de>
|
||||
Description
|
||||
Shows whether file system capabilities are honored
|
||||
when executing a binary
|
||||
|
||||
@@ -96,10 +96,10 @@ X!Iinclude/linux/kobject.h
|
||||
|
||||
<chapter id="devdrivers">
|
||||
<title>Device drivers infrastructure</title>
|
||||
<sect1><title>The Basic Device Driver-Model Structures </title>
|
||||
!Iinclude/linux/device.h
|
||||
</sect1>
|
||||
<sect1><title>Device Drivers Base</title>
|
||||
<!--
|
||||
X!Iinclude/linux/device.h
|
||||
-->
|
||||
!Edrivers/base/driver.c
|
||||
!Edrivers/base/core.c
|
||||
!Edrivers/base/class.c
|
||||
|
||||
@@ -3,24 +3,7 @@ Bus Types
|
||||
|
||||
Definition
|
||||
~~~~~~~~~~
|
||||
|
||||
struct bus_type {
|
||||
char * name;
|
||||
|
||||
struct subsystem subsys;
|
||||
struct kset drivers;
|
||||
struct kset devices;
|
||||
|
||||
struct bus_attribute * bus_attrs;
|
||||
struct device_attribute * dev_attrs;
|
||||
struct driver_attribute * drv_attrs;
|
||||
|
||||
int (*match)(struct device * dev, struct device_driver * drv);
|
||||
int (*hotplug) (struct device *dev, char **envp,
|
||||
int num_envp, char *buffer, int buffer_size);
|
||||
int (*suspend)(struct device * dev, pm_message_t state);
|
||||
int (*resume)(struct device * dev);
|
||||
};
|
||||
See the kerneldoc for the struct bus_type.
|
||||
|
||||
int bus_register(struct bus_type * bus);
|
||||
|
||||
|
||||
@@ -27,22 +27,7 @@ The device class structure looks like:
|
||||
typedef int (*devclass_add)(struct device *);
|
||||
typedef void (*devclass_remove)(struct device *);
|
||||
|
||||
struct device_class {
|
||||
char * name;
|
||||
rwlock_t lock;
|
||||
u32 devnum;
|
||||
struct list_head node;
|
||||
|
||||
struct list_head drivers;
|
||||
struct list_head intf_list;
|
||||
|
||||
struct driver_dir_entry dir;
|
||||
struct driver_dir_entry device_dir;
|
||||
struct driver_dir_entry driver_dir;
|
||||
|
||||
devclass_add add_device;
|
||||
devclass_remove remove_device;
|
||||
};
|
||||
See the kerneldoc for the struct class.
|
||||
|
||||
A typical device class definition would look like:
|
||||
|
||||
|
||||
@@ -2,96 +2,7 @@
|
||||
The Basic Device Structure
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
struct device {
|
||||
struct list_head g_list;
|
||||
struct list_head node;
|
||||
struct list_head bus_list;
|
||||
struct list_head driver_list;
|
||||
struct list_head intf_list;
|
||||
struct list_head children;
|
||||
struct device * parent;
|
||||
|
||||
char name[DEVICE_NAME_SIZE];
|
||||
char bus_id[BUS_ID_SIZE];
|
||||
|
||||
spinlock_t lock;
|
||||
atomic_t refcount;
|
||||
|
||||
struct bus_type * bus;
|
||||
struct driver_dir_entry dir;
|
||||
|
||||
u32 class_num;
|
||||
|
||||
struct device_driver *driver;
|
||||
void *driver_data;
|
||||
void *platform_data;
|
||||
|
||||
u32 current_state;
|
||||
unsigned char *saved_state;
|
||||
|
||||
void (*release)(struct device * dev);
|
||||
};
|
||||
|
||||
Fields
|
||||
~~~~~~
|
||||
g_list: Node in the global device list.
|
||||
|
||||
node: Node in device's parent's children list.
|
||||
|
||||
bus_list: Node in device's bus's devices list.
|
||||
|
||||
driver_list: Node in device's driver's devices list.
|
||||
|
||||
intf_list: List of intf_data. There is one structure allocated for
|
||||
each interface that the device supports.
|
||||
|
||||
children: List of child devices.
|
||||
|
||||
parent: *** FIXME ***
|
||||
|
||||
name: ASCII description of device.
|
||||
Example: " 3Com Corporation 3c905 100BaseTX [Boomerang]"
|
||||
|
||||
bus_id: ASCII representation of device's bus position. This
|
||||
field should be a name unique across all devices on the
|
||||
bus type the device belongs to.
|
||||
|
||||
Example: PCI bus_ids are in the form of
|
||||
<bus number>:<slot number>.<function number>
|
||||
This name is unique across all PCI devices in the system.
|
||||
|
||||
lock: Spinlock for the device.
|
||||
|
||||
refcount: Reference count on the device.
|
||||
|
||||
bus: Pointer to struct bus_type that device belongs to.
|
||||
|
||||
dir: Device's sysfs directory.
|
||||
|
||||
class_num: Class-enumerated value of the device.
|
||||
|
||||
driver: Pointer to struct device_driver that controls the device.
|
||||
|
||||
driver_data: Driver-specific data.
|
||||
|
||||
platform_data: Platform data specific to the device.
|
||||
|
||||
Example: for devices on custom boards, as typical of embedded
|
||||
and SOC based hardware, Linux often uses platform_data to point
|
||||
to board-specific structures describing devices and how they
|
||||
are wired. That can include what ports are available, chip
|
||||
variants, which GPIO pins act in what additional roles, and so
|
||||
on. This shrinks the "Board Support Packages" (BSPs) and
|
||||
minimizes board-specific #ifdefs in drivers.
|
||||
|
||||
current_state: Current power state of the device.
|
||||
|
||||
saved_state: Pointer to saved state of the device. This is usable by
|
||||
the device driver controlling the device.
|
||||
|
||||
release: Callback to free the device after all references have
|
||||
gone away. This should be set by the allocator of the
|
||||
device (i.e. the bus driver that discovered the device).
|
||||
See the kerneldoc for the struct device.
|
||||
|
||||
|
||||
Programming Interface
|
||||
|
||||
@@ -1,23 +1,7 @@
|
||||
|
||||
Device Drivers
|
||||
|
||||
struct device_driver {
|
||||
char * name;
|
||||
struct bus_type * bus;
|
||||
|
||||
struct completion unloaded;
|
||||
struct kobject kobj;
|
||||
list_t devices;
|
||||
|
||||
struct module *owner;
|
||||
|
||||
int (*probe) (struct device * dev);
|
||||
int (*remove) (struct device * dev);
|
||||
|
||||
int (*suspend) (struct device * dev, pm_message_t state);
|
||||
int (*resume) (struct device * dev);
|
||||
};
|
||||
|
||||
See the kerneldoc for the struct device_driver.
|
||||
|
||||
|
||||
Allocation
|
||||
|
||||
@@ -11,14 +11,14 @@ for non English (read: Japanese) speakers and is not intended as a
|
||||
fork. So if you have any comments or updates for this file, please try
|
||||
to update the original English file first.
|
||||
|
||||
Last Updated: 2008/10/24
|
||||
Last Updated: 2011/03/31
|
||||
==================================
|
||||
これは、
|
||||
linux-2.6.28/Documentation/HOWTO
|
||||
linux-2.6.38/Documentation/HOWTO
|
||||
の和訳です。
|
||||
|
||||
翻訳団体： JF プロジェクト < http://www.linux.or.jp/JF/ >
|
||||
翻訳日： 2008/10/24
|
||||
翻訳日： 2011/3/28
|
||||
翻訳者： Tsugikazu Shibata <tshibata at ab dot jp dot nec dot com>
|
||||
校正者： 松倉さん <nbh--mats at nifty dot com>
|
||||
小林 雅典さん (Masanori Kobayasi) <zap03216 at nifty dot ne dot jp>
|
||||
@@ -256,8 +256,8 @@ Linux カーネルの開発プロセスは現在幾つかの異なるメイン
|
||||
- メインの 2.6.x カーネルツリー
|
||||
- 2.6.x.y -stable カーネルツリー
|
||||
- 2.6.x -git カーネルパッチ
|
||||
- 2.6.x -mm カーネルパッチ
|
||||
- サブシステム毎のカーネルツリーとパッチ
|
||||
- 統合テストのための 2.6.x -next カーネルツリー
|
||||
|
||||
2.6.x カーネルツリー
|
||||
-----------------
|
||||
@@ -268,9 +268,9 @@ Linux カーネルの開発プロセスは現在幾つかの異なるメイン
|
||||
|
||||
- 新しいカーネルがリリースされた直後に、2週間の特別期間が設けられ、
|
||||
この期間中に、メンテナ達は Linus に大きな差分を送ることができます。
|
||||
このような差分は通常 -mm カーネルに数週間含まれてきたパッチです。
|
||||
このような差分は通常 -next カーネルに数週間含まれてきたパッチです。
|
||||
大きな変更は git(カーネルのソース管理ツール、詳細は
|
||||
http://git.or.cz/ 参照) を使って送るのが好ましいやり方ですが、パッ
|
||||
http://git-scm.com/ 参照) を使って送るのが好ましいやり方ですが、パッ
|
||||
チファイルの形式のまま送るのでも十分です。
|
||||
|
||||
- 2週間後、-rc1 カーネルがリリースされ、この後にはカーネル全体の安定
|
||||
@@ -333,86 +333,44 @@ git リポジトリで管理されているLinus のカーネルツリーの毎
|
||||
れは -rc カーネルと比べて、パッチが大丈夫かどうかも確認しないで自動的
|
||||
に生成されるので、より実験的です。
|
||||
|
||||
2.6.x -mm カーネルパッチ
|
||||
------------------------
|
||||
|
||||
Andrew Morton によってリリースされる実験的なカーネルパッチ群です。
|
||||
Andrew は個別のサブシステムカーネルツリーとパッチを全て集めてきて
|
||||
linux-kernel メーリングリストで収集された多数のパッチと同時に一つにま
|
||||
とめます。
|
||||
このツリーは新機能とパッチが検証される場となります。ある期間の間パッチ
|
||||
が -mm に入って価値を証明されたら、Andrew やサブシステムメンテナが、
|
||||
メインラインへ入れるように Linus にプッシュします。
|
||||
|
||||
メインカーネルツリーに含めるために Linus に送る前に、すべての新しいパッ
|
||||
チが -mm ツリーでテストされることが強く推奨されています。マージウィン
|
||||
ドウが開く前に -mm ツリーに現れなかったパッチはメインラインにマージさ
|
||||
れることは困難になります。
|
||||
|
||||
これらのカーネルは安定して動作すべきシステムとして使うのには適切ではあ
|
||||
りませんし、カーネルブランチの中でももっとも動作にリスクが高いものです。
|
||||
|
||||
もしあなたが、カーネル開発プロセスの支援をしたいと思っているのであれば、
|
||||
どうぞこれらのカーネルリリースをテストに使ってみて、そしてもし問題があ
|
||||
れば、またもし全てが正しく動作したとしても、linux-kernel メーリングリ
|
||||
ストにフィードバックを提供してください。
|
||||
|
||||
すべての他の実験的パッチに加えて、これらのカーネルは通常リリース時点で
|
||||
メインラインの -git カーネルに含まれる全ての変更も含んでいます。
|
||||
|
||||
-mm カーネルは決まったスケジュールではリリースされません、しかし通常幾
|
||||
つかの -mm カーネル (1 から 3 が普通）が各-rc カーネルの間にリリースさ
|
||||
れます。
|
||||
|
||||
サブシステム毎のカーネルツリーとパッチ
|
||||
-------------------------------------------
|
||||
|
||||
カーネルの様々な領域で何が起きているかを見られるようにするため、多くの
|
||||
カーネルサブシステム開発者は彼らの開発ツリーを公開しています。これらの
|
||||
ツリーは説明したように -mm カーネルリリースに入れ込まれます。
|
||||
それぞれのカーネルサブシステムのメンテナ達は --- そして多くのカーネル
|
||||
サブシステムの開発者達も --- 各自の最新の開発状況をソースリポジトリに
|
||||
公開しています。そのため、自分とは異なる領域のカーネルで何が起きている
|
||||
かを他の人が見られるようになっています。開発が早く進んでいる領域では、
|
||||
開発者は自身の投稿がどのサブシステムカーネルツリーを元にしているか質問
|
||||
されるので、その投稿とすでに進行中の他の作業との衝突が避けられます。
|
||||
|
||||
以下はさまざまなカーネルツリーの中のいくつかのリスト-
|
||||
大部分のこれらのリポジトリは git ツリーです。しかしその他の SCM や
|
||||
quilt シリーズとして公開されているパッチキューも使われています。これら
|
||||
のサブシステムリポジトリのアドレスは MAINTAINERS ファイルにリストされ
|
||||
ています。これらの多くは http://git.kernel.org/ で参照することができま
|
||||
す。
|
||||
|
||||
git ツリー-
|
||||
- Kbuild の開発ツリー、Sam Ravnborg <sam@ravnborg.org>
|
||||
git.kernel.org:/pub/scm/linux/kernel/git/sam/kbuild.git
|
||||
提案されたパッチがこのようなサブシステムツリーにコミットされる前に、メー
|
||||
リングリストで事前にレビューにかけられます（以下の対応するセクションを
|
||||
参照）。いくつかのカーネルサブシステムでは、このレビューは patchwork
|
||||
というツールによって追跡されます。Patchwork は web インターフェイスに
|
||||
よってパッチ投稿の表示、パッチへのコメント付けや改訂などができ、そして
|
||||
メンテナはパッチに対して、レビュー中、受付済み、拒否というようなマーク
|
||||
をつけることができます。大部分のこれらの patchwork のサイトは
|
||||
http://patchwork.kernel.org/ でリストされています。
|
||||
|
||||
- ACPI の開発ツリー、 Len Brown <len.brown@intel.com>
|
||||
git.kernel.org:/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6.git
|
||||
統合テストのための 2.6.x -next カーネルツリー
|
||||
---------------------------------------------
|
||||
|
||||
- Block の開発ツリー、Jens Axboe <axboe@suse.de>
|
||||
git.kernel.org:/pub/scm/linux/kernel/git/axboe/linux-2.6-block.git
|
||||
サブシステムツリーの更新内容がメインラインの 2.6.x ツリーにマージされ
|
||||
る前に、それらは統合テストされる必要があります。この目的のため、実質的
|
||||
に全サブシステムツリーからほぼ毎日プルされてできる特別なテスト用のリ
|
||||
ポジトリが存在します-
|
||||
http://git.kernel.org/?p=linux/kernel/git/sfr/linux-next.git
|
||||
http://linux.f-seidel.de/linux-next/pmwiki/
|
||||
|
||||
- DRM の開発ツリー、Dave Airlie <airlied@linux.ie>
|
||||
git.kernel.org:/pub/scm/linux/kernel/git/airlied/drm-2.6.git
|
||||
|
||||
- ia64 の開発ツリー、Tony Luck <tony.luck@intel.com>
|
||||
git.kernel.org:/pub/scm/linux/kernel/git/aegl/linux-2.6.git
|
||||
|
||||
- infiniband, Roland Dreier <rolandd@cisco.com>
|
||||
git.kernel.org:/pub/scm/linux/kernel/git/roland/infiniband.git
|
||||
|
||||
- libata, Jeff Garzik <jgarzik@pobox.com>
|
||||
git.kernel.org:/pub/scm/linux/kernel/git/jgarzik/libata-dev.git
|
||||
|
||||
- ネットワークドライバ, Jeff Garzik <jgarzik@pobox.com>
|
||||
git.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git
|
||||
|
||||
- pcmcia, Dominik Brodowski <linux@dominikbrodowski.net>
|
||||
git.kernel.org:/pub/scm/linux/kernel/git/brodo/pcmcia-2.6.git
|
||||
|
||||
- SCSI, James Bottomley <James.Bottomley@hansenpartnership.com>
|
||||
git.kernel.org:/pub/scm/linux/kernel/git/jejb/scsi-misc-2.6.git
|
||||
|
||||
- x86, Ingo Molnar <mingo@elte.hu>
|
||||
git://git.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-x86.git
|
||||
|
||||
quilt ツリー-
|
||||
- USB, ドライバコアと I2C, Greg Kroah-Hartman <gregkh@suse.de>
|
||||
kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/
|
||||
|
||||
その他のカーネルツリーは http://git.kernel.org/ と MAINTAINERS ファ
|
||||
イルに一覧表があります。
|
||||
このやり方によって、-next カーネルは次のマージ機会でどんなものがメイン
|
||||
ラインカーネルにマージされるか、おおまかなの展望を提供します。-next
|
||||
カーネルの実行テストを行う冒険好きなテスターは大いに歓迎されます
|
||||
|
||||
バグレポート
|
||||
-------------
|
||||
@@ -673,10 +631,9 @@ Linux カーネルコミュニティは、一度に大量のコードの塊を
|
||||
じところからスタートしたのですから。
|
||||
|
||||
Paolo Ciarrocchi に感謝、彼は彼の書いた "Development Process"
|
||||
(http://linux.tar.bz/articles/2.6-development_process)セクショ
|
||||
ンをこのテキストの原型にすることを許可してくれました。
|
||||
Rundy Dunlap と Gerrit Huizenga はメーリングリストでやるべきこととやっ
|
||||
てはいけないことのリストを提供してくれました。
|
||||
(http://lwn.net/Articles/94386/) セクションをこのテキストの原型にする
|
||||
ことを許可してくれました。Rundy Dunlap と Gerrit Huizenga はメーリング
|
||||
リストでやるべきこととやってはいけないことのリストを提供してくれました。
|
||||
以下の人々のレビュー、コメント、貢献に感謝。
|
||||
Pat Mochel, Hanna Linder, Randy Dunlap, Kay Sievers,
|
||||
Vojtech Pavlik, Jan Kara, Josh Boyer, Kees Cook, Andrew Morton, Andi
|
||||
|
||||
210
Documentation/zh_CN/email-clients.txt
Normal file
210
Documentation/zh_CN/email-clients.txt
Normal file
@@ -0,0 +1,210 @@
|
||||
锘?Chinese translated version of Documentation/email-clients.txt
|
||||
|
||||
If you have any comment or update to the content, please contact the
|
||||
original document maintainer directly. However, if you have a problem
|
||||
communicating in English you can also ask the Chinese maintainer for
|
||||
help. Contact the Chinese maintainer if this translation is outdated
|
||||
or if there is a problem with the translation.
|
||||
|
||||
Chinese maintainer: Harry Wei <harryxiyou@gmail.com>
|
||||
---------------------------------------------------------------------
|
||||
Documentation/email-clients.txt ???涓????缈昏??
|
||||
|
||||
濡??????宠??璁烘????存?版???????????瀹癸??璇风?存?ヨ??绯诲?????妗ｇ??缁存?よ?????濡????浣?浣跨?ㄨ?辨??
|
||||
浜ゆ???????伴?剧??璇?锛?涔????浠ュ??涓???????缁存?よ??姹???┿??濡???????缈昏????存?颁???????舵?????缈?
|
||||
璇?瀛???ㄩ??棰?锛?璇疯??绯讳腑??????缁存?よ?????
|
||||
|
||||
涓???????缁存?よ??锛? 璐惧??濞? Harry Wei <harryxiyou@gmail.com>
|
||||
涓???????缈昏?????锛? 璐惧??濞? Harry Wei <harryxiyou@gmail.com>
|
||||
涓?????????¤?????锛? Yinglin Luan <synmyth@gmail.com>
|
||||
Xiaochen Wang <wangxiaochen0@gmail.com>
|
||||
yaxinsn <yaxinsn@163.com>
|
||||
|
||||
浠ヤ??涓烘?ｆ??
|
||||
---------------------------------------------------------------------
|
||||
|
||||
Linux???浠跺?㈡?风?????缃?淇℃??
|
||||
======================================================================
|
||||
|
||||
?????????缃?
|
||||
----------------------------------------------------------------------
|
||||
Linux?????歌ˉ涓???????杩????浠惰?????浜ょ??锛????濂芥??琛ヤ??浣?涓洪??浠朵????????宓?????????????浜?缁存?よ??
|
||||
??ユ?堕??浠讹??浣???????浠剁?????瀹规?煎??搴?璇ユ??"text/plain"?????惰??锛????浠朵????????涓?璧???????锛?
|
||||
???涓鸿??浼?浣胯ˉ涓????寮???ㄩ?ㄥ????ㄨ??璁鸿??绋?涓???????寰???伴?俱??
|
||||
|
||||
??ㄦ?ュ?????Linux?????歌ˉ涓???????浠跺?㈡?风????ㄥ?????琛ヤ????跺??璇ュ??浜?????????????濮???舵?????渚?濡?锛?
|
||||
浠?浠?涓???芥?瑰?????????????ゅ?惰〃绗???????绌烘?硷???????虫????ㄦ??涓?琛????寮?澶存?????缁?灏俱??
|
||||
|
||||
涓?瑕????杩?"format=flowed"妯″????????琛ヤ?????杩???蜂??寮?璧蜂?????棰????浠ュ?????瀹崇?????琛????
|
||||
|
||||
涓?瑕?璁╀????????浠跺?㈡?风??杩?琛??????ㄦ?㈣?????杩???蜂??浼???村??浣????琛ヤ?????
|
||||
|
||||
???浠跺?㈡?风??涓???芥?瑰???????????瀛?绗????缂??????瑰?????瑕??????????琛ヤ???????芥??ASCII??????UTF-8缂??????瑰??锛?
|
||||
濡????浣?浣跨??UTF-8缂??????瑰???????????浠讹????ｄ??浣?灏?浼???垮??涓?浜??????藉????????瀛?绗???????棰????
|
||||
|
||||
???浠跺?㈡?风??搴?璇ュ舰???骞朵??淇???? References: ?????? In-Reply-To: ???棰?锛???ｄ??
|
||||
???浠惰??棰?灏变??浼?涓???????
|
||||
|
||||
澶???剁??甯?(?????????璐寸??甯?)???甯镐????界?ㄤ??琛ヤ??锛????涓哄?惰〃绗?浼?杞????涓虹┖??笺??浣跨??xclipboard, xclip
|
||||
??????xcutsel涔?璁稿??浠ワ??浣???????濂芥??璇?涓?涓?????????垮??浣跨?ㄥ????剁??甯????
|
||||
|
||||
涓?瑕???ㄤ娇???PGP/GPG缃插????????浠朵腑??????琛ヤ?????杩???蜂??浣垮??寰?澶???????涓???借?诲??????????ㄤ??浣????琛ヤ?????
|
||||
锛?杩?涓????棰?搴?璇ユ?????浠ヤ慨澶????锛?
|
||||
|
||||
??ㄧ???????搁??浠跺??琛ㄥ?????琛ヤ??涔????锛?缁????宸卞?????涓?涓?琛ヤ?????涓?涓???????涓绘??锛?淇?瀛???ユ?跺?扮??
|
||||
???浠讹??灏?琛ヤ?????'patch'??戒护???涓?锛?濡??????????浜?锛????缁??????搁??浠跺??琛ㄥ????????
|
||||
|
||||
|
||||
涓?浜????浠跺?㈡?风?????绀?
|
||||
----------------------------------------------------------------------
|
||||
杩????缁???轰??浜?璇?缁????MUA???缃????绀猴?????浠ョ?ㄤ??缁?Linux?????稿?????琛ヤ?????杩?浜?骞朵???????虫??
|
||||
?????????杞?浠跺?????缃???荤?????
|
||||
|
||||
璇存??锛?
|
||||
TUI = 浠ユ?????涓哄?虹???????ㄦ?锋?ュ??
|
||||
GUI = ??惧舰?????㈢?ㄦ?锋?ュ??
|
||||
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
Alpine (TUI)
|
||||
|
||||
???缃????椤癸??
|
||||
???"Sending Preferences"??ㄥ??锛?
|
||||
|
||||
- "Do Not Send Flowed Text"蹇?椤诲?????
|
||||
- "Strip Whitespace Before Sending"蹇?椤诲?抽??
|
||||
|
||||
褰???????浠舵?讹????????搴?璇ユ?惧?ㄨˉ涓?浼???虹?扮????版?癸????跺?????涓?CTRL-R缁???????锛?浣挎??瀹????
|
||||
琛ヤ?????浠跺????ュ?伴??浠朵腑???
|
||||
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
Evolution (GUI)
|
||||
|
||||
涓?浜?寮????????????????浣跨?ㄥ????????琛ヤ??
|
||||
|
||||
褰??????╅??浠堕??椤癸??Preformat
|
||||
浠?Format->Heading->Preformatted (Ctrl-7)??????宸ュ?锋??
|
||||
|
||||
??跺??浣跨??锛?
|
||||
Insert->Text File... (Alt-n x)?????ヨˉ涓????浠躲??
|
||||
|
||||
浣?杩????浠?"diff -Nru old.c new.c | xclip"锛???????Preformat锛???跺??浣跨?ㄤ腑??撮??杩?琛?绮?甯????
|
||||
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
Kmail (GUI)
|
||||
|
||||
涓?浜?寮????????????????浣跨?ㄥ????????琛ヤ?????
|
||||
|
||||
榛?璁よ?剧疆涓?涓?HTML??煎??????????????锛?涓?瑕??????ㄥ?????
|
||||
|
||||
褰?涔????涓?灏????浠剁????跺??锛???ㄩ??椤逛?????涓?瑕??????╄????ㄦ?㈣????????涓????缂虹?瑰氨???浣???ㄩ??浠朵腑杈???ョ??浠讳????????
|
||||
??戒??浼?琚??????ㄦ?㈣??锛????姝や??蹇?椤诲?ㄥ?????琛ヤ??涔?????????ㄦ?㈣????????绠?????????规??灏辨???????ㄨ????ㄦ?㈣????ヤ功??????浠讹??
|
||||
??跺?????瀹?淇?瀛?涓鸿??绋裤??涓????浣???ㄨ??绋夸腑???娆℃??寮?瀹?锛?瀹?宸茬????ㄩ?ㄨ????ㄦ?㈣??浜?锛???ｄ??浣???????浠惰?界?舵病???
|
||||
?????╄????ㄦ?㈣??锛?浣????杩?涓?浼?澶卞?诲凡???????????ㄦ?㈣?????
|
||||
|
||||
??ㄩ??浠剁??搴????锛??????ヨˉ涓?涔????锛???句??甯哥?ㄧ??琛ヤ??瀹????绗?锛?涓?涓?杩?瀛????(---)???
|
||||
|
||||
??跺?????"Message"????????＄??锛??????╂????ユ??浠讹????ョ????????浣????琛ヤ?????浠躲??杩????涓?涓?棰?澶???????椤癸??浣????浠?
|
||||
???杩?瀹????缃?浣???????浠跺缓绔?宸ュ?锋????????锛?杩????浠ュ甫涓?"insert file"??炬?????
|
||||
|
||||
浣????浠ュ????ㄥ?伴??杩?GPG???璁伴??浠讹??浣???????宓?琛ヤ?????濂戒??瑕?浣跨??GPG???璁板??浠????浣?涓哄??宓??????????绛惧??琛ヤ??锛?
|
||||
褰?浠?GPG涓???????7浣?缂??????朵??浣夸??浠?????????村??澶???????
|
||||
|
||||
濡????浣????瑕?浠ラ??浠剁??褰㈠????????琛ヤ??锛???ｄ??灏卞?抽????瑰?婚??浠讹????跺?????涓?灞???э??绐????"Suggest automatic
|
||||
display"锛?杩???峰??宓????浠舵?村?规??璁╄?昏???????般??
|
||||
|
||||
褰?浣?瑕?淇?瀛?灏?瑕?????????????宓???????琛ヤ??锛?浣????浠ヤ??娑???????琛ㄧ????奸????╁?????琛ヤ????????浠讹????跺????冲?婚?????
|
||||
"save as"???浣????浠ヤ娇??ㄤ??涓?娌℃????存?圭????????琛ヤ????????浠讹??濡????瀹????浠ユ?ｇ‘???褰㈠??缁???????褰?浣?姝ｇ????ㄥ??
|
||||
???宸辩??绐???ｄ??涓?瀵????锛???ｆ?舵病??????椤瑰??浠ヤ??瀛????浠?--宸茬?????涓?涓?杩???风??bug琚?姹???ュ?颁??kmail???bugzilla
|
||||
骞朵??甯????杩?灏?浼?琚?澶??????????浠舵??浠ュ?????瀵规??涓???ㄦ?峰??璇诲???????????琚?淇?瀛????锛????浠ュ?????浣???虫?????浠跺????跺?板?朵????版?癸??
|
||||
浣?涓?寰?涓????浠?浠????????????逛负缁?????????翠?????璇汇??
|
||||
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
Lotus Notes (GUI)
|
||||
|
||||
涓?瑕?浣跨?ㄥ?????
|
||||
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
Mutt (TUI)
|
||||
|
||||
寰?澶?Linux寮????浜哄??浣跨??mutt瀹㈡?风??锛????浠ヨ?????瀹????瀹?宸ヤ????????甯告??浜????
|
||||
|
||||
Mutt涓????甯?缂?杈????锛????浠ヤ??绠′??浣跨?ㄤ??涔?缂?杈???ㄩ?戒??搴?璇ュ甫????????ㄦ??琛????澶у????扮??杈???ㄩ?藉甫???
|
||||
涓?涓?"insert file"???椤癸??瀹????浠ラ??杩?涓???瑰?????浠跺??瀹圭????瑰???????ユ??浠躲??
|
||||
|
||||
'vim'浣?涓?mutt???缂?杈????锛?
|
||||
set editor="vi"
|
||||
|
||||
濡????浣跨??xclip锛???插?ヤ互涓???戒护
|
||||
:set paste
|
||||
???涓????涔??????????shift-insert??????浣跨??
|
||||
:r filename
|
||||
|
||||
濡??????宠?????琛ヤ??浣?涓哄??宓??????????
|
||||
(a)ttach宸ヤ?????寰?濂斤??涓?甯????"set paste"???
|
||||
|
||||
???缃????椤癸??
|
||||
瀹?搴?璇ヤ互榛?璁よ?剧疆???褰㈠??宸ヤ?????
|
||||
??惰??锛????"send_charset"璁剧疆涓?"us-ascii::utf-8"涔????涓?涓?涓???????涓绘?????
|
||||
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
Pine (TUI)
|
||||
|
||||
Pine杩???绘??涓?浜?绌烘?煎????????棰?锛?浣????杩?浜???板?ㄥ??璇ラ?借??淇?澶?浜????
|
||||
|
||||
濡???????浠ワ??璇蜂娇???alpine(pine???缁ф?胯??)
|
||||
|
||||
???缃????椤癸??
|
||||
- ???杩?????????????瑕?娑???ゆ??绋???????
|
||||
- "no-strip-whitespace-before-send"???椤逛????????瑕???????
|
||||
|
||||
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
Sylpheed (GUI)
|
||||
|
||||
- ???宓??????????浠ュ??濂界??宸ヤ??锛???????浣跨?ㄩ??浠讹?????
|
||||
- ???璁镐娇??ㄥ????ㄧ??缂?杈???ㄣ??
|
||||
- 瀵逛?????褰?杈?澶???堕??甯告?????
|
||||
- 濡???????杩?non-SSL杩???ワ?????娉?浣跨??TLS SMTP?????????
|
||||
- ??ㄧ?????绐???ｄ腑???涓?涓?寰??????ㄧ??ruler bar???
|
||||
- 缁???板?????涓?娣诲????板??灏变??浼?姝ｇ‘???浜?瑙ｆ?剧ず??????
|
||||
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
Thunderbird (GUI)
|
||||
|
||||
榛?璁ゆ????典??锛?thunderbird寰?瀹规??????????????锛?浣????杩????涓?浜???规?????浠ュ己??跺?????寰???村ソ???
|
||||
|
||||
- ??ㄧ?ㄦ?峰????疯?剧疆???锛?缁???????瀵诲??锛?涓?瑕???????"Compose messages in HTML format"???
|
||||
|
||||
- 缂?杈?浣????Thunderbird???缃?璁剧疆??ヤ娇瀹?涓?瑕????琛?浣跨??锛?user_pref("mailnews.wraplength", 0);
|
||||
|
||||
- 缂?杈?浣????Thunderbird???缃?璁剧疆锛?浣垮??涓?瑕?浣跨??"format=flowed"??煎??锛?user_pref("mailnews.
|
||||
send_plaintext_flowed", false);
|
||||
|
||||
- 浣????瑕?浣?Thunderbird???涓洪???????煎????瑰??锛?
|
||||
濡????榛?璁ゆ????典??浣?涔??????????HTML??煎??锛???ｄ?????寰???俱??浠?浠?浠????棰???????涓????妗?涓???????"Preformat"??煎?????
|
||||
濡????榛?璁ゆ????典??浣?涔??????????????????煎??锛?浣?涓?寰????瀹???逛负HTML??煎??锛?浠?浠?浣?涓轰??娆℃?х??锛???ヤ功?????扮??娑????锛?
|
||||
??跺??寮哄?朵娇瀹??????版???????煎??锛???????瀹?灏变?????琛????瑕?瀹???板??锛???ㄥ??淇＄????炬??涓?浣跨??shift?????ヤ娇瀹????涓?HTML
|
||||
??煎??锛???跺?????棰???????涓????妗?涓???????"Preformat"??煎?????
|
||||
|
||||
- ???璁镐娇??ㄥ????ㄧ??缂?杈????锛?
|
||||
???瀵?Thunderbird???琛ヤ?????绠?????????规??灏辨??浣跨?ㄤ??涓?"external editor"??╁??锛???跺??浣跨?ㄤ????????娆㈢??
|
||||
$EDITOR??ヨ?诲???????????骞惰ˉ涓???版?????涓????瑕?瀹???板??锛????浠ヤ??杞藉苟涓?瀹?瑁?杩?涓???╁??锛???跺??娣诲??涓?涓?浣跨?ㄥ?????
|
||||
??????View->Toolbars->Customize...??????褰?浣?涔????淇℃???????跺??浠?浠???瑰?诲??灏卞??浠ヤ?????
|
||||
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
TkRat (GUI)
|
||||
|
||||
???浠ヤ娇??ㄥ?????浣跨??"Insert file..."??????澶???ㄧ??缂?杈???ㄣ??
|
||||
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
Gmail (Web GUI)
|
||||
|
||||
涓?瑕?浣跨?ㄥ????????琛ヤ?????
|
||||
|
||||
Gmail缃?椤靛?㈡?风???????ㄥ?版????惰〃绗?杞????涓虹┖??笺??
|
||||
|
||||
??界?跺?惰〃绗?杞????涓虹┖??奸??棰????浠ヨ??澶???ㄧ??杈???ㄨВ??筹???????跺??杩?浼?浣跨?ㄥ??杞???㈣?????姣?琛???????涓?78涓?瀛?绗????
|
||||
|
||||
???涓?涓????棰????Gmail杩?浼????浠讳??涓????ASCII???瀛?绗????淇℃????逛负base64缂???????瀹????涓?瑗垮????????娆ф床浜虹?????瀛????
|
||||
|
||||
###
|
||||
@@ -234,7 +234,6 @@ static int __die(const char *str, int err, struct thread_info *thread, struct pt
|
||||
|
||||
printk(KERN_EMERG "Internal error: %s: %x [#%d]" S_PREEMPT S_SMP "\n",
|
||||
str, err, ++die_counter);
|
||||
sysfs_printk_last_file();
|
||||
|
||||
/* trap and error numbers are mostly meaningless on ARM */
|
||||
ret = notify_die(DIE_OOPS, str, regs, err, tsk->thread.trap_no, SIGSEGV);
|
||||
|
||||
@@ -143,7 +143,6 @@ int die(const char *str, struct pt_regs *regs, long err)
|
||||
#endif
|
||||
printk("%s\n", ppc_md.name ? ppc_md.name : "");
|
||||
|
||||
sysfs_printk_last_file();
|
||||
if (notify_die(DIE_OOPS, str, regs, err, 255,
|
||||
SIGSEGV) == NOTIFY_STOP)
|
||||
return 1;
|
||||
|
||||
@@ -87,7 +87,6 @@ void die(const char * str, struct pt_regs * regs, long err)
|
||||
bust_spinlocks(1);
|
||||
|
||||
printk("%s: %04lx [#%d]\n", str, err & 0xffff, ++die_counter);
|
||||
sysfs_printk_last_file();
|
||||
print_modules();
|
||||
show_regs(regs);
|
||||
|
||||
|
||||
@@ -192,7 +192,6 @@ static int __die(const char *str, int err, struct thread_info *thread,
|
||||
|
||||
printk(KERN_EMERG "Internal error: %s: %x [#%d]\n",
|
||||
str, err, ++die_counter);
|
||||
sysfs_printk_last_file();
|
||||
|
||||
/* trap and error numbers are mostly meaningless on UniCore */
|
||||
ret = notify_die(DIE_OOPS, str, regs, err, tsk->thread.trap_no, \
|
||||
|
||||
@@ -4,16 +4,40 @@
|
||||
#include <asm/io.h>
|
||||
|
||||
/*
|
||||
* there is a real-mode segmented pointer pointing to the
|
||||
* 4K EBDA area at 0x40E.
|
||||
* Returns physical address of EBDA. Returns 0 if there is no EBDA.
|
||||
*/
|
||||
static inline unsigned int get_bios_ebda(void)
|
||||
{
|
||||
/*
|
||||
* There is a real-mode segmented pointer pointing to the
|
||||
* 4K EBDA area at 0x40E.
|
||||
*/
|
||||
unsigned int address = *(unsigned short *)phys_to_virt(0x40E);
|
||||
address <<= 4;
|
||||
return address; /* 0 means none */
|
||||
}
|
||||
|
||||
/*
|
||||
* Return the sanitized length of the EBDA in bytes, if it exists.
|
||||
*/
|
||||
static inline unsigned int get_bios_ebda_length(void)
|
||||
{
|
||||
unsigned int address;
|
||||
unsigned int length;
|
||||
|
||||
address = get_bios_ebda();
|
||||
if (!address)
|
||||
return 0;
|
||||
|
||||
/* EBDA length is byte 0 of the EBDA (stored in KiB) */
|
||||
length = *(unsigned char *)phys_to_virt(address);
|
||||
length <<= 10;
|
||||
|
||||
/* Trim the length if it extends beyond 640KiB */
|
||||
length = min_t(unsigned int, (640 * 1024) - address, length);
|
||||
return length;
|
||||
}
|
||||
|
||||
void reserve_ebda_region(void);
|
||||
|
||||
#ifdef CONFIG_X86_CHECK_BIOS_CORRUPTION
|
||||
|
||||
@@ -263,7 +263,6 @@ int __kprobes __die(const char *str, struct pt_regs *regs, long err)
|
||||
printk("DEBUG_PAGEALLOC");
|
||||
#endif
|
||||
printk("\n");
|
||||
sysfs_printk_last_file();
|
||||
if (notify_die(DIE_OOPS, str, regs, err,
|
||||
current->thread.trap_no, SIGSEGV) == NOTIFY_STOP)
|
||||
return 1;
|
||||
|
||||
@@ -400,7 +400,7 @@ static void device_remove_groups(struct device *dev,
|
||||
static int device_add_attrs(struct device *dev)
|
||||
{
|
||||
struct class *class = dev->class;
|
||||
struct device_type *type = dev->type;
|
||||
const struct device_type *type = dev->type;
|
||||
int error;
|
||||
|
||||
if (class) {
|
||||
@@ -440,7 +440,7 @@ static int device_add_attrs(struct device *dev)
|
||||
static void device_remove_attrs(struct device *dev)
|
||||
{
|
||||
struct class *class = dev->class;
|
||||
struct device_type *type = dev->type;
|
||||
const struct device_type *type = dev->type;
|
||||
|
||||
device_remove_groups(dev, dev->groups);
|
||||
|
||||
@@ -1314,8 +1314,7 @@ EXPORT_SYMBOL_GPL(put_device);
|
||||
EXPORT_SYMBOL_GPL(device_create_file);
|
||||
EXPORT_SYMBOL_GPL(device_remove_file);
|
||||
|
||||
struct root_device
|
||||
{
|
||||
struct root_device {
|
||||
struct device dev;
|
||||
struct module *owner;
|
||||
};
|
||||
|
||||
@@ -245,6 +245,10 @@ int device_attach(struct device *dev)
|
||||
|
||||
device_lock(dev);
|
||||
if (dev->driver) {
|
||||
if (klist_node_attached(&dev->p->knode_driver)) {
|
||||
ret = 1;
|
||||
goto out_unlock;
|
||||
}
|
||||
ret = device_bind_driver(dev);
|
||||
if (ret == 0)
|
||||
ret = 1;
|
||||
@@ -257,6 +261,7 @@ int device_attach(struct device *dev)
|
||||
ret = bus_for_each_drv(dev->bus, NULL, dev, __device_attach);
|
||||
pm_runtime_put_sync(dev);
|
||||
}
|
||||
out_unlock:
|
||||
device_unlock(dev);
|
||||
return ret;
|
||||
}
|
||||
@@ -408,17 +413,16 @@ void *dev_get_drvdata(const struct device *dev)
|
||||
}
|
||||
EXPORT_SYMBOL(dev_get_drvdata);
|
||||
|
||||
void dev_set_drvdata(struct device *dev, void *data)
|
||||
int dev_set_drvdata(struct device *dev, void *data)
|
||||
{
|
||||
int error;
|
||||
|
||||
if (!dev)
|
||||
return;
|
||||
if (!dev->p) {
|
||||
error = device_private_init(dev);
|
||||
if (error)
|
||||
return;
|
||||
return error;
|
||||
}
|
||||
dev->p->driver_data = data;
|
||||
return 0;
|
||||
}
|
||||
EXPORT_SYMBOL(dev_set_drvdata);
|
||||
|
||||
@@ -48,7 +48,8 @@ static const char *memory_uevent_name(struct kset *kset, struct kobject *kobj)
|
||||
return MEMORY_CLASS_NAME;
|
||||
}
|
||||
|
||||
static int memory_uevent(struct kset *kset, struct kobject *obj, struct kobj_uevent_env *env)
|
||||
static int memory_uevent(struct kset *kset, struct kobject *obj,
|
||||
struct kobj_uevent_env *env)
|
||||
{
|
||||
int retval = 0;
|
||||
|
||||
@@ -228,10 +229,11 @@ int memory_isolate_notify(unsigned long val, void *v)
|
||||
* OK to have direct references to sparsemem variables in here.
|
||||
*/
|
||||
static int
|
||||
memory_section_action(unsigned long phys_index, unsigned long action)
|
||||
memory_block_action(unsigned long phys_index, unsigned long action)
|
||||
{
|
||||
int i;
|
||||
unsigned long start_pfn, start_paddr;
|
||||
unsigned long nr_pages = PAGES_PER_SECTION * sections_per_block;
|
||||
struct page *first_page;
|
||||
int ret;
|
||||
|
||||
@@ -243,7 +245,7 @@ memory_section_action(unsigned long phys_index, unsigned long action)
|
||||
* that way.
|
||||
*/
|
||||
if (action == MEM_ONLINE) {
|
||||
for (i = 0; i < PAGES_PER_SECTION; i++) {
|
||||
for (i = 0; i < nr_pages; i++) {
|
||||
if (PageReserved(first_page+i))
|
||||
continue;
|
||||
|
||||
@@ -257,12 +259,12 @@ memory_section_action(unsigned long phys_index, unsigned long action)
|
||||
switch (action) {
|
||||
case MEM_ONLINE:
|
||||
start_pfn = page_to_pfn(first_page);
|
||||
ret = online_pages(start_pfn, PAGES_PER_SECTION);
|
||||
ret = online_pages(start_pfn, nr_pages);
|
||||
break;
|
||||
case MEM_OFFLINE:
|
||||
start_paddr = page_to_pfn(first_page) << PAGE_SHIFT;
|
||||
ret = remove_memory(start_paddr,
|
||||
PAGES_PER_SECTION << PAGE_SHIFT);
|
||||
nr_pages << PAGE_SHIFT);
|
||||
break;
|
||||
default:
|
||||
WARN(1, KERN_WARNING "%s(%ld, %ld) unknown action: "
|
||||
@@ -276,7 +278,7 @@ memory_section_action(unsigned long phys_index, unsigned long action)
|
||||
static int memory_block_change_state(struct memory_block *mem,
|
||||
unsigned long to_state, unsigned long from_state_req)
|
||||
{
|
||||
int i, ret = 0;
|
||||
int ret = 0;
|
||||
|
||||
mutex_lock(&mem->state_mutex);
|
||||
|
||||
@@ -288,20 +290,11 @@ static int memory_block_change_state(struct memory_block *mem,
|
||||
if (to_state == MEM_OFFLINE)
|
||||
mem->state = MEM_GOING_OFFLINE;
|
||||
|
||||
for (i = 0; i < sections_per_block; i++) {
|
||||
ret = memory_section_action(mem->start_section_nr + i,
|
||||
to_state);
|
||||
if (ret)
|
||||
break;
|
||||
}
|
||||
|
||||
if (ret) {
|
||||
for (i = 0; i < sections_per_block; i++)
|
||||
memory_section_action(mem->start_section_nr + i,
|
||||
from_state_req);
|
||||
ret = memory_block_action(mem->start_section_nr, to_state);
|
||||
|
||||
if (ret)
|
||||
mem->state = from_state_req;
|
||||
} else
|
||||
else
|
||||
mem->state = to_state;
|
||||
|
||||
out:
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user