1
0
Fork 0
alistair23-linux/drivers/base/base.h

155 lines
5.3 KiB
C
Raw Normal View History

#include <linux/notifier.h>
[PATCH] drivers/base - fix sparse warnings There are a number of sparse warnings from the latest sparse snapshot being generated from the drivers/base build. The main culprits are due to the initialisation functions not being declared in a header file. Also, the firmware.c file should include <linux/device.h> to get the prototype of firmware_register() and firmware_unregister(). This patch moves the init function declerations from the init.c file to the base.h, and ensures it is included in all the relevant c sources. It also adds <linux/device.h> to the included headers for firmware.c. The patch does not solve all the sparse errors generated, but reduces the count significantly. drivers/base/core.c:161:1: warning: symbol 'devices_subsys' was not declared. Should it be static? drivers/base/core.c:417:12: warning: symbol 'devices_init' was not declared. Should it be static? drivers/base/sys.c:253:6: warning: symbol 'sysdev_shutdown' was not declared. Should it be static? drivers/base/sys.c:326:5: warning: symbol 'sysdev_suspend' was not declared. Should it be static? drivers/base/sys.c:428:5: warning: symbol 'sysdev_resume' was not declared. Should it be static? drivers/base/sys.c:450:12: warning: symbol 'system_bus_init' was not declared. Should it be static? drivers/base/bus.c:133:1: warning: symbol 'bus_subsys' was not declared. Should it be static? drivers/base/bus.c:667:12: warning: symbol 'buses_init' was not declared. Should it be static? drivers/base/class.c:759:12: warning: symbol 'classes_init' was not declared. Should it be static? drivers/base/platform.c:313:12: warning: symbol 'platform_bus_init' was not declared. Should it be static? drivers/base/cpu.c:110:12: warning: symbol 'cpu_dev_init' was not declared. Should it be static? drivers/base/firmware.c:17:5: warning: symbol 'firmware_register' was not declared. Should it be static? drivers/base/firmware.c:23:6: warning: symbol 'firmware_unregister' was not declared. Should it be static? drivers/base/firmware.c:28:12: warning: symbol 'firmware_init' was not declared. Should it be static? drivers/base/init.c:28:13: warning: symbol 'driver_init' was not declared. Should it be static? drivers/base/dmapool.c:174:10: warning: implicit cast from nocast type drivers/base/attribute_container.c:439:1: warning: symbol 'attribute_container_init' was not declared. Should it be static? drivers/base/power/runtime.c:76:6: warning: symbol 'dpm_set_power_state' was not declared. Should it be static? Signed-off-by: Ben Dooks <ben-linux@fluff.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-10-13 10:54:41 -06:00
/**
* struct subsys_private - structure to hold the private to the driver core portions of the bus_type/class structure.
*
* @subsys - the struct kset that defines this subsystem
* @devices_kset - the subsystem's 'devices' directory
* @interfaces - list of subsystem interfaces associated
* @mutex - protect the devices, and interfaces lists.
*
* @drivers_kset - the list of drivers associated
* @klist_devices - the klist to iterate over the @devices_kset
* @klist_drivers - the klist to iterate over the @drivers_kset
* @bus_notifier - the bus notifier list for anything that cares about things
* on this bus.
* @bus - pointer back to the struct bus_type that this structure is associated
* with.
*
* @glue_dirs - "glue" directory to put in-between the parent device to
* avoid namespace conflicts
* @class - pointer back to the struct class that this structure is associated
* with.
*
* This structure is the one that is the actual kobject allowing struct
* bus_type/class to be statically allocated safely. Nothing outside of the
* driver core should ever touch these fields.
*/
struct subsys_private {
struct kset subsys;
struct kset *devices_kset;
struct list_head interfaces;
struct mutex mutex;
struct kset *drivers_kset;
struct klist klist_devices;
struct klist klist_drivers;
struct blocking_notifier_head bus_notifier;
unsigned int drivers_autoprobe:1;
struct bus_type *bus;
struct kset glue_dirs;
struct class *class;
};
#define to_subsys_private(obj) container_of(obj, struct subsys_private, subsys.kobj)
struct driver_private {
struct kobject kobj;
struct klist klist_devices;
struct klist_node knode_bus;
struct module_kobject *mkobj;
struct device_driver *driver;
};
#define to_driver(obj) container_of(obj, struct driver_private, kobj)
[PATCH] drivers/base - fix sparse warnings There are a number of sparse warnings from the latest sparse snapshot being generated from the drivers/base build. The main culprits are due to the initialisation functions not being declared in a header file. Also, the firmware.c file should include <linux/device.h> to get the prototype of firmware_register() and firmware_unregister(). This patch moves the init function declerations from the init.c file to the base.h, and ensures it is included in all the relevant c sources. It also adds <linux/device.h> to the included headers for firmware.c. The patch does not solve all the sparse errors generated, but reduces the count significantly. drivers/base/core.c:161:1: warning: symbol 'devices_subsys' was not declared. Should it be static? drivers/base/core.c:417:12: warning: symbol 'devices_init' was not declared. Should it be static? drivers/base/sys.c:253:6: warning: symbol 'sysdev_shutdown' was not declared. Should it be static? drivers/base/sys.c:326:5: warning: symbol 'sysdev_suspend' was not declared. Should it be static? drivers/base/sys.c:428:5: warning: symbol 'sysdev_resume' was not declared. Should it be static? drivers/base/sys.c:450:12: warning: symbol 'system_bus_init' was not declared. Should it be static? drivers/base/bus.c:133:1: warning: symbol 'bus_subsys' was not declared. Should it be static? drivers/base/bus.c:667:12: warning: symbol 'buses_init' was not declared. Should it be static? drivers/base/class.c:759:12: warning: symbol 'classes_init' was not declared. Should it be static? drivers/base/platform.c:313:12: warning: symbol 'platform_bus_init' was not declared. Should it be static? drivers/base/cpu.c:110:12: warning: symbol 'cpu_dev_init' was not declared. Should it be static? drivers/base/firmware.c:17:5: warning: symbol 'firmware_register' was not declared. Should it be static? drivers/base/firmware.c:23:6: warning: symbol 'firmware_unregister' was not declared. Should it be static? drivers/base/firmware.c:28:12: warning: symbol 'firmware_init' was not declared. Should it be static? drivers/base/init.c:28:13: warning: symbol 'driver_init' was not declared. Should it be static? drivers/base/dmapool.c:174:10: warning: implicit cast from nocast type drivers/base/attribute_container.c:439:1: warning: symbol 'attribute_container_init' was not declared. Should it be static? drivers/base/power/runtime.c:76:6: warning: symbol 'dpm_set_power_state' was not declared. Should it be static? Signed-off-by: Ben Dooks <ben-linux@fluff.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-10-13 10:54:41 -06:00
/**
* struct device_private - structure to hold the private to the driver core portions of the device structure.
*
* @klist_children - klist containing all children of this device
* @knode_parent - node in sibling list
* @knode_driver - node in driver list
* @knode_bus - node in bus list
* @deferred_probe - entry in deferred_probe_list which is used to retry the
* binding of drivers which were unable to get all the resources needed by
* the device; typically because it depends on another driver getting
* probed first.
* @device - pointer back to the struct device that this structure is
* associated with.
*
* Nothing outside of the driver core should ever touch these fields.
*/
struct device_private {
struct klist klist_children;
struct klist_node knode_parent;
struct klist_node knode_driver;
struct klist_node knode_bus;
struct list_head deferred_probe;
struct device *device;
};
#define to_device_private_parent(obj) \
container_of(obj, struct device_private, knode_parent)
#define to_device_private_driver(obj) \
container_of(obj, struct device_private, knode_driver)
#define to_device_private_bus(obj) \
container_of(obj, struct device_private, knode_bus)
extern int device_private_init(struct device *dev);
/* initialisation functions */
[PATCH] drivers/base - fix sparse warnings There are a number of sparse warnings from the latest sparse snapshot being generated from the drivers/base build. The main culprits are due to the initialisation functions not being declared in a header file. Also, the firmware.c file should include <linux/device.h> to get the prototype of firmware_register() and firmware_unregister(). This patch moves the init function declerations from the init.c file to the base.h, and ensures it is included in all the relevant c sources. It also adds <linux/device.h> to the included headers for firmware.c. The patch does not solve all the sparse errors generated, but reduces the count significantly. drivers/base/core.c:161:1: warning: symbol 'devices_subsys' was not declared. Should it be static? drivers/base/core.c:417:12: warning: symbol 'devices_init' was not declared. Should it be static? drivers/base/sys.c:253:6: warning: symbol 'sysdev_shutdown' was not declared. Should it be static? drivers/base/sys.c:326:5: warning: symbol 'sysdev_suspend' was not declared. Should it be static? drivers/base/sys.c:428:5: warning: symbol 'sysdev_resume' was not declared. Should it be static? drivers/base/sys.c:450:12: warning: symbol 'system_bus_init' was not declared. Should it be static? drivers/base/bus.c:133:1: warning: symbol 'bus_subsys' was not declared. Should it be static? drivers/base/bus.c:667:12: warning: symbol 'buses_init' was not declared. Should it be static? drivers/base/class.c:759:12: warning: symbol 'classes_init' was not declared. Should it be static? drivers/base/platform.c:313:12: warning: symbol 'platform_bus_init' was not declared. Should it be static? drivers/base/cpu.c:110:12: warning: symbol 'cpu_dev_init' was not declared. Should it be static? drivers/base/firmware.c:17:5: warning: symbol 'firmware_register' was not declared. Should it be static? drivers/base/firmware.c:23:6: warning: symbol 'firmware_unregister' was not declared. Should it be static? drivers/base/firmware.c:28:12: warning: symbol 'firmware_init' was not declared. Should it be static? drivers/base/init.c:28:13: warning: symbol 'driver_init' was not declared. Should it be static? drivers/base/dmapool.c:174:10: warning: implicit cast from nocast type drivers/base/attribute_container.c:439:1: warning: symbol 'attribute_container_init' was not declared. Should it be static? drivers/base/power/runtime.c:76:6: warning: symbol 'dpm_set_power_state' was not declared. Should it be static? Signed-off-by: Ben Dooks <ben-linux@fluff.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-10-13 10:54:41 -06:00
extern int devices_init(void);
extern int buses_init(void);
extern int classes_init(void);
extern int firmware_init(void);
#ifdef CONFIG_SYS_HYPERVISOR
extern int hypervisor_init(void);
#else
static inline int hypervisor_init(void) { return 0; }
#endif
[PATCH] drivers/base - fix sparse warnings There are a number of sparse warnings from the latest sparse snapshot being generated from the drivers/base build. The main culprits are due to the initialisation functions not being declared in a header file. Also, the firmware.c file should include <linux/device.h> to get the prototype of firmware_register() and firmware_unregister(). This patch moves the init function declerations from the init.c file to the base.h, and ensures it is included in all the relevant c sources. It also adds <linux/device.h> to the included headers for firmware.c. The patch does not solve all the sparse errors generated, but reduces the count significantly. drivers/base/core.c:161:1: warning: symbol 'devices_subsys' was not declared. Should it be static? drivers/base/core.c:417:12: warning: symbol 'devices_init' was not declared. Should it be static? drivers/base/sys.c:253:6: warning: symbol 'sysdev_shutdown' was not declared. Should it be static? drivers/base/sys.c:326:5: warning: symbol 'sysdev_suspend' was not declared. Should it be static? drivers/base/sys.c:428:5: warning: symbol 'sysdev_resume' was not declared. Should it be static? drivers/base/sys.c:450:12: warning: symbol 'system_bus_init' was not declared. Should it be static? drivers/base/bus.c:133:1: warning: symbol 'bus_subsys' was not declared. Should it be static? drivers/base/bus.c:667:12: warning: symbol 'buses_init' was not declared. Should it be static? drivers/base/class.c:759:12: warning: symbol 'classes_init' was not declared. Should it be static? drivers/base/platform.c:313:12: warning: symbol 'platform_bus_init' was not declared. Should it be static? drivers/base/cpu.c:110:12: warning: symbol 'cpu_dev_init' was not declared. Should it be static? drivers/base/firmware.c:17:5: warning: symbol 'firmware_register' was not declared. Should it be static? drivers/base/firmware.c:23:6: warning: symbol 'firmware_unregister' was not declared. Should it be static? drivers/base/firmware.c:28:12: warning: symbol 'firmware_init' was not declared. Should it be static? drivers/base/init.c:28:13: warning: symbol 'driver_init' was not declared. Should it be static? drivers/base/dmapool.c:174:10: warning: implicit cast from nocast type drivers/base/attribute_container.c:439:1: warning: symbol 'attribute_container_init' was not declared. Should it be static? drivers/base/power/runtime.c:76:6: warning: symbol 'dpm_set_power_state' was not declared. Should it be static? Signed-off-by: Ben Dooks <ben-linux@fluff.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-10-13 10:54:41 -06:00
extern int platform_bus_init(void);
extern void cpu_dev_init(void);
ACPI / hotplug / driver core: Handle containers in a special way ACPI container devices require special hotplug handling, at least on some systems, since generally user space needs to carry out system-specific cleanup before it makes sense to offline devices in the container. However, the current ACPI hotplug code for containers first attempts to offline devices in the container and only then it notifies user space of the container offline. Moreover, after commit 202317a573b2 (ACPI / scan: Add acpi_device objects for all device nodes in the namespace), ACPI device objects representing containers are present as long as the ACPI namespace nodes corresponding to them are present, which may be forever, even if the container devices are physically detached from the system (the return values of the corresponding _STA methods change in those cases, but generally the namespace nodes themselves are still there). Thus it is useful to introduce entities representing containers that will go away during container hot-unplug. The goal of this change is to address both the above issues. The idea is to create a "companion" container system device for each of the ACPI container device objects during the initial namespace scan or on a hotplug event making the container present. That system device will be unregistered on container removal. A new bus type for container devices is added for this purpose, because device offline and online operations need to be defined for them. The online operation is a trivial function that is always successful and the offline uses a callback pointed to by the container device's offline member. For ACPI containers that callback simply walks the list of ACPI device objects right below the container object (its children) and checks if all of their physical companion devices are offline. If that's not the case, it returns -EBUSY and the container system devivce cannot be put offline. Consequently, to put the container system device offline, it is necessary to put all of the physical devices depending on its ACPI companion object offline beforehand. Container system devices created for ACPI container objects are initially online. They are created by the container ACPI scan handler whose hotplug.demand_offline flag is set. That causes acpi_scan_hot_remove() to check if the companion container system device is offline before attempting to remove an ACPI container or any devices below it. If the check fails, a KOBJ_CHANGE uevent is emitted for the container system device in question and user space is expected to offline all devices below the container and the container itself in response to it. Then, user space can finalize the removal of the container with the help of its ACPI device object's eject attribute in sysfs. Tested-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-12-29 07:25:48 -07:00
extern void container_dev_init(void);
[PATCH] drivers/base - fix sparse warnings There are a number of sparse warnings from the latest sparse snapshot being generated from the drivers/base build. The main culprits are due to the initialisation functions not being declared in a header file. Also, the firmware.c file should include <linux/device.h> to get the prototype of firmware_register() and firmware_unregister(). This patch moves the init function declerations from the init.c file to the base.h, and ensures it is included in all the relevant c sources. It also adds <linux/device.h> to the included headers for firmware.c. The patch does not solve all the sparse errors generated, but reduces the count significantly. drivers/base/core.c:161:1: warning: symbol 'devices_subsys' was not declared. Should it be static? drivers/base/core.c:417:12: warning: symbol 'devices_init' was not declared. Should it be static? drivers/base/sys.c:253:6: warning: symbol 'sysdev_shutdown' was not declared. Should it be static? drivers/base/sys.c:326:5: warning: symbol 'sysdev_suspend' was not declared. Should it be static? drivers/base/sys.c:428:5: warning: symbol 'sysdev_resume' was not declared. Should it be static? drivers/base/sys.c:450:12: warning: symbol 'system_bus_init' was not declared. Should it be static? drivers/base/bus.c:133:1: warning: symbol 'bus_subsys' was not declared. Should it be static? drivers/base/bus.c:667:12: warning: symbol 'buses_init' was not declared. Should it be static? drivers/base/class.c:759:12: warning: symbol 'classes_init' was not declared. Should it be static? drivers/base/platform.c:313:12: warning: symbol 'platform_bus_init' was not declared. Should it be static? drivers/base/cpu.c:110:12: warning: symbol 'cpu_dev_init' was not declared. Should it be static? drivers/base/firmware.c:17:5: warning: symbol 'firmware_register' was not declared. Should it be static? drivers/base/firmware.c:23:6: warning: symbol 'firmware_unregister' was not declared. Should it be static? drivers/base/firmware.c:28:12: warning: symbol 'firmware_init' was not declared. Should it be static? drivers/base/init.c:28:13: warning: symbol 'driver_init' was not declared. Should it be static? drivers/base/dmapool.c:174:10: warning: implicit cast from nocast type drivers/base/attribute_container.c:439:1: warning: symbol 'attribute_container_init' was not declared. Should it be static? drivers/base/power/runtime.c:76:6: warning: symbol 'dpm_set_power_state' was not declared. Should it be static? Signed-off-by: Ben Dooks <ben-linux@fluff.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-10-13 10:54:41 -06:00
struct kobject *virtual_device_parent(struct device *dev);
extern int bus_add_device(struct device *dev);
extern void bus_probe_device(struct device *dev);
extern void bus_remove_device(struct device *dev);
extern int bus_add_driver(struct device_driver *drv);
extern void bus_remove_driver(struct device_driver *drv);
extern void driver_detach(struct device_driver *drv);
extern int driver_probe_device(struct device_driver *drv, struct device *dev);
drivercore: Add driver probe deferral mechanism Allow drivers to report at probe time that they cannot get all the resources required by the device, and should be retried at a later time. This should completely solve the problem of getting devices initialized in the right order. Right now this is mostly handled by mucking about with initcall ordering which is a complete hack, and doesn't even remotely handle the case where device drivers are in modules. This approach completely sidesteps the issues by allowing driver registration to occur in any order, and any driver can request to be retried after a few more other drivers get probed. v4: - Integrate Manjunath's addition of a separate workqueue - Change -EAGAIN to -EPROBE_DEFER for drivers to trigger deferral - Update comment blocks to reflect how the code really works v3: - Hold off workqueue scheduling until late_initcall so that the bulk of driver probes are complete before we start retrying deferred devices. - Tested with simple use cases. Still needs more testing though. Using it to get rid of the gpio early_initcall madness, or to replace the ASoC internal probe deferral code would be ideal. v2: - added locking so it should no longer be utterly broken in that regard - remove device from deferred list at device_del time. - Still completely untested with any real use case, but has been boot tested. Signed-off-by: Grant Likely <grant.likely@secretlab.ca> Cc: Mark Brown <broonie@opensource.wolfsonmicro.com> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Dilan Lee <dilee@nvidia.com> Cc: Manjunath GKondaiah <manjunath.gkondaiah@linaro.org> Cc: Alan Stern <stern@rowland.harvard.edu> Cc: Tony Lindgren <tony@atomide.com> Cc: Alan Cox <alan@lxorguk.ukuu.org.uk> Reviewed-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Acked-by: David Daney <david.daney@cavium.com> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-03-05 08:47:41 -07:00
extern void driver_deferred_probe_del(struct device *dev);
static inline int driver_match_device(struct device_driver *drv,
struct device *dev)
{
return drv->bus->match ? drv->bus->match(dev, drv) : 1;
}
extern bool driver_allows_async_probing(struct device_driver *drv);
extern int driver_add_groups(struct device_driver *drv,
const struct attribute_group **groups);
extern void driver_remove_groups(struct device_driver *drv,
const struct attribute_group **groups);
extern int device_add_groups(struct device *dev,
const struct attribute_group **groups);
extern void device_remove_groups(struct device *dev,
const struct attribute_group **groups);
extern char *make_class_name(const char *name, struct kobject *kobj);
extern int devres_release_all(struct device *dev);
extern void device_block_probing(void);
extern void device_unblock_probing(void);
/* /sys/devices directory */
extern struct kset *devices_kset;
driver core: correct device's shutdown order Now device's shutdown sequence is performed in reverse order of their registration in devices_kset list and this sequence corresponds to the reverse device's creation order. So, devices_kset data tracks "parent<-child" device's dependencies only. Unfortunately, that's not enough and causes problems in case of implementing board's specific shutdown procedures. For example [1]: "DRA7XX_evm uses PCF8575 and one of the PCF output lines feeds to MMC/SD and this line should be driven high in order for the MMC/SD to be detected. This line is modelled as regulator and the hsmmc driver takes care of enabling and disabling it. In the case of 'reboot', during shutdown path as part of it's cleanup process the hsmmc driver disables this regulator. This makes MMC boot not functional." To handle this issue the .shutdown() callback could be implemented for PCF8575 device where corresponding GPIO pins will be configured to states, required for correct warm/cold reset. This can be achieved only when all .shutdown() callbacks have been called already for all PCF8575's consumers. But devices_kset is not filled correctly now: devices_kset: Device61 4e000000.dmm devices_kset: Device62 48070000.i2c devices_kset: Device63 48072000.i2c devices_kset: Device64 48060000.i2c devices_kset: Device65 4809c000.mmc ... devices_kset: Device102 fixedregulator-sd ... devices_kset: Device181 0-0020 // PCF8575 devices_kset: Device182 gpiochip496 devices_kset: Device183 0-0021 // PCF8575 devices_kset: Device184 gpiochip480 As can be seen from above .shutdown() callback for PCF8575 will be called before its consumers, which, in turn means, that any changes of PCF8575 GPIO's pins will be or unsafe or overwritten later by GPIO's consumers. The problem can be solved if devices_kset list will be filled not only according device creation order, but also according device's probing order to track "supplier<-consumer" dependencies also. Hence, as a fix, lets add devices_kset_move_last(), devices_kset_move_before(), devices_kset_move_after() and call them from device_move() and also add call of devices_kset_move_last() in really_probe(). After this change all entries in devices_kset will be sorted according to device's creation ("parent<-child") and probing ("supplier<-consumer") order. devices_kset after: devices_kset: Device121 48070000.i2c devices_kset: Device122 i2c-0 ... devices_kset: Device147 regulator.24 devices_kset: Device148 0-0020 devices_kset: Device149 gpiochip496 devices_kset: Device150 0-0021 devices_kset: Device151 gpiochip480 devices_kset: Device152 0-0019 ... devices_kset: Device372 fixedregulator-sd devices_kset: Device373 regulator.29 devices_kset: Device374 4809c000.mmc devices_kset: Device375 mmc0 [1] http://www.spinics.net/lists/linux-mmc/msg29825.html Cc: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-07-27 11:43:01 -06:00
extern void devices_kset_move_last(struct device *dev);
#if defined(CONFIG_MODULES) && defined(CONFIG_SYSFS)
extern void module_add_driver(struct module *mod, struct device_driver *drv);
extern void module_remove_driver(struct device_driver *drv);
#else
static inline void module_add_driver(struct module *mod,
struct device_driver *drv) { }
static inline void module_remove_driver(struct device_driver *drv) { }
#endif
Driver Core: devtmpfs - kernel-maintained tmpfs-based /dev Devtmpfs lets the kernel create a tmpfs instance called devtmpfs very early at kernel initialization, before any driver-core device is registered. Every device with a major/minor will provide a device node in devtmpfs. Devtmpfs can be changed and altered by userspace at any time, and in any way needed - just like today's udev-mounted tmpfs. Unmodified udev versions will run just fine on top of it, and will recognize an already existing kernel-created device node and use it. The default node permissions are root:root 0600. Proper permissions and user/group ownership, meaningful symlinks, all other policy still needs to be applied by userspace. If a node is created by devtmps, devtmpfs will remove the device node when the device goes away. If the device node was created by userspace, or the devtmpfs created node was replaced by userspace, it will no longer be removed by devtmpfs. If it is requested to auto-mount it, it makes init=/bin/sh work without any further userspace support. /dev will be fully populated and dynamic, and always reflect the current device state of the kernel. With the commonly used dynamic device numbers, it solves the problem where static devices nodes may point to the wrong devices. It is intended to make the initial bootup logic simpler and more robust, by de-coupling the creation of the inital environment, to reliably run userspace processes, from a complex userspace bootstrap logic to provide a working /dev. Signed-off-by: Kay Sievers <kay.sievers@vrfy.org> Signed-off-by: Jan Blunck <jblunck@suse.de> Tested-By: Harald Hoyer <harald@redhat.com> Tested-By: Scott James Remnant <scott@ubuntu.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 07:23:42 -06:00
#ifdef CONFIG_DEVTMPFS
extern int devtmpfs_init(void);
#else
static inline int devtmpfs_init(void) { return 0; }
#endif