/proc/sys/kernel/hotplug  怎么会是下面这样的  vi 打开怎么是个空文件

-rw-r--r--    1 root     root            0 Jan  1 00:14 hotplug 

是否表示内核不支持 hotplug 

另外想问下 -rw-r--r-- 第一个-是表示什么意思 好像这个位置还可以是 l ， b？

另外想问下 -rw-r--r-- 第一个-是表示什么意思 好像这个位置还可以是 l ， b？

-表示普通文件
d   目录
l   链接
b   块设备
c   字符设备

查看设备可以通过 fdisk -l

2.6.15内核之后，/proc/sys/kernel/hotplug会成空的，因为内核通知用户空间的接口变成了netlink，所以最新的udev也采用了netlink接口去写，废弃了/sbin/hotplug或者/sbin/udevsend。udev在2.6.15以后的内核上可以直接通过netlink接听设备事件，sysfs提供了uevent文件，对该文件的“写”可以送出设备事件！

http://www.cublog.cn/u2/66024/showart_1275273.html

There is nothing wrong with it. If /proc/sys/kernel/hotplug is not
set (empty string), the kernel records the journal of hotplug events.
This enables the kernel to replay events after reboots. The problem
ist that there are some races between /sbin/hotplug and the
initscripts when handling cold plugs. It happens if the initscripts
assume the presence of some device. The other problem is that we need
initscript to run "lost" hotplugs.

If /sbin/hotplug is not "ready" (for any reason, but we assume it may
be not ready before something special happens in system
initialization, i.e., some fs is mounted), the hotplug event is lost.
From the other side, assuming that /sbin/hotplug is always "ready"
doesn't seem to be a good idea. It is known that forking a lot of
hotplugs is not good. Serializing helps but is unacceptable in kernel
(but ok in initscripts).

After an 'echo "/sbin/hotplug" > /proc/sys/kernel/hotplug' (or any
other modifying of /proc/... file) the recording is stopped and
performed by the specified program to notify user mode applications.