Commit efefc6eb 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: (75 commits)
  PM: merge device power-management source files
  sysfs: add copyrights
  kobject: update the copyrights
  kset: add some kerneldoc to help describe what these strange things are
  Driver core: rename ktype_edd and ktype_efivar
  Driver core: rename ktype_driver
  Driver core: rename ktype_device
  Driver core: rename ktype_class
  driver core: remove subsystem_init()
  sysfs: move sysfs file poll implementation to sysfs_open_dirent
  sysfs: implement sysfs_open_dirent
  sysfs: move sysfs_dirent->s_children into sysfs_dirent->s_dir
  sysfs: make sysfs_root a regular directory dirent
  sysfs: open code sysfs_attach_dentry()
  sysfs: make s_elem an anonymous union
  sysfs: make bin attr open get active reference of parent too
  sysfs: kill unnecessary NULL pointer check in sysfs_release()
  sysfs: kill unnecessary sysfs_get() in open paths
  sysfs: reposition sysfs_dirent->s_mode.
  sysfs: kill sysfs_update_file()
  ...
parents 117494a1 cd59abfc
NOTE:
NOTE:
This is a version of Documentation/HOWTO translated into Japanese.
This document is maintained by Tsugikazu Shibata <tshibata@ab.jp.nec.com>
and the JF Project team <www.linux.or.jp/JF>.
......@@ -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: 2007/07/18
Last Updated: 2007/09/23
==================================
これは、
linux-2.6.22/Documentation/HOWTO
linux-2.6.23/Documentation/HOWTO
の和訳です。
翻訳団体: JF プロジェクト < http://www.linux.or.jp/JF/ >
翻訳日: 2007/07/16
翻訳日: 2007/09/19
翻訳者: 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>
......@@ -27,6 +27,7 @@ linux-2.6.22/Documentation/HOWTO
野口さん (Kenji Noguchi) <tokyo246 at gmail dot com>
河内さん (Takayoshi Kochi) <t-kochi at bq dot jp dot nec dot com>
岩本さん (iwamoto) <iwamoto.kn at ncos dot nec dot co dot jp>
内田さん (Satoshi Uchida) <s-uchida at ap dot jp dot nec dot com>
==================================
Linux カーネル開発のやり方
......@@ -40,7 +41,7 @@ Linux カーネル開発コミュニティと共に活動するやり方を学
手助けになります。
もし、このドキュメントのどこかが古くなっていた場合には、このドキュメン
トの最後にリストしたメンテナにパッチを送ってください。
トの最後にリストしたメンテナにパッチを送ってください。
はじめに
---------
......@@ -59,7 +60,7 @@ Linux カーネル開発コミュニティと共に活動するやり方を学
ネル開発者には必要です。アーキテクチャ向けの低レベル部分の開発をするの
でなければ、(どんなアーキテクチャでも)アセンブリ(訳注: 言語)は必要あり
ません。以下の本は、C 言語の十分な知識や何年もの経験に取って代わるもの
ではありませんが、少なくともリファレンスとしてはい本です。
ではありませんが、少なくともリファレンスとしてはい本です。
- "The C Programming Language" by Kernighan and Ritchie [Prentice Hall]
-『プログラミング言語C第2版』(B.W. カーニハン/D.M. リッチー著 石田晴久訳) [共立出版]
- "Practical C Programming" by Steve Oualline [O'Reilly]
......@@ -76,7 +77,7 @@ Linux カーネル開発コミュニティと共に活動するやり方を学
ときどき、カーネルがツールチェインや C 言語拡張に置いている前提がどう
なっているのかわかりにくいことがあり、また、残念なことに決定的なリファ
レンスは存在しません。情報を得るには、gcc の info ページ( info gcc )を
てください。
てください。
あなたは既存の開発コミュニティと一緒に作業する方法を学ぼうとしているこ
とに留意してください。そのコミュニティは、コーディング、スタイル、
......@@ -92,7 +93,7 @@ Linux カーネル開発コミュニティと共に活動するやり方を学
Linux カーネルのソースコードは GPL ライセンスの下でリリースされていま
す。ライセンスの詳細については、ソースツリーのメインディレクトリに存在
する、COPYING のファイルをてください。もしライセンスについてさらに質
する、COPYING のファイルをてください。もしライセンスについてさらに質
問があれば、Linux Kernel メーリングリストに質問するのではなく、どうぞ
法律家に相談してください。メーリングリストの人達は法律家ではなく、法的
問題については彼らの声明はあてにするべきではありません。
......@@ -109,7 +110,8 @@ Linux カーネルソースツリーは幅広い範囲のドキュメントを
新しいドキュメントファイルも追加することを勧めます。
カーネルの変更が、カーネルがユーザ空間に公開しているインターフェイスの
変更を引き起こす場合、その変更を説明するマニュアルページのパッチや情報
をマニュアルページのメンテナ mtk-manpages@gmx.net に送ることを勧めます。
をマニュアルページのメンテナ mtk-manpages@gmx.net に送ることを勧めま
す。
以下はカーネルソースツリーに含まれている読んでおくべきファイルの一覧で
す-
......@@ -117,7 +119,7 @@ Linux カーネルソースツリーは幅広い範囲のドキュメントを
README
このファイルは Linuxカーネルの簡単な背景とカーネルを設定(訳注
configure )し、生成(訳注 build )するために必要なことは何かが書かれ
ています。カーネルに関して初めての人はここからスタートするといで
ています。カーネルに関して初めての人はここからスタートするといで
しょう。
Documentation/Changes
......@@ -128,7 +130,7 @@ Linux カーネルソースツリーは幅広い範囲のドキュメントを
Documentation/CodingStyle
これは Linux カーネルのコーディングスタイルと背景にある理由を記述
しています。全ての新しいコードはこのドキュメントにあるガイドライン
に従っていることを期待されています。大部分のメンテナはこれらのルー
に従っていることを期待されています。大部分のメンテナはこれらのルー
ルに従っているものだけを受け付け、多くの人は正しいスタイルのコード
だけをレビューします。
......@@ -168,16 +170,16 @@ Linux カーネルソースツリーは幅広い範囲のドキュメントを
支援してください。
Documentation/ManagementStyle
このドキュメントは Linux カーネルのメンテナ達がどう行動するか、
このドキュメントは Linux カーネルのメンテナ達がどう行動するか、
彼らの手法の背景にある共有されている精神について記述しています。こ
れはカーネル開発の初心者なら(もしくは、単に興味があるだけの人でも)
重要です。なぜならこのドキュメントは、カーネルメンテナ達の独特な
重要です。なぜならこのドキュメントは、カーネルメンテナ達の独特な
行動についての多くの誤解や混乱を解消するからです。
Documentation/stable_kernel_rules.txt
このファイルはどのように stable カーネルのリリースが行われるかのルー
ルが記述されています。そしてこれらのリリースの中のどこかで変更を取
り入れてもらいたい場合に何をすればいかが示されています。
り入れてもらいたい場合に何をすればいかが示されています。
Documentation/kernel-docs.txt
  カーネル開発に付随する外部ドキュメントのリストです。もしあなたが
......@@ -218,9 +220,9 @@ web サイトには、コードの構成、サブシステム、現在存在す
ここには、また、カーネルのコンパイルのやり方やパッチの当て方などの間接
的な基本情報も記述されています。
あなたがどこからスタートしていかわからないが、Linux カーネル開発コミュ
あなたがどこからスタートしていかわからないが、Linux カーネル開発コミュ
ニティに参加して何かすることをさがしている場合には、Linux kernel
Janitor's プロジェクトにいけばいでしょう -
Janitor's プロジェクトにいけばいでしょう -
http://janitor.kernelnewbies.org/
ここはそのようなスタートをするのにうってつけの場所です。ここには、
Linux カーネルソースツリーの中に含まれる、きれいにし、修正しなければな
......@@ -243,7 +245,7 @@ Linux カーネルソースツリーの中に含まれる、きれいにし、
自己参照方式で、索引がついた web 形式で、ソースコードを参照することが
できます。この最新の素晴しいカーネルコードのリポジトリは以下で見つかり
ます-
http://sosdg.org/~coywolf/lxr/
http://sosdg.org/~qiyong/lxr/
開発プロセス
-----------------------
......@@ -265,9 +267,9 @@ Linux カーネルの開発プロセスは現在幾つかの異なるメイン
以下のとおり-
- 新しいカーネルがリリースされた直後に、2週間の特別期間が設けられ、
この期間中に、メンテナ達は Linus に大きな差分を送ることができま
す。このような差分は通常 -mm カーネルに数週間含まれてきたパッチで
す。 大きな変更は git(カーネルのソース管理ツール、詳細は
この期間中に、メンテナ達は Linus に大きな差分を送ることができます。
このような差分は通常 -mm カーネルに数週間含まれてきたパッチです。
大きな変更は git(カーネルのソース管理ツール、詳細は
http://git.or.cz/ 参照) を使って送るのが好ましいやり方ですが、パッ
チファイルの形式のまま送るのでも十分です。
......@@ -285,6 +287,10 @@ Linux カーネルの開発プロセスは現在幾つかの異なるメイン
に安定した状態にあると判断したときにリリースされます。目標は毎週新
しい -rc カーネルをリリースすることです。
- 以下の URL で各 -rc リリースに存在する既知の後戻り問題のリスト
が追跡されます-
http://kernelnewbies.org/known_regressions
- このプロセスはカーネルが 「準備ができた」と考えられるまで継続しま
す。このプロセスはだいたい 6週間継続します。
......@@ -331,8 +337,8 @@ Andrew は個別のサブシステムカーネルツリーとパッチを全て
linux-kernel メーリングリストで収集された多数のパッチと同時に一つにま
とめます。
このツリーは新機能とパッチが検証される場となります。ある期間の間パッチ
が -mm に入って価値を証明されたら、Andrew やサブシステムメンテナが、
インラインへ入れるように Linus にプッシュします。
が -mm に入って価値を証明されたら、Andrew やサブシステムメンテナが、
インラインへ入れるように Linus にプッシュします。
メインカーネルツリーに含めるために Linus に送る前に、すべての新しいパッ
チが -mm ツリーでテストされることが強く推奨されます。
......@@ -460,7 +466,7 @@ MAINTAINERS ファイルにリストがありますので参照してくださ
せん-
彼らはあなたのパッチの行毎にコメントを入れたいので、そのためにはそうす
るしかありません。あなたのメールプログラムが空白やタブを圧縮しないよう
に確認した方がいです。最初の良いテストとしては、自分にメールを送って
に確認した方がいです。最初の良いテストとしては、自分にメールを送って
みて、そのパッチを自分で当ててみることです。もしそれがうまく行かないな
ら、あなたのメールプログラムを直してもらうか、正しく動くように変えるべ
きです。
......@@ -507,14 +513,14 @@ MAINTAINERS ファイルにリストがありますので参照してくださ
とも普通のことです。これはあなたのパッチが受け入れられないということで
は *ありません*、そしてあなた自身に反対することを意味するのでも *ありま
せん*。単に自分のパッチに対して指摘された問題を全て修正して再送すれば
いのです。
いのです。
カーネルコミュニティと企業組織のちがい
-----------------------------------------------------------------
カーネルコミュニティは大部分の伝統的な会社の開発環境とは異ったやり方で
動いています。以下は問題を避けるためにできるといことのリストです-
動いています。以下は問題を避けるためにできるといことのリストです-
あなたの提案する変更について言うときのうまい言い方:
......@@ -525,7 +531,7 @@ MAINTAINERS ファイルにリストがありますので参照してくださ
- "以下は一連の小さなパッチ群ですが..."
- "これは典型的なマシンでの性能を向上させます.."
やめた方がい悪い言い方:
やめた方がい悪い言い方:
- このやり方で AIX/ptx/Solaris ではできたので、できるはずだ
- 私はこれを20年もの間やってきた、だから
......@@ -575,10 +581,10 @@ Linux カーネルコミュニティは、一度に大量のコードの塊を
1) 小さいパッチはあなたのパッチが適用される見込みを大きくします、カー
ネルの人達はパッチが正しいかどうかを確認する時間や労力をかけないか
らです。5行のパッチはメンテナがたった1秒見るだけで適用できます。
かし、500行のパッチは、正しいことをレビューするのに数時間かかるか
しれません(時間はパッチのサイズなどにより指数関数に比例してかかり
す)
らです。5行のパッチはメンテナがたった1秒見るだけで適用できます。
かし、500行のパッチは、正しいことをレビューするのに数時間かかるか
しれません(時間はパッチのサイズなどにより指数関数に比例してかかり
す)
小さいパッチは何かあったときにデバッグもとても簡単になります。パッ
チを1個1個取り除くのは、とても大きなパッチを当てた後に(かつ、何かお
......@@ -587,23 +593,23 @@ Linux カーネルコミュニティは、一度に大量のコードの塊を
2) 小さいパッチを送るだけでなく、送るまえに、書き直して、シンプルにす
る(もしくは、単に順番を変えるだけでも)ことも、とても重要です。
以下はカーネル開発者の Al Viro のたとえ話です:
以下はカーネル開発者の Al Viro のたとえ話です:
"生徒の数学の宿題を採点する先生のことを考えてみてください、先
生は生徒が解に到達するまでの試行錯誤をたいとは思わないでしょ
う。先生は簡潔な最高の解をたいのです。良い生徒はこれを知って
生は生徒が解に到達するまでの試行錯誤をたいとは思わないでしょ
う。先生は簡潔な最高の解をたいのです。良い生徒はこれを知って
おり、そして最終解の前の中間作業を提出することは決してないので
す"
カーネル開発でもこれは同じです。メンテナ達とレビューア達は、
問題を解決する解の背後になる思考プロセスをたいとは思いません。
彼らは単純であざやかな解決方法をたいのです。
カーネル開発でもこれは同じです。メンテナ達とレビューア達は、
問題を解決する解の背後になる思考プロセスをたいとは思いません。
彼らは単純であざやかな解決方法をたいのです。
あざやかな解を説明するのと、コミュニティと共に仕事をし、未解決の仕事を
議論することのバランスをキープするのは難しいかもしれません。
ですから、開発プロセスの早期段階で改善のためのフィードバックをもらうよ
うにするのもいですが、変更点を小さい部分に分割して全体ではまだ完成し
ていない仕事を(部分的に)取り込んでもらえるようにすることもいことです。
うにするのもいですが、変更点を小さい部分に分割して全体ではまだ完成し
ていない仕事を(部分的に)取り込んでもらえるようにすることもいことです。
また、でき上がっていないものや、"将来直す" ようなパッチを、本流に含め
てもらうように送っても、それは受け付けられないことを理解してください。
......@@ -629,7 +635,7 @@ Linux カーネルコミュニティは、一度に大量のコードの塊を
- テスト結果
これについて全てがどのようにあるべきかについての詳細は、以下のドキュメ
ントの ChangeLog セクションをてください-
ントの ChangeLog セクションをてください-
"The Perfect Patch"
http://www.zip.com.au/~akpm/linux/patches/stuff/tpp.txt
......
......@@ -1437,6 +1437,10 @@ and is between 256 and 4096 characters. It is defined in the file
pt. [PARIDE]
See Documentation/paride.txt.
pty.legacy_count=
[KNL] Number of legacy pty's. Overwrites compiled-in
default number.
quiet [KNL] Disable most log messages
r128= [HW,DRM]
......
......@@ -54,7 +54,6 @@ embedded in larger data structures and replace fields they duplicate.
struct kobject {
const char * k_name;
char name[KOBJ_NAME_LEN];
struct kref kref;
struct list_head entry;
struct kobject * parent;
......@@ -223,18 +222,15 @@ 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,
};
kobject_set_name(&devices_subsys, name);
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:
following helper makes setting the kset easier:
kobj_set_kset_s(obj,subsys)
......@@ -242,22 +238,8 @@ 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.
......
......@@ -66,8 +66,7 @@ static int tiocx_match(struct device *dev, struct device_driver *drv)
}
static int tiocx_uevent(struct device *dev, char **envp, int num_envp,
char *buffer, int buffer_size)
static int tiocx_uevent(struct device *dev, struct kobj_uevent_env *env)
{
return -ENODEV;
}
......
......@@ -57,26 +57,21 @@ ssize_t of_device_get_modalias(struct of_device *ofdev,
return tsize;
}
int of_device_uevent(struct device *dev,
char **envp, int num_envp, char *buffer, int buffer_size)
int of_device_uevent(struct device *dev, struct kobj_uevent_env *env)
{
struct of_device *ofdev;
const char *compat;
int i = 0, length = 0, seen = 0, cplen, sl;
int seen = 0, cplen, sl;
if (!dev)
return -ENODEV;
ofdev = to_of_device(dev);
if (add_uevent_var(envp, num_envp, &i,
buffer, buffer_size, &length,
"OF_NAME=%s", ofdev->node->name))
if (add_uevent_var(env, "OF_NAME=%s", ofdev->node->name))
return -ENOMEM;
if (add_uevent_var(envp, num_envp, &i,
buffer, buffer_size, &length,
"OF_TYPE=%s", ofdev->node->type))
if (add_uevent_var(env, "OF_TYPE=%s", ofdev->node->type))
return -ENOMEM;
/* Since the compatible field can contain pretty much anything
......@@ -85,9 +80,7 @@ int of_device_uevent(struct device *dev,
compat = of_get_property(ofdev->node, "compatible", &cplen);
while (compat && *compat && cplen > 0) {
if (add_uevent_var(envp, num_envp, &i,
buffer, buffer_size, &length,
"OF_COMPATIBLE_%d=%s", seen, compat))
if (add_uevent_var(env, "OF_COMPATIBLE_%d=%s", seen, compat))
return -ENOMEM;
sl = strlen (compat) + 1;
......@@ -96,25 +89,17 @@ int of_device_uevent(struct device *dev,
seen++;
}
if (add_uevent_var(envp, num_envp, &i,
buffer, buffer_size, &length,
"OF_COMPATIBLE_N=%d", seen))
if (add_uevent_var(env, "OF_COMPATIBLE_N=%d", seen))
return -ENOMEM;
/* modalias is trickier, we add it in 2 steps */
if (add_uevent_var(envp, num_envp, &i,
buffer, buffer_size, &length,
"MODALIAS="))
if (add_uevent_var(env, "MODALIAS="))
return -ENOMEM;
sl = of_device_get_modalias(ofdev, &buffer[length-1],
buffer_size-length);
if (sl >= (buffer_size-length))
sl = of_device_get_modalias(ofdev, &env->buf[env->buflen-1],
sizeof(env->buf) - env->buflen);
if (sl >= (sizeof(env->buf) - env->buflen))
return -ENOMEM;
length += sl;
envp[i] = NULL;
env->buflen += sl;
return 0;
}
......
......@@ -317,30 +317,20 @@ static int vio_bus_match(struct device *dev, struct device_driver *drv)
return (ids != NULL) && (vio_match_device(ids, vio_dev) != NULL);
}
static int vio_hotplug(struct device *dev, char **envp, int num_envp,
char *buffer, int buffer_size)
static int vio_hotplug(struct device *dev, struct kobj_uevent_env *env)
{
const struct vio_dev *vio_dev = to_vio_dev(dev);
struct device_node *dn;
const char *cp;
int length;
if (!num_envp)
return -ENOMEM;
dn = dev->archdata.of_node;
if (!dn)
return -ENODEV;
cp = of_get_property(dn, "compatible", &length);
cp = of_get_property(dn, "compatible", NULL);
if (!cp)
return -ENODEV;
envp[0] = buffer;
length = scnprintf(buffer, buffer_size, "MODALIAS=vio:T%sS%s",
vio_dev->type, cp);
if ((buffer_size - length) <= 0)
return -ENOMEM;
envp[1] = NULL;
add_uevent_var(env, "MODALIAS=vio:T%sS%s", vio_dev->type, cp);
return 0;
}
......
......@@ -437,18 +437,13 @@ static void ps3_system_bus_shutdown(struct device *_dev)
dev_dbg(&dev->core, " <- %s:%d\n", __func__, __LINE__);
}
static int ps3_system_bus_uevent(struct device *_dev, char **envp,
int num_envp, char *buffer, int buffer_size)
static int ps3_system_bus_uevent(struct device *_dev, struct kobj_uevent_env *env)
{
struct ps3_system_bus_device *dev = ps3_dev_to_system_bus_dev(_dev);
int i = 0, length = 0;
if (add_uevent_var(envp, num_envp, &i, buffer, buffer_size,
&length, "MODALIAS=ps3:%d",
dev->match_id))
if (add_uevent_var(env, "MODALIAS=ps3:%d", dev->match_id))
return -ENOMEM;
envp[i] = NULL;
return 0;
}
......
......@@ -1010,10 +1010,7 @@ unlock:
}
EXPORT_SYMBOL_GPL(bsg_register_queue);
static struct cdev bsg_cdev = {
.kobj = {.name = "bsg", },
.owner = THIS_MODULE,
};
static struct cdev bsg_cdev;
static int __init bsg_init(void)
{
......
......@@ -186,7 +186,7 @@ static elevator_t *elevator_alloc(struct request_queue *q,
eq->ops = &e->ops;
eq->elevator_type = e;
kobject_init(&eq->kobj);
snprintf(eq->kobj.name, KOBJ_NAME_LEN, "%s", "iosched");
kobject_set_name(&eq->kobj, "%s", "iosched");
eq->kobj.ktype = &elv_ktype;
mutex_init(&eq->sysfs_lock);
......
......@@ -540,61 +540,42 @@ static int block_uevent_filter(struct kset *kset, struct kobject *kobj)
return ((ktype == &ktype_block) || (ktype == &ktype_part));
}
static int block_uevent(struct kset *kset, struct kobject *kobj, char **envp,
int num_envp, char *buffer, int buffer_size)
static int block_uevent(struct kset *kset, struct kobject *kobj,
struct kobj_uevent_env *env)
{
struct kobj_type *ktype = get_ktype(kobj);
struct device *physdev;
struct gendisk *disk;
struct hd_struct *part;
int length = 0;
int i = 0;
if (ktype == &ktype_block) {
disk = container_of(kobj, struct gendisk, kobj);
add_uevent_var(envp, num_envp, &i, buffer, buffer_size,
&length, "MINOR=%u", disk->first_minor);
add_uevent_var(env, "MINOR=%u", disk->first_minor);
} else if (ktype == &ktype_part) {
disk = container_of(kobj->parent, struct gendisk, kobj);
part = container_of(kobj, struct hd_struct, kobj);
add_uevent_var(envp, num_envp, &i, buffer, buffer_size,
&length, "MINOR=%u",
add_uevent_var(env, "MINOR=%u",
disk->first_minor + part->partno);
} else
return 0;
add_uevent_var(envp, num_envp, &i, buffer, buffer_size, &length,
"MAJOR=%u", disk->major);
add_uevent_var(env, "MAJOR=%u", disk->major);
/* add physical device, backing this device */
physdev = disk->driverfs_dev;
if (physdev) {
char *path = kobject_get_path(&physdev->kobj, GFP_KERNEL);
add_uevent_var(envp, num_envp, &i, buffer, buffer_size,
&length, "PHYSDEVPATH=%s", path);
add_uevent_var(env, "PHYSDEVPATH=%s", path);
kfree(path);
if (physdev->bus)
add_uevent_var(envp, num_envp, &i,
buffer, buffer_size, &length,
"PHYSDEVBUS=%s",
physdev->bus->name);
add_uevent_var(env, "PHYSDEVBUS=%s", physdev->bus->name);
if (physdev->driver)
add_uevent_var(envp, num_envp, &i,
buffer, buffer_size, &length,
"PHYSDEVDRIVER=%s",
physdev->driver->name);
add_uevent_var(env, physdev->driver->name);
}
/* terminate, set to next free slot, shrink available space */
envp[i] = NULL;
envp = &envp[i];
num_envp -= i;
buffer = &buffer[length];
buffer_size -= length;
return 0;
}
......
......@@ -1854,7 +1854,7 @@ struct request_queue *blk_alloc_queue_node(gfp_t gfp_mask, int node_id)
init_timer(&q->unplug_timer);
snprintf(q->kobj.name, KOBJ_NAME_LEN, "%s", "queue");
kobject_set_name(&q->kobj, "%s", "queue");
q->kobj.ktype = &queue_ktype;
kobject_init(&q->kobj);
......
......@@ -194,7 +194,7 @@ int acpi_bus_set_power(acpi_handle handle, int state)
if (!device->flags.power_manageable) {
ACPI_DEBUG_PRINT((ACPI_DB_INFO, "Device `[%s]' is not power manageable\n",
device->dev.kobj.name));
kobject_name(&device->dev.kobj)));
return -ENODEV;
}
/*
......
......@@ -319,16 +319,18 @@ static int acpi_bus_match(struct device *dev, struct device_driver *drv)
return !acpi_match_device_ids(acpi_dev, acpi_drv->ids);
}
static int acpi_device_uevent(struct device *dev, char **envp, int num_envp,
char *buffer, int buffer_size)
static int acpi_device_uevent(struct device *dev, struct kobj_uevent_env *env)
{
struct acpi_device *acpi_dev = to_acpi_device(dev);
int len;
strcpy(buffer, "MODALIAS=");
if (create_modalias(acpi_dev, buffer + 9, buffer_size - 9) > 0) {
envp[0] = buffer;
envp[1] = NULL;
}
if (add_uevent_var(env, "MODALIAS="