Commit af947311 authored by Linus Torvalds's avatar Linus Torvalds

Merge master.kernel.org:/pub/scm/linux/kernel/git/gregkh/driver-2.6

* master.kernel.org:/pub/scm/linux/kernel/git/gregkh/driver-2.6:
  modules: better error messages when modules fail to load due to a sysfs problem.
  kobject: update documentation
  kset: kernel-doc cleanups
  driver core: revert "device" link creation check
  stable_api_nonsense.txt: Disambiguate the use of "this" by using "that" to refer to the syscall interface
  Fix Doc/sysfs-rules typos
  kernel-doc fixes for PCI and drivers/base/
  kobject: put kobject_actions in kobject.h
  kobject: fix link error when CONFIG_HOTPLUG is disabled
  HOWTO: sync Japanese HOWTO
  HOWTO: adjust translation header of Japanese stable_api_nonsense.txt
parents 9f8e35fc 74c5b597
NOTE: NOTE:
This is Japanese translated version of "Documentation/HOWTO". This is a version of Documentation/HOWTO translated into Japanese.
This one is maintained by Tsugikazu Shibata <tshibata@ab.jp.nec.com> This document is maintained by Tsugikazu Shibata <tshibata@ab.jp.nec.com>
and JF Project team <www.linux.or.jp/JF>. and the JF Project team <www.linux.or.jp/JF>.
If you find difference with original file or problem in translation, If you find any difference between this document and the original file
please contact maintainer of this file or JF project. or a problem with the translation,
please contact the maintainer of this file or JF project.
Please also note that purpose of this file is easier to read for non
English natives and not to be intended to fork. So, if you have any Please also note that the purpose of this file is to be easier to read
comments or updates of this file, please try to update Original(English) for non English (read: Japanese) speakers and is not intended as a
file at first. fork. So if you have any comments or updates for this file, please try
to update the original English file first.
Last Updated: 2007/06/04
Last Updated: 2007/07/18
================================== ==================================
これは、 これは、
linux-2.6.21/Documentation/HOWTO linux-2.6.22/Documentation/HOWTO
の和訳です。 の和訳です。
翻訳団体: JF プロジェクト < http://www.linux.or.jp/JF/ > 翻訳団体: JF プロジェクト < http://www.linux.or.jp/JF/ >
翻訳日: 2007/06/04 翻訳日: 2007/07/16
翻訳者: Tsugikazu Shibata <tshibata at ab dot jp dot nec dot com> 翻訳者: Tsugikazu Shibata <tshibata at ab dot jp dot nec dot com>
校正者: 松倉さん <nbh--mats at nifty dot com> 校正者: 松倉さん <nbh--mats at nifty dot com>
小林 雅典さん (Masanori Kobayasi) <zap03216 at nifty dot ne dot jp> 小林 雅典さん (Masanori Kobayasi) <zap03216 at nifty dot ne dot jp>
...@@ -52,6 +53,7 @@ Linux カーネル開発コミュニティと共に活動するやり方を学 ...@@ -52,6 +53,7 @@ Linux カーネル開発コミュニティと共に活動するやり方を学
また、このコミュニティがなぜ今うまくまわっているのかという理由の一部も また、このコミュニティがなぜ今うまくまわっているのかという理由の一部も
説明しようと試みています。 説明しようと試みています。
カーネルは 少量のアーキテクチャ依存部分がアセンブリ言語で書かれている カーネルは 少量のアーキテクチャ依存部分がアセンブリ言語で書かれている
以外は大部分は C 言語で書かれています。C言語をよく理解していることはカー 以外は大部分は C 言語で書かれています。C言語をよく理解していることはカー
ネル開発者には必要です。アーキテクチャ向けの低レベル部分の開発をするの ネル開発者には必要です。アーキテクチャ向けの低レベル部分の開発をするの
...@@ -141,6 +143,7 @@ Linux カーネルソースツリーは幅広い範囲のドキュメントを ...@@ -141,6 +143,7 @@ Linux カーネルソースツリーは幅広い範囲のドキュメントを
これらのルールに従えばうまくいくことを保証することではありません これらのルールに従えばうまくいくことを保証することではありません
が (すべてのパッチは内容とスタイルについて精査を受けるので)、 が (すべてのパッチは内容とスタイルについて精査を受けるので)、
ルールに従わなければ間違いなくうまくいかないでしょう。 ルールに従わなければ間違いなくうまくいかないでしょう。
この他にパッチを作る方法についてのよくできた記述は- この他にパッチを作る方法についてのよくできた記述は-
"The Perfect Patch" "The Perfect Patch"
...@@ -360,44 +363,42 @@ linux-kernel メーリングリストで収集された多数のパッチと同 ...@@ -360,44 +363,42 @@ linux-kernel メーリングリストで収集された多数のパッチと同
git ツリー- git ツリー-
- Kbuild の開発ツリー、Sam Ravnborg <sam@ravnborg.org> - Kbuild の開発ツリー、Sam Ravnborg <sam@ravnborg.org>
kernel.org:/pub/scm/linux/kernel/git/sam/kbuild.git git.kernel.org:/pub/scm/linux/kernel/git/sam/kbuild.git
- ACPI の開発ツリー、 Len Brown <len.brown@intel.com> - ACPI の開発ツリー、 Len Brown <len.brown@intel.com>
kernel.org:/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6.git git.kernel.org:/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6.git
- Block の開発ツリー、Jens Axboe <axboe@suse.de> - Block の開発ツリー、Jens Axboe <axboe@suse.de>
kernel.org:/pub/scm/linux/kernel/git/axboe/linux-2.6-block.git git.kernel.org:/pub/scm/linux/kernel/git/axboe/linux-2.6-block.git
- DRM の開発ツリー、Dave Airlie <airlied@linux.ie> - DRM の開発ツリー、Dave Airlie <airlied@linux.ie>
kernel.org:/pub/scm/linux/kernel/git/airlied/drm-2.6.git git.kernel.org:/pub/scm/linux/kernel/git/airlied/drm-2.6.git
- ia64 の開発ツリー、Tony Luck <tony.luck@intel.com> - ia64 の開発ツリー、Tony Luck <tony.luck@intel.com>
kernel.org:/pub/scm/linux/kernel/git/aegl/linux-2.6.git git.kernel.org:/pub/scm/linux/kernel/git/aegl/linux-2.6.git
- ieee1394 の開発ツリー、Jody McIntyre <scjody@modernduck.com>
kernel.org:/pub/scm/linux/kernel/git/scjody/ieee1394.git
- infiniband, Roland Dreier <rolandd@cisco.com> - infiniband, Roland Dreier <rolandd@cisco.com>
kernel.org:/pub/scm/linux/kernel/git/roland/infiniband.git git.kernel.org:/pub/scm/linux/kernel/git/roland/infiniband.git
- libata, Jeff Garzik <jgarzik@pobox.com> - libata, Jeff Garzik <jgarzik@pobox.com>
kernel.org:/pub/scm/linux/kernel/git/jgarzik/libata-dev.git git.kernel.org:/pub/scm/linux/kernel/git/jgarzik/libata-dev.git
- ネットワークドライバ, Jeff Garzik <jgarzik@pobox.com> - ネットワークドライバ, Jeff Garzik <jgarzik@pobox.com>
kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git git.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git
- pcmcia, Dominik Brodowski <linux@dominikbrodowski.net> - pcmcia, Dominik Brodowski <linux@dominikbrodowski.net>
kernel.org:/pub/scm/linux/kernel/git/brodo/pcmcia-2.6.git git.kernel.org:/pub/scm/linux/kernel/git/brodo/pcmcia-2.6.git
- SCSI, James Bottomley <James.Bottomley@SteelEye.com> - SCSI, James Bottomley <James.Bottomley@SteelEye.com>
kernel.org:/pub/scm/linux/kernel/git/jejb/scsi-misc-2.6.git git.kernel.org:/pub/scm/linux/kernel/git/jejb/scsi-misc-2.6.git
その他の git カーネルツリーは http://kernel.org/git に一覧表がありま
す。
quilt ツリー- quilt ツリー-
- USB, PCI ドライバコアと I2C, Greg Kroah-Hartman <gregkh@suse.de> - USB, PCI ドライバコアと I2C, Greg Kroah-Hartman <gregkh@suse.de>
kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/ kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/
- x86-64 と i386 の仲間 Andi Kleen <ak@suse.de>
その他のカーネルツリーは http://git.kernel.org/ と MAINTAINERS ファ
イルに一覧表があります。
バグレポート バグレポート
------------- -------------
...@@ -508,6 +509,7 @@ MAINTAINERS ファイルにリストがありますので参照してくださ ...@@ -508,6 +509,7 @@ MAINTAINERS ファイルにリストがありますので参照してくださ
せん*。単に自分のパッチに対して指摘された問題を全て修正して再送すれば せん*。単に自分のパッチに対して指摘された問題を全て修正して再送すれば
いいのです。 いいのです。
カーネルコミュニティと企業組織のちがい カーネルコミュニティと企業組織のちがい
----------------------------------------------------------------- -----------------------------------------------------------------
...@@ -577,6 +579,7 @@ Linux カーネルコミュニティは、一度に大量のコードの塊を ...@@ -577,6 +579,7 @@ Linux カーネルコミュニティは、一度に大量のコードの塊を
かし、500行のパッチは、正しいことをレビューするのに数時間かかるかも かし、500行のパッチは、正しいことをレビューするのに数時間かかるかも
しれません(時間はパッチのサイズなどにより指数関数に比例してかかりま しれません(時間はパッチのサイズなどにより指数関数に比例してかかりま
す) す)
小さいパッチは何かあったときにデバッグもとても簡単になります。パッ 小さいパッチは何かあったときにデバッグもとても簡単になります。パッ
チを1個1個取り除くのは、とても大きなパッチを当てた後に(かつ、何かお チを1個1個取り除くのは、とても大きなパッチを当てた後に(かつ、何かお
かしくなった後で)解剖するのに比べればとても簡単です。 かしくなった後で)解剖するのに比べればとても簡単です。
...@@ -591,6 +594,7 @@ Linux カーネルコミュニティは、一度に大量のコードの塊を ...@@ -591,6 +594,7 @@ Linux カーネルコミュニティは、一度に大量のコードの塊を
う。先生は簡潔な最高の解をみたいのです。良い生徒はこれを知って う。先生は簡潔な最高の解をみたいのです。良い生徒はこれを知って
おり、そして最終解の前の中間作業を提出することは決してないので おり、そして最終解の前の中間作業を提出することは決してないので
す" す"
カーネル開発でもこれは同じです。メンテナー達とレビューア達は、 カーネル開発でもこれは同じです。メンテナー達とレビューア達は、
問題を解決する解の背後になる思考プロセスをみたいとは思いません。 問題を解決する解の背後になる思考プロセスをみたいとは思いません。
彼らは単純であざやかな解決方法をみたいのです。 彼らは単純であざやかな解決方法をみたいのです。
......
NOTE: NOTE:
This is a Japanese translated version of This is a version of Documentation/stable_api_nonsense.txt into Japanese.
"Documentation/stable_api_nonsense.txt". This document is maintained by IKEDA, Munehiro <m-ikeda@ds.jp.nec.com>
This one is maintained by and the JF Project team <http://www.linux.or.jp/JF/>.
IKEDA, Munehiro <m-ikeda@ds.jp.nec.com> If you find any difference between this document and the original file
and JF Project team <http://www.linux.or.jp/JF/>. or a problem with the translation,
If you find difference with original file or problem in translation,
please contact the maintainer of this file or JF project. please contact the maintainer of this file or JF project.
Please also note that purpose of this file is easier to read for non Please also note that the purpose of this file is to be easier to read
English natives and not to be intended to fork. So, if you have any for non English (read: Japanese) speakers and is not intended as a
comments or updates of this file, please try to update fork. So if you have any comments or updates of this file, please try
Original(English) file at first. to update the original English file first.
Last Updated: 2007/07/18
================================== ==================================
これは、 これは、
linux-2.6.22-rc4/Documentation/stable_api_nonsense.txt の和訳 linux-2.6.22-rc4/Documentation/stable_api_nonsense.txt の和訳
......
...@@ -27,7 +27,6 @@ in detail, and briefly here: ...@@ -27,7 +27,6 @@ in detail, and briefly here:
- kobjects a simple object. - kobjects a simple object.
- kset a set of objects of a certain type. - kset a set of objects of a certain type.
- ktype a set of helpers for objects of a common type. - ktype a set of helpers for objects of a common type.
- subsystem a controlling object for a number of ksets.
The kobject infrastructure maintains a close relationship with the The kobject infrastructure maintains a close relationship with the
...@@ -54,13 +53,15 @@ embedded in larger data structures and replace fields they duplicate. ...@@ -54,13 +53,15 @@ embedded in larger data structures and replace fields they duplicate.
1.2 Definition 1.2 Definition
struct kobject { struct kobject {
const char * k_name;
char name[KOBJ_NAME_LEN]; char name[KOBJ_NAME_LEN];
atomic_t refcount; struct kref kref;
struct list_head entry; struct list_head entry;
struct kobject * parent; struct kobject * parent;
struct kset * kset; struct kset * kset;
struct kobj_type * ktype; struct kobj_type * ktype;
struct dentry * dentry; struct sysfs_dirent * sd;
wait_queue_head_t poll;
}; };
void kobject_init(struct kobject *); void kobject_init(struct kobject *);
...@@ -137,8 +138,7 @@ If a kobject does not have a parent when it is registered, its parent ...@@ -137,8 +138,7 @@ If a kobject does not have a parent when it is registered, its parent
becomes its dominant kset. becomes its dominant kset.
If a kobject does not have a parent nor a dominant kset, its directory If a kobject does not have a parent nor a dominant kset, its directory
is created at the top-level of the sysfs partition. This should only is created at the top-level of the sysfs partition.
happen for kobjects that are embedded in a struct subsystem.
...@@ -150,10 +150,10 @@ A kset is a set of kobjects that are embedded in the same type. ...@@ -150,10 +150,10 @@ A kset is a set of kobjects that are embedded in the same type.
struct kset { struct kset {
struct subsystem * subsys;
struct kobj_type * ktype; struct kobj_type * ktype;
struct list_head list; struct list_head list;
struct kobject kobj; struct kobject kobj;
struct kset_uevent_ops * uevent_ops;
}; };
...@@ -169,8 +169,7 @@ struct kobject * kset_find_obj(struct kset *, char *); ...@@ -169,8 +169,7 @@ struct kobject * kset_find_obj(struct kset *, char *);
The type that the kobjects are embedded in is described by the ktype The type that the kobjects are embedded in is described by the ktype
pointer. The subsystem that the kobject belongs to is pointed to by the pointer.
subsys pointer.
A kset contains a kobject itself, meaning that it may be registered in A kset contains a kobject itself, meaning that it may be registered in
the kobject hierarchy and exported via sysfs. More importantly, the the kobject hierarchy and exported via sysfs. More importantly, the
...@@ -209,6 +208,58 @@ the hierarchy. ...@@ -209,6 +208,58 @@ the hierarchy.
kset_find_obj() may be used to locate a kobject with a particular kset_find_obj() may be used to locate a kobject with a particular
name. The kobject, if found, is returned. name. The kobject, if found, is returned.
There are also some helper functions which names point to the formerly
existing "struct subsystem", whose functions have been taken over by
ksets.
decl_subsys(name,type,uevent_ops)
Declares a kset named '<name>_subsys' of type <type> with
uevent_ops <uevent_ops>. For example,
decl_subsys(devices, &ktype_device, &device_uevent_ops);
is equivalent to doing:
struct kset devices_subsys = {
.kobj = {
.name = "devices",
},
.ktype = &ktype_devices,
.uevent_ops = &device_uevent_ops,
};
The objects that are registered with a subsystem that use the
subsystem's default list must have their kset ptr set properly. These
objects may have embedded kobjects or ksets. The
following helpers make setting the kset easier:
kobj_set_kset_s(obj,subsys)
- Assumes that obj->kobj exists, and is a struct kobject.
- Sets the kset of that kobject to the kset <subsys>.
kset_set_kset_s(obj,subsys)
- Assumes that obj->kset exists, and is a struct kset.
- Sets the kset of the embedded kobject to the kset <subsys>.
subsys_set_kset(obj,subsys)
- Assumes obj->subsys exists, and is a struct subsystem.
- Sets obj->subsys.kset.kobj.kset to the subsystem's embedded kset.
void subsystem_init(struct kset *s);
int subsystem_register(struct kset *s);
void subsystem_unregister(struct kset *s);
struct kset *subsys_get(struct kset *s);
void kset_put(struct kset *s);
These are just wrappers around the respective kset_* functions.
2.3 sysfs 2.3 sysfs
...@@ -254,114 +305,3 @@ Instances of struct kobj_type are not registered; only referenced by ...@@ -254,114 +305,3 @@ Instances of struct kobj_type are not registered; only referenced by
the kset. A kobj_type may be referenced by an arbitrary number of the kset. A kobj_type may be referenced by an arbitrary number of
ksets, as there may be disparate sets of identical objects. ksets, as there may be disparate sets of identical objects.
4. subsystems
4.1 Description
A subsystem represents a significant entity of code that maintains an
arbitrary number of sets of objects of various types. Since the number
of ksets and the type of objects they contain are variable, a
generic representation of a subsystem is minimal.
struct subsystem {
struct kset kset;
struct rw_semaphore rwsem;
};
int subsystem_register(struct subsystem *);
void subsystem_unregister(struct subsystem *);
struct subsystem * subsys_get(struct subsystem * s);
void subsys_put(struct subsystem * s);
A subsystem contains an embedded kset so:
- It can be represented in the object hierarchy via the kset's
embedded kobject.
- It can maintain a default list of objects of one type.
Additional ksets may attach to the subsystem simply by referencing the
subsystem before they are registered. (This one-way reference means
that there is no way to determine the ksets that are attached to the
subsystem.)
All ksets that are attached to a subsystem share the subsystem's R/W
semaphore.
4.2 subsystem Programming Interface.
The subsystem programming interface is simple and does not offer the
flexibility that the kset and kobject programming interfaces do. They
may be registered and unregistered, as well as reference counted. Each
call forwards the calls to their embedded ksets (which forward the
calls to their embedded kobjects).
4.3 Helpers
A number of macros are available to make dealing with subsystems and
their embedded objects easier.
decl_subsys(name,type)
Declares a subsystem named '<name>_subsys', with an embedded kset of
type <type>. For example,
decl_subsys(devices,&ktype_devices);
is equivalent to doing:
struct subsystem device_subsys = {
.kset = {
.kobj = {
.name = "devices",
},
.ktype = &ktype_devices,
}
};
The objects that are registered with a subsystem that use the
subsystem's default list must have their kset ptr set properly. These
objects may have embedded kobjects, ksets, or other subsystems. The
following helpers make setting the kset easier:
kobj_set_kset_s(obj,subsys)
- Assumes that obj->kobj exists, and is a struct kobject.
- Sets the kset of that kobject to the subsystem's embedded kset.
kset_set_kset_s(obj,subsys)
- Assumes that obj->kset exists, and is a struct kset.
- Sets the kset of the embedded kobject to the subsystem's
embedded kset.
subsys_set_kset(obj,subsys)
- Assumes obj->subsys exists, and is a struct subsystem.
- Sets obj->subsys.kset.kobj.kset to the subsystem's embedded kset.
4.4 sysfs
subsystems are represented in sysfs via their embedded kobjects. They
follow the same rules as previously mentioned with no exceptions. They
typically receive a top-level directory in sysfs, except when their
embedded kobject is part of another kset, or the parent of the
embedded kobject is explicitly set.
Note that the subsystem's embedded kset must be 'attached' to the
subsystem itself in order to use its rwsem. This is done after
kset_add() has been called. (Not before, because kset_add() uses its
subsystem for a default parent if it doesn't already have one).
...@@ -10,7 +10,7 @@ kernel to userspace interfaces. The kernel to userspace interface is ...@@ -10,7 +10,7 @@ kernel to userspace interfaces. The kernel to userspace interface is
the one that application programs use, the syscall interface. That the one that application programs use, the syscall interface. That
interface is _very_ stable over time, and will not break. I have old interface is _very_ stable over time, and will not break. I have old
programs that were built on a pre 0.9something kernel that still work programs that were built on a pre 0.9something kernel that still work
just fine on the latest 2.6 kernel release. This interface is the one just fine on the latest 2.6 kernel release. That interface is the one
that users and application programmers can count on being stable. that users and application programmers can count on being stable.
......
Rules on how to access information in the Linux kernel sysfs Rules on how to access information in the Linux kernel sysfs
The kernel exported sysfs exports internal kernel implementation-details The kernel-exported sysfs exports internal kernel implementation details
and depends on internal kernel structures and layout. It is agreed upon and depends on internal kernel structures and layout. It is agreed upon
by the kernel developers that the Linux kernel does not provide a stable by the kernel developers that the Linux kernel does not provide a stable
internal API. As sysfs is a direct export of kernel internal internal API. As sysfs is a direct export of kernel internal
structures, the sysfs interface can not provide a stable interface eighter, structures, the sysfs interface cannot provide a stable interface either;
it may always change along with internal kernel changes. it may always change along with internal kernel changes.
To minimize the risk of breaking users of sysfs, which are in most cases To minimize the risk of breaking users of sysfs, which are in most cases
low-level userspace applications, with a new kernel release, the users low-level userspace applications, with a new kernel release, the users
of sysfs must follow some rules to use an as abstract-as-possible way to of sysfs must follow some rules to use an as-abstract-as-possible way to
access this filesystem. The current udev and HAL programs already access this filesystem. The current udev and HAL programs already
implement this and users are encouraged to plug, if possible, into the implement this and users are encouraged to plug, if possible, into the
abstractions these programs provide instead of accessing sysfs abstractions these programs provide instead of accessing sysfs directly.
directly.
But if you really do want or need to access sysfs directly, please follow But if you really do want or need to access sysfs directly, please follow
the following rules and then your programs should work with future the following rules and then your programs should work with future
...@@ -25,22 +24,22 @@ versions of the sysfs interface. ...@@ -25,22 +24,22 @@ versions of the sysfs interface.
implementation details in its own API. Therefore it is not better than implementation details in its own API. Therefore it is not better than
reading directories and opening the files yourself. reading directories and opening the files yourself.
Also, it is not actively maintained, in the sense of reflecting the Also, it is not actively maintained, in the sense of reflecting the
current kernel-development. The goal of providing a stable interface current kernel development. The goal of providing a stable interface
to sysfs has failed, it causes more problems, than it solves. It to sysfs has failed; it causes more problems than it solves. It
violates many of the rules in this document. violates many of the rules in this document.
- sysfs is always at /sys - sysfs is always at /sys
Parsing /proc/mounts is a waste of time. Other mount points are a Parsing /proc/mounts is a waste of time. Other mount points are a
system configuration bug you should not try to solve. For test cases, system configuration bug you should not try to solve. For test cases,
possibly support a SYSFS_PATH environment variable to overwrite the possibly support a SYSFS_PATH environment variable to overwrite the
applications behavior, but never try to search for sysfs. Never try application's behavior, but never try to search for sysfs. Never try
to mount it, if you are not an early boot script. to mount it, if you are not an early boot script.
- devices are only "devices" - devices are only "devices"
There is no such thing like class-, bus-, physical devices, There is no such thing like class-, bus-, physical devices,
interfaces, and such that you can rely on in userspace. Everything is interfaces, and such that you can rely on in userspace. Everything is
just simply a "device". Class-, bus-, physical, ... types are just just simply a "device". Class-, bus-, physical, ... types are just
kernel implementation details, which should not be expected by kernel implementation details which should not be expected by
applications that look for devices in sysfs. applications that look for devices in sysfs.
The properties of a device are: The properties of a device are:
...@@ -48,11 +47,11 @@ versions of the sysfs interface. ...@@ -48,11 +47,11 @@ versions of the sysfs interface.
- identical to the DEVPATH value in the event sent from the kernel - identical to the DEVPATH value in the event sent from the kernel
at device creation and removal at device creation and removal
- the unique key to the device at that point in time - the unique key to the device at that point in time
- the kernels path to the device-directory without the leading - the kernel's path to the device directory without the leading
/sys, and always starting with with a slash /sys, and always starting with with a slash
- all elements of a devpath must be real directories. Symlinks - all elements of a devpath must be real directories. Symlinks
pointing to /sys/devices must always be resolved to their real pointing to /sys/devices must always be resolved to their real
target, and the target path must be used to access the device. target and the target path must be used to access the device.
That way the devpath to the device matches the devpath of the That way the devpath to the device matches the devpath of the
kernel used at event time. kernel used at event time.
- using or exposing symlink values as elements in a devpath string - using or exposing symlink values as elements in a devpath string
...@@ -73,17 +72,17 @@ versions of the sysfs interface. ...@@ -73,17 +72,17 @@ versions of the sysfs interface.
link link
- it is retrieved by reading the "driver"-link and using only the - it is retrieved by reading the "driver"-link and using only the
last element of the target path last element of the target path
- devices which do not have "driver"-link, just do not have a - devices which do not have "driver"-link just do not have a
driver; copying the driver value in a child device context, is a driver; copying the driver value in a child device context is a
bug in the application bug in the application
o attributes o attributes
- the files in the device directory or files below a subdirectories - the files in the device directory or files below subdirectories
of the same device directory of the same device directory
- accessing attributes reached by a symlink pointing to another device, - accessing attributes reached by a symlink pointing to another device,
like the "device"-link, is a bug in the application like the "device"-link, is a bug in the application
Everything else is just a kernel driver-core implementation detail, Everything else is just a kernel driver-core implementation detail
that should not be assumed to be stable across kernel releases. that should not be assumed to be stable across kernel releases.
- Properties of parent devices never belong into a child device. - Properties of parent devices never belong into a child device.
...@@ -91,25 +90,25 @@ versions of the sysfs interface. ...@@ -91,25 +90,25 @@ versions of the sysfs interface.
context properties. If the device 'eth0' or 'sda' does not have a context properties. If the device 'eth0' or 'sda' does not have a
"driver"-link, then this device does not have a driver. Its value is empty. "driver"-link, then this device does not have a driver. Its value is empty.
Never copy any property of the parent-device into a child-device. Parent Never copy any property of the parent-device into a child-device. Parent
device-properties may change dynamically without any notice to the device properties may change dynamically without any notice to the
child device. child device.
- Hierarchy in a single device-tree - Hierarchy in a single device tree
There is only one valid place in sysfs where hierarchy can be examined There is only one valid place in sysfs where hierarchy can be examined
and this is below: /sys/devices. and this is below: /sys/devices.
It is planned, that all device directories will end up in the tree It is planned that all device directories will end up in the tree
below this directory. below this directory.
- Classification by subsystem - Classification by subsystem
There are currently three places for classification of devices: There are currently three places for classification of devices:
/sys/block, /sys/class and /sys/bus. It is planned that these will /sys/block, /sys/class and /sys/bus. It is planned that these will
not contain any device-directories themselves, but only flat lists of not contain any device directories themselves, but only flat lists of
symlinks pointing to the unified /sys/devices tree. symlinks pointing to the unified /sys/devices tree.
All three places have completely different rules on how to access All three places have completely different rules on how to access
device information. It is planned to merge all three device information. It is planned to merge all three
classification-directories into one place at /sys/subsystem, classification directories into one place at /sys/subsystem,
following the layout of the bus-directories. All buses and following the layout of the bus directories. All buses and
classes, including the converted block-subsystem, will show up classes, including the converted block subsystem, will show up
there. there.
The devices belonging to a subsystem will create a symlink in the The devices belonging to a subsystem will create a symlink in the
"devices" directory at /sys/subsystem/<name>/devices. "devices" directory at /sys/subsystem/<name>/devices.
...@@ -121,38 +120,38 @@ versions of the sysfs interface. ...@@ -121,38 +120,38 @@ versions of the sysfs interface.
subsystem name. subsystem name.
Assuming /sys/class/<subsystem> and /sys/bus/<subsystem>, or Assuming /sys/class/<subsystem> and /sys/bus/<subsystem>, or
/sys/block and /sys/class/block are not interchangeable, is a bug in /sys/block and /sys/class/block are not interchangeable is a bug in
the application. the application.
- Block - Block
The converted block-subsystem at /sys/class/block, or The converted block subsystem at /sys/class/block or
/sys/subsystem/block will contain the links for disks and partitions /sys/subsystem/block will contain the links for disks and partitions
at the same level, never in a hierarchy. Assuming the block-subsytem to at the same level, never in a hierarchy. Assuming the block subsytem to
contain only disks and not partition-devices in the same flat list is contain only disks and not partition devices in the same flat list is
a bug in the application. a bug in the application.
- "device"-link and <subsystem>:<kernel name>-links - "device"-link and <subsystem>:<kernel name>-links
Never depend on the "device"-link. The "device"-link is a workaround Never depend on the "device"-link. The "device"-link is a workaround
for the old layout, where class-devices are not created in for the old layout, where class devices are not created in
/sys/devices/ like the bus-devices. If the link-resolving of a /sys/devices/ like the bus devices. If the link-resolving of a
device-directory does not end in /sys/devices/, you can use the device directory does not end in /sys/devices/, you can use the
"device"-link to find the parent devices in /sys/devices/. That is the "device"-link to find the parent devices in /sys/devices/. That is the
single valid use of the "device"-link, it must never appear in any single valid use of the "device"-link; it must never appear in any
path as an element. Assuming the existence of the "device"-link for path as an element. Assuming the existence of the "device"-link for
a device in /sys/devices/ is a bug in the application. a device in /sys/devices/ is a bug in the application.
Accessing /sys/class/net/eth0/device is a bug in the application. Accessing /sys/class/net/eth0/device is a bug in the application.
Never depend on the class-specific links back to the /sys/class Never depend on the class-specific links back to the /sys/class
directory. These links are also a workaround for the design mistake directory. These links are also a workaround for the design mistake
that class-devices are not created in /sys/devices. If a device that class devices are not created in /sys/devices. If a device
directory does not contain directories for child devices, these links directory does not contain directories for child devices, these links
may be used to find the child devices in /sys/class. That is the single may be used to find the child devices in /sys/class. That is the single
valid use of these links, they must never appear in any path as an valid use of these links; they must never appear in any path as an
element. Assuming the existence of these links for devices which are element. Assuming the existence of these links for devices which are
real child device directories in the /sys/devices tree, is a bug in real child device directories in the /sys/devices tree is a bug in
the application. the application.
It is planned to remove all these links when when all class-device It is planned to remove all these links when all class device
directories live in /sys/devices. directories live in /sys/devices.
- Position of devices along device chain can change. - Position of devices along device chain can change.
...@@ -161,6 +160,5 @@ versions of the sysfs interface. ...@@ -161,6 +160,5 @@ versions of the sysfs interface.
the chain. You must always request the parent device you are looking for the chain. You must always request the parent device you are looking for
by its subsystem value. You need to walk up the chain until you find by its subsystem value. You need to walk up the chain until you find
the device that matches the expected subsystem. Depending on a specific the device that matches the expected subsystem. Depending on a specific
position of a parent device, or exposing relative paths, using "../" to position of a parent device or exposing relative paths using "../" to
access the chain of parents, is a bug in the application. access the chain of parents is a bug in the application.
...@@ -24,8 +24,6 @@ ...@@ -24,8 +24,6 @@
#include "base.h" #include "base.h"
#include "power/power.h" #include "power/power.h"
extern const char *kobject_actions[];
int (*platform_notify)(struct device * dev) = NULL; int (*platform_notify)(struct device * dev) = NULL;
int (*platform_notify_remove)(struct device * dev) = NULL; int (*platform_notify_remove)(struct device * dev) = NULL;
...@@ -680,8 +678,7 @@ static int device_add_class_symlinks(struct device *dev) ...@@ -680,8 +678,7 @@ static int device_add_class_symlinks(struct device *dev)
if (error) if (error)
goto out_subsys; goto out_subsys;
} }
/* only bus-device parents get a "device"-link */ if (dev->parent) {
if (dev->parent && dev->parent->bus) {
error = sysfs_create_link(&dev->kobj, &dev->parent->kobj, error = sysfs_create_link(&dev->kobj, &dev->parent->kobj,
"device"); "device");
if (error) if (error)
......
...@@ -232,6 +232,7 @@ fw_realloc_buffer(struct firmware_priv *fw_priv, int min_size) ...@@ -232,6 +232,7 @@ fw_realloc_buffer(struct firmware_priv *fw_priv, int min_size)
/** /**
* firmware_data_write - write method for firmware * firmware_data_write - write method for firmware
* @kobj: kobject for the device * @kobj: kobject for the device
* @bin_attr: bin_attr structure
* @buffer: buffer being written * @buffer: buffer being written
* @offset: buffer offset for write in total data store area * @offset: buffer offset for write in total data store area
* @count: buffer size * @count: buffer size
......
...@@ -1517,7 +1517,7 @@ EXPORT_SYMBOL(pcie_get_readrq); ...@@ -1517,7 +1517,7 @@ EXPORT_SYMBOL(pcie_get_readrq);
/** /**
* pcie_set_readrq - set PCI Express maximum memory read request * pcie_set_readrq - set PCI Express maximum memory read request
* @dev: PCI device to query * @dev: PCI device to query
* @count: maximum memory read count in bytes * @rq: maximum memory read count in bytes
* valid values are 128, 256, 512, 1024, 2048, 4096 * valid values are 128, 256, 512, 1024, 2048, 4096
* *
* If possible sets maximum read byte count * If possible sets maximum read byte count
......
...@@ -56,6 +56,9 @@ enum kobject_action { ...@@ -56,6 +56,9 @@ enum kobject_action {
KOBJ_MAX KOBJ_MAX
}; };
/* The list of strings defining the valid kobject actions as specified above */
extern const char *kobject_actions[];
struct kobject { struct kobject {
const char * k_name; const char * k_name;
char name[KOBJ_NAME_LEN]; char name[KOBJ_NAME_LEN];
...@@ -108,9 +111,15 @@ struct kobj_type { ...@@ -108,9 +111,15 @@ struct kobj_type {
struct attribute ** default_attrs; struct attribute ** default_attrs;
}; };
struct kset_uevent_ops {
int (*filter)(struct kset *kset, struct kobject *kobj);
const char *(*name)(struct kset *kset, struct kobject *kobj);
int (*uevent)(struct kset *kset, struct kobject *kobj, char **envp,
int num_envp, char *buffer, int buffer_size);
};
/** /*
* kset - a set of kobjects of a specific type, belonging * struct kset - a set of kobjects of a specific type, belonging
* to a specific subsystem. * to a specific subsystem.
* *
* All kobjects of a kset should be embedded in an identical * All kobjects of a kset should be embedded in an identical
...@@ -126,13 +135,6 @@ struct kobj_type { ...@@ -126,13 +135,6 @@ struct kobj_type {
* supress the event generation or add subsystem specific * supress the event generation or add subsystem specific
* variables carried with the event. * variables carried with the event.
*/ */
struct kset_uevent_ops {
int (*filter)(struct kset *kset, struct kobject *kobj);
const char *(*name)(struct kset *kset, struct kobject *kobj);
int (*uevent)(struct kset *kset, struct kobject *kobj, char **envp,
int num_envp, char *buffer, int buffer_size);
};
struct kset { struct kset {
struct kobj_type * ktype; struct kobj_type * ktype;
struct list_head list; struct list_head list;
...@@ -173,7 +175,7 @@ static inline struct kobj_type * get_ktype(struct kobject * k) ...@@ -173,7 +175,7 @@ static inline struct kobj_type * get_ktype(struct kobject * k)
extern struct kobject * kset_find_obj(struct kset *, const char *); extern struct kobject * kset_find_obj(struct kset *, const char *);
/** /*
* Use this when initializing an embedded kset with no other * Use this when initializing an embedded kset with no other
* fields to initialize. * fields to initialize.
*/ */
...@@ -198,7 +200,7 @@ extern struct kset kernel_subsys; ...@@ -198,7 +200,7 @@ extern struct kset kernel_subsys;
/* The global /sys/hypervisor/ subsystem */ /* The global /sys/hypervisor/ subsystem */
extern struct kset hypervisor_subsys; extern struct kset hypervisor_subsys;
/** /*
* Helpers for setting the kset of registered objects. * Helpers for setting the kset of registered objects.
* Often, a registered object belongs to a kset embedded in a * Often, a registered object belongs to a kset embedded in a
* subsystem. These do no magic, just make the resulting code * subsystem. These do no magic, just make the resulting code
...@@ -233,7 +235,7 @@ extern struct kset hypervisor_subsys; ...@@ -233,7 +235,7 @@ extern struct kset hypervisor_subsys;
/** /**
* subsys_set_kset(obj,subsys) - set kset for subsystem * subsys_set_kset(obj,subsys) - set kset for subsystem
* @obj: ptr to some object type. * @obj: ptr to some object type.
* @subsys: a subsystem object (not a ptr). * @_subsys: a subsystem object (not a ptr).
* *
* Can be used for any object type with an embedded ->subsys. * Can be used for any object type with an embedded ->subsys.
* Sets the kset of @obj's kobject to @subsys.kset. This makes * Sets the kset of @obj's kobject to @subsys.kset. This makes
......
...@@ -567,7 +567,12 @@ static void __init kernel_param_sysfs_setup(const char *name, ...@@ -567,7 +567,12 @@ static void __init kernel_param_sysfs_setup(const char *name,
kobject_set_name(&mk->kobj, name); kobject_set_name(&mk->kobj, name);
kobject_init(&mk->kobj); kobject_init(&mk->kobj);
ret = kobject_add(&mk->kobj); ret = kobject_add(&mk->kobj);
BUG_ON(ret < 0); if (ret) {
printk(KERN_ERR "Module '%s' failed to be added to sysfs, "
"error number %d\n", name, ret);
printk(KERN_ERR "The system will be unstable now.\n");
return;
}
param_sysfs_setup(mk, kparam, num_params, name_skip); param_sysfs_setup(mk, kparam, num_params, name_skip);
kobject_uevent(&mk->kobj, KOBJ_ADD); kobject_uevent(&mk->kobj, KOBJ_ADD);
} }
......
...@@ -25,14 +25,6 @@ ...@@ -25,14 +25,6 @@
#define BUFFER_SIZE 2048 /* buffer for the variables */ #define BUFFER_SIZE 2048 /* buffer for the variables */
#define NUM_ENVP 32 /* number of env pointers */ #define NUM_ENVP 32 /* number of env pointers */
#if defined(CONFIG_HOTPLUG)
u64 uevent_seqnum;
char uevent_helper[UEVENT_HELPER_PATH_LEN] = "/sbin/hotplug";
static DEFINE_SPINLOCK(sequence_lock);
#if defined(CONFIG_NET)
static struct sock *uevent_sock;
#endif
/* the strings here must match the enum in include/linux/kobject.h */ /* the strings here must match the enum in include/linux/kobject.h */
const char *kobject_actions[] = { const char *kobject_actions[] = {
"add", "add",
...@@ -43,6 +35,14 @@ const char *kobject_actions[] = { ...@@ -43,6 +35,14 @@ const char *kobject_actions[] = {
"offline", "offline",
}; };
#if defined(CONFIG_HOTPLUG)
u64 uevent_seqnum;
char uevent_helper[UEVENT_HELPER_PATH_LEN] = "/sbin/hotplug";
static DEFINE_SPINLOCK(sequence_lock);
#if defined(CONFIG_NET)
static struct sock *uevent_sock;
#endif
/** /**
* kobject_uevent_env - send an uevent with environmental data * kobject_uevent_env - send an uevent with environmental data
* *
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment