Commit 39ab05c8 authored by Linus Torvalds's avatar Linus Torvalds
Browse files

Merge branch 'driver-core-next' of...

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.
parents 1477fcc2 c42d2237
......@@ -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
......
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.
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.
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
......
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 ツリー-
- Kbuild の開発ツリー、Sam Ravnborg <sam@ravnborg.org>
git.kernel.org:/pub/scm/linux/kernel/git/sam/kbuild.git
- ACPI の開発ツリー、 Len Brown <len.brown@intel.com>
git.kernel.org:/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6.git
- Block の開発ツリー、Jens Axboe <axboe@suse.de>
git.kernel.org:/pub/scm/linux/kernel/git/axboe/linux-2.6-block.git
- 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/
それぞれのカーネルサブシステムのメンテナ達は --- そして多くのカーネル
サブシステムの開発者達も --- 各自の最新の開発状況をソースリポジトリに
公開しています。そのため、自分とは異なる領域のカーネルで何が起きている
かを他の人が見られるようになっています。開発が早く進んでいる領域では、
開発者は自身の投稿がどのサブシステムカーネルツリーを元にしているか質問
されるので、その投稿とすでに進行中の他の作業との衝突が避けられます。
大部分のこれらのリポジトリは git ツリーです。しかしその他の SCM や
quilt シリーズとして公開されているパッチキューも使われています。これら
のサブシステムリポジトリのアドレスは MAINTAINERS ファイルにリストされ
ています。これらの多くは http://git.kernel.org/ で参照することができま
す。
その他のカーネルツリーは http://git.kernel.org/ と MAINTAINERS ファ
イルに一覧表があります。
提案されたパッチがこのようなサブシステムツリーにコミットされる前に、メー
リングリストで事前にレビューにかけられます(以下の対応するセクションを
参照)。いくつかのカーネルサブシステムでは、このレビューは patchwork
というツールによって追跡されます。Patchwork は web インターフェイスに
よってパッチ投稿の表示、パッチへのコメント付けや改訂などができ、そして
メンテナはパッチに対して、レビュー中、受付済み、拒否というようなマーク
をつけることができます。大部分のこれらの patchwork のサイトは
http://patchwork.kernel.org/ でリストされています。
統合テストのための 2.6.x -next カーネルツリー
---------------------------------------------
サブシステムツリーの更新内容がメインラインの 2.6.x ツリーにマージされ
る前に、それらは統合テストされる必要があります。この目的のため、実質的
に全サブシステムツリーからほぼ毎日プルされてできる特別なテスト用のリ
ポジトリが存在します-
http://git.kernel.org/?p=linux/kernel/git/sfr/linux-next.git
http://linux.f-seidel.de/linux-next/pmwiki/
このやり方によって、-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
......
锘?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 ???涓????缈昏??
濡??????宠??璁烘????存?版???????????瀹癸??璇风?存?ヨ??绯诲?????妗g??缁存?よ?????濡????浣?浣跨?ㄨ?辨??
浜ゆ???????伴?剧??璇?锛?涔????浠ュ??涓???????缁存?よ??姹???┿??濡???????缈昏????存?颁???????舵?????缈?
璇?瀛???ㄩ??棰?锛?璇疯??绯讳腑??????缁存?よ?????
涓???????缁存?よ??锛? 璐惧??濞? Harry Wei <harryxiyou@gmail.com>
涓???????缈昏?????锛? 璐惧??濞? Harry Wei <harryxiyou@gmail.com>
涓?????????¤?????锛? Yinglin Luan <synmyth@gmail.com>
Xiaochen Wang <wangxiaochen0@gmail.com>
yaxinsn <yaxinsn@163.com>
浠ヤ??涓烘?f??
---------------------------------------------------------------------
Linux???浠跺?㈡?风?????缃?淇℃??
======================================================================
?????????缃?
----------------------------------------------------------------------
Linux?????歌ˉ涓???????杩????浠惰?????浜ょ??锛????濂芥??琛ヤ??浣?涓洪??浠朵????????宓?????????????浜?缁存?よ??
??ユ?堕??浠讹??浣???????浠剁?????瀹规?煎??搴?璇ユ??"text/plain"?????惰??锛????浠朵????????涓?璧???????锛?
???涓鸿??浼?浣胯ˉ涓????寮???ㄩ?ㄥ????ㄨ??璁鸿??绋?涓???????寰???伴?俱??
??ㄦ?ュ?????Linux?????歌ˉ涓???????浠跺?㈡?风????ㄥ?????琛ヤ????跺??璇ュ??浜?????????????濮???舵?????渚?濡?锛?
浠?浠?涓???芥?瑰?????????????ゅ?惰〃绗???????绌烘?硷???????虫????ㄦ??涓?琛????寮?澶存?????缁?灏俱??
涓?瑕????杩?"format=flowed"妯″????????琛ヤ?????杩???蜂??寮?璧蜂?????棰????浠ュ?????瀹崇?????琛????
涓?瑕?璁╀????????浠跺?㈡?风??杩?琛??????ㄦ?㈣?????杩???蜂??浼???村??浣????琛ヤ?????
???浠跺?㈡?风??涓???芥?瑰???????????瀛?绗????缂??????瑰?????瑕??????????琛ヤ???????芥??ASCII??????UTF-8缂??????瑰??锛?
濡????浣?浣跨??UTF-8缂??????瑰???????????浠讹????d??浣?灏?浼???垮??涓?浜??????藉????????瀛?绗???????棰????
???浠跺?㈡?风??搴?璇ュ舰???骞朵??淇???? References: ?????? In-Reply-To: ???棰?锛???d??
???浠惰??棰?灏变??浼?涓???????
澶???剁??甯?(?????????璐寸??甯?)???甯镐????界?ㄤ??琛ヤ??锛????涓哄?惰〃绗?浼?杞????涓虹┖??笺??浣跨??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??煎??????????????锛?涓?瑕??????ㄥ?????
褰?涔????涓?灏????浠剁????跺??锛???ㄩ??椤逛?????涓?瑕??????╄????ㄦ?㈣????????涓????缂虹?瑰氨???浣???ㄩ??浠朵腑杈???ョ??浠讳????????
??戒??浼?琚??????ㄦ?㈣??锛????姝や??蹇?椤诲?ㄥ?????琛ヤ??涔?????????ㄦ?㈣????????绠?????????规??灏辨???????ㄨ????ㄦ?㈣????ヤ功??????浠讹??
??跺?????瀹?淇?瀛?涓鸿??绋裤??涓????浣???ㄨ??绋夸腑???娆℃??寮?瀹?锛?瀹?宸茬????ㄩ?ㄨ????ㄦ?㈣??浜?锛???d??浣???????浠惰?界?舵病???
?????╄????ㄦ?㈣??锛?浣????杩?涓?浼?澶卞?诲凡???????????ㄦ?㈣?????
??ㄩ??浠剁??搴????锛??????ヨˉ涓?涔????锛???句??甯哥?ㄧ??琛ヤ??瀹????绗?锛?涓?涓?杩?瀛????(---)???
??跺?????"Message"????????$??锛??????╂????ユ??浠讹????ョ????????浣????琛ヤ?????浠躲??杩????涓?涓?棰?澶???????椤癸??浣????浠?
???杩?瀹????缃?浣???????浠跺缓绔?宸ュ?锋????????锛?杩????浠ュ甫涓?"insert file"??炬?????
浣????浠ュ????ㄥ?伴??杩?GPG???璁伴??浠讹??浣???????宓?琛ヤ?????濂戒??瑕?浣跨??GPG???璁板??浠????浣?涓哄??宓??????????绛惧??琛ヤ??锛?
褰?浠?GPG涓???????7浣?缂??????朵??浣夸??浠?????????村??澶???????
濡????浣????瑕?浠ラ??浠剁??褰㈠????????琛ヤ??锛???d??灏卞?抽????瑰?婚??浠讹????跺?????涓?灞???э??绐????"Suggest automatic
display"锛?杩???峰??宓????浠舵?村?规??璁╄?昏???????般??
褰?浣?瑕?淇?瀛?灏?瑕?????????????宓???????琛ヤ??锛?浣????浠ヤ??娑???????琛ㄧ????奸????╁?????琛ヤ????????浠讹????跺????冲?婚?????
"save as"???浣????浠ヤ娇??ㄤ??涓?娌℃????存?圭????????琛ヤ????????浠讹??濡????瀹????浠ユ?g‘???褰㈠??缁???????褰?浣?姝g????ㄥ??
???宸辩??绐???d??涓?瀵????锛???f?舵病??????椤瑰??浠ヤ??瀛????浠?--宸茬?????涓?涓?杩???风??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"???
???缃????椤癸??
瀹?搴?璇ヤ互榛?璁よ?剧疆???褰㈠??宸ヤ?????