Sun Microsystems Systems Architecture Committee Subject Filesystem Driven Device Naming Submitted by Yonghong Lai File PSARC/2003/246/opinion.html Date May, 24th, 2006 Committee Shudong Zhou, Ed Gould, Glenn Skinner, William Sommerfeld, Gary Winiger Abstain: James Carlson Steering Committee Operating Systems and Networking 1. Summary This project implements an in-memory filesystem that exports the /dev namespace. Immediate benefits include a reduced need for reconfiguration boot and much simpler implementations of device support in zones and the pseudo terminal subsystem. The project also lays the foundation for centralized naming scheme where devices are named via a name service (LDAP or NIS). 2. Decision & Precedence Information The project is approved as specified in reference [1]. The project may be delivered in a minor release of Solaris. 3. Interfaces Interfaces Exported Interface Name Classification Comment dev Stable filesystem type mount_dev(1M) Consolidation Private mount devname filesystem di_prof_t Consolidation Private opaque handle to a profile di_prof_init Consolidation Private allocate a profile handle di_prof_fini Consolidation Private destroy a profile handle di_prof_add_dev Consolidation Private add a rule for device inclusion di_prof_add_exclude Consolidation Private add a rule for device exclusion di_prof_add_symlink Consolidation Private add a symlink di_prof_add_map Consolidation Private add a name mapping rule di_prof_commit Consolidation Private commit profile to filesystem instance kernel/devname Consolidation Private Devname plug-in module directory 4. Opinion 4.1 Implicit reconfiguration The project aims to eliminate the need for reconfiguration boot by performing reconfiguration on demand (i.e. implicit reconfiguration). The idea is to delay the scan for new devices until the first request for a device name the system hasn't seen so far. Unfortunately, request for non-existing /dev names are common during system startup, some by design and others by accident. A naiive implementation of implicit reconfiguration would result in device scanning on every boot, degrading the boot performance. To avoid the boot performance degradation, a "negative cache" is introduced to remember all non-existing names referenced in past boot sessions. Any boot-time lookup of devices in the negative cache would fail without incurring a scan for new devices. PSARC raised several issues regarding the negative cache, leading to TCRs listed in Appendix A. 4.2 /dev namespace In an interim version of the proposal, the project team reserved a number of /dev subdirectories for follow-on projects. PSARC felt that an overall "naming architecture" is required to judge the merit of name reservations. The project team subsequnently withdrew the namespace reservation. 5. Minority Opinion(s) None. 6. Advisory Information None. Appendices Appendix A: Technical Changes Required 1. There are corner cases where the negative cache hides new devices during system startup. The negative cache must be disabled when an explicit reconfiguration boot (boot -r and /reconfigure) is requested. 2. By design, the negative cache discussed in 4.1 takes effect at boot time. The time at which the negative cache is disabled must be logically tied to an appropriate SMF milestone. 3. The negative cache is likely to grow over time and consume system resources. The implementation must bound the resource consumption to prevent denial of service attacks. Appendix B: Technical Changes Advised None Appendix C: Reference Material Unless otherwise stated, path names are relative to the case directory (PSARC/2003/246) . 1. devname_arc