- Linux allocated devices (4.x+ version)В¶
- Additional /dev/ directory entries¶
- Compulsory links¶
- Recommended links¶
- Locally defined links¶
- Sockets and pipes¶
- Mount points¶
- Terminal devices¶
- Virtual consoles and the console device¶
- Serial ports¶
- Pseudoterminals (PTYs)В¶
- The Linux Hardware Monitoring kernel API¶
- Introduction¶
- The API¶
- Using devm_hwmon_device_register_with_info()В¶
- 3. x86 Feature Flags¶
- 3.1. Introduction¶
- 3.2. How are feature flags created?В¶
- 3.2.1. a: Feature flags can be derived from the contents of CPUID leaves.В¶
- 3.2.2. b: Flags can be from scattered CPUID-based features.В¶
- 3.2.3. c: Flags can be created synthetically under certain conditions for hardware features.В¶
- 3.2.4. d: Flags can represent purely software features.В¶
- 3.3. Naming of Flags¶
- 3.3.1. a: The name of the flag is from the string in X86_FEATURE_ by default.В¶
- 3.3.2. b: The naming can be overridden.В¶
- 3.3.3. c: The naming override can be “”, which means it will not appear in /proc/cpuinfo.¶
- 3.4. Flags are missing when one or more of these happen¶
- 3.4.1. a: The hardware does not enumerate support for it.В¶
- 3.4.2. b: The kernel does not know about the flag.В¶
- 3.4.3. c: The kernel disabled support for it at compile-time.В¶
- 3.4.4. d: The feature is disabled at boot-time.В¶
- 3.4.5. e: The feature was known to be non-functional.В¶
Linux allocated devices (4.x+ version)В¶
This list is the Linux Device List, the official registry of allocated device numbers and /dev directory nodes for the Linux operating system.
This document is included by reference into the Filesystem Hierarchy Standard (FHS). The FHS is available from https://www.pathname.com/fhs/.
Allocations marked (68k/Amiga) apply to Linux/68k on the Amiga platform only. Allocations marked (68k/Atari) apply to Linux/68k on the Atari platform only.
This document is in the public domain. The authors requests, however, that semantically altered versions are not distributed without permission of the authors, assuming the authors can be contacted without an unreasonable effort.
DEVICE DRIVERS AUTHORS PLEASE READ THIS
Linux now has extensive support for dynamic allocation of device numbering and can use sysfs and udev ( systemd ) to handle the naming needs. There are still some exceptions in the serial and boot device area. Before asking for a device number make sure you actually need one.
To have a major number allocated, or a minor number in situations where that applies (e.g. busmice), please submit a patch and send to the authors as indicated above.
Keep the description of the device in the same format as this list. The reason for this is that it is the only way we have found to ensure we have all the requisite information to publish your device and avoid conflicts.
Finally, sometimes we have to play “namespace police.” Please don’t be offended. We often get submissions for /dev names that would be bound to cause conflicts down the road. We are trying to avoid getting in a situation where we would have to suffer an incompatible forward change. Therefore, please consult with us before you make your device names and numbers in any way public, at least to the point where it would be at all difficult to get them changed.
Your cooperation is appreciated.
Additional /dev/ directory entries¶
This section details additional entries that should or may exist in the /dev directory. It is preferred that symbolic links use the same form (absolute or relative) as is indicated here. Links are classified as “hard” or “symbolic” depending on the preferred type of link; if possible, the indicated type of link should be used.
Compulsory links¶
These links should exist on all systems:
stdin file descriptor
stdout file descriptor
stderr file descriptor
Required by iBCS-2
Required by iBCS-2
Recommended links¶
It is recommended that these links exist on all systems:
Alternate SCSI CD-ROM name
Locally defined links¶
The following links may be established locally to conform to the configuration of the system. This is merely a tabulation of existing practice, and does not constitute a recommendation. However, if they exist, they should have the following uses.
Current mouse device
Current tape device
Current CD-ROM device
Current CD-writer device
Current scanner device
Current dialout device
Current root filesystem
Current swap device
/dev/modem should not be used for a modem which supports dialin as well as dialout, as it tends to cause lock file problems. If it exists, /dev/modem should point to the appropriate primary TTY device (the use of the alternate callout devices is deprecated).
For SCSI devices, /dev/tape and /dev/cdrom should point to the cooked devices ( /dev/st* and /dev/sr* , respectively), whereas /dev/cdwriter and /dev/scanner should point to the appropriate generic SCSI devices (/dev/sg*).
/dev/mouse may point to a primary serial TTY device, a hardware mouse device, or a socket for a mouse driver program (e.g. /dev/gpmdata ).
Sockets and pipes¶
Non-transient sockets and named pipes may exist in /dev. Common entries are:
lpd local socket
syslog local socket
gpm mouse multiplexer
Mount points¶
The following names are reserved for mounting special filesystems under /dev. These special filesystems provide kernel interfaces that cannot be provided with standard device nodes.
PTY slave filesystem
POSIX shared memory maintenance access
Terminal devices¶
Terminal, or TTY devices are a special class of character devices. A terminal device is any device that could act as a controlling terminal for a session; this includes virtual consoles, serial ports, and pseudoterminals (PTYs).
All terminal devices share a common set of capabilities known as line disciplines; these include the common terminal line discipline as well as SLIP and PPP modes.
All terminal devices are named similarly; this section explains the naming and use of the various types of TTYs. Note that the naming conventions include several historical warts; some of these are Linux-specific, some were inherited from other systems, and some reflect Linux outgrowing a borrowed convention.
A hash mark ( # ) in a device name is used here to indicate a decimal number without leading zeroes.
Virtual consoles and the console device¶
Virtual consoles are full-screen terminal displays on the system video monitor. Virtual consoles are named /dev/tty# , with numbering starting at /dev/tty1 ; /dev/tty0 is the current virtual console. /dev/tty0 is the device that should be used to access the system video card on those architectures for which the frame buffer devices ( /dev/fb* ) are not applicable. Do not use /dev/console for this purpose.
The console device, /dev/console , is the device to which system messages should be sent, and on which logins should be permitted in single-user mode. Starting with Linux 2.1.71, /dev/console is managed by the kernel; for previous versions it should be a symbolic link to either /dev/tty0 , a specific virtual console such as /dev/tty1 , or to a serial port primary ( tty* , not cu* ) device, depending on the configuration of the system.
Serial ports¶
Serial ports are RS-232 serial ports and any device which simulates one, either in hardware (such as internal modems) or in software (such as the ISDN driver.) Under Linux, each serial ports has two device names, the primary or callin device and the alternate or callout one. Each kind of device is indicated by a different letter. For any letter X, the names of the devices are /dev/ttyX# and /dev/cux# , respectively; for historical reasons, /dev/ttyS# and /dev/ttyC# correspond to /dev/cua# and /dev/cub# . In the future, it should be expected that multiple letters will be used; all letters will be upper case for the “tty” device (e.g. /dev/ttyDP# ) and lower case for the “cu” device (e.g. /dev/cudp# ).
The names /dev/ttyQ# and /dev/cuq# are reserved for local use.
The alternate devices provide for kernel-based exclusion and somewhat different defaults than the primary devices. Their main purpose is to allow the use of serial ports with programs with no inherent or broken support for serial ports. Their use is deprecated, and they may be removed from a future version of Linux.
Arbitration of serial ports is provided by the use of lock files with the names /var/lock/LCK..ttyX# . The contents of the lock file should be the PID of the locking process as an ASCII number.
It is common practice to install links such as /dev/modem which point to serial ports. In order to ensure proper locking in the presence of these links, it is recommended that software chase symlinks and lock all possible names; additionally, it is recommended that a lock file be installed with the corresponding alternate device. In order to avoid deadlocks, it is recommended that the locks are acquired in the following order, and released in the reverse:
The symbolic link name, if any ( /var/lock/LCK..modem )
The “tty” name ( /var/lock/LCK..ttyS2 )
The alternate device name ( /var/lock/LCK..cua2 )
In the case of nested symbolic links, the lock files should be installed in the order the symlinks are resolved.
Under no circumstances should an application hold a lock while waiting for another to be released. In addition, applications which attempt to create lock files for the corresponding alternate device names should take into account the possibility of being used on a non-serial port TTY, for which no alternate device would exist.
Pseudoterminals (PTYs)В¶
Pseudoterminals, or PTYs, are used to create login sessions or provide other capabilities requiring a TTY line discipline (including SLIP or PPP capability) to arbitrary data-generation processes. Each PTY has a master side, named /dev/pty[p-za-e][0-9a-f] , and a slave side, named /dev/tty[p-za-e][0-9a-f] . The kernel arbitrates the use of PTYs by allowing each master side to be opened only once.
Once the master side has been opened, the corresponding slave device can be used in the same manner as any TTY device. The master and slave devices are connected by the kernel, generating the equivalent of a bidirectional pipe with TTY capabilities.
Recent versions of the Linux kernels and GNU libc contain support for the System V/Unix98 naming scheme for PTYs, which assigns a common device, /dev/ptmx , to all the masters (opening it will automatically give you a previously unassigned PTY) and a subdirectory, /dev/pts , for the slaves; the slaves are named with decimal integers ( /dev/pts/# in our notation). This removes the problem of exhausting the namespace and enables the kernel to automatically create the device nodes for the slaves on demand using the “devpts” filesystem.
© Copyright The kernel development community.
Источник
The Linux Hardware Monitoring kernel API¶
Introduction¶
This document describes the API that can be used by hardware monitoring drivers that want to use the hardware monitoring framework.
This document does not describe what a hardware monitoring (hwmon) Driver or Device is. It also does not describe the API which can be used by user space to communicate with a hardware monitoring device. If you want to know this then please read the following file: Naming and data format standards for sysfs files .
For additional guidelines on how to write and improve hwmon drivers, please also read How to Get Your Patch Accepted Into the Hwmon Subsystem .
The API¶
Each hardware monitoring driver must #include
hwmon_device_register_with_groups registers a hardware monitoring device. The first parameter of this function is a pointer to the parent device. The name parameter is a pointer to the hwmon device name. The registration function wil create a name sysfs attribute pointing to this name. The drvdata parameter is the pointer to the local driver data. hwmon_device_register_with_groups will attach this pointer to the newly allocated hwmon device. The pointer can be retrieved by the driver using dev_get_drvdata() on the hwmon device pointer. The groups parameter is a pointer to a list of sysfs attribute groups. The list must be NULL terminated. hwmon_device_register_with_groups creates the hwmon device with name attribute as well as all sysfs attributes attached to the hwmon device. This function returns a pointer to the newly created hardware monitoring device or PTR_ERR for failure.
devm_hwmon_device_register_with_groups is similar to hwmon_device_register_with_groups. However, it is device managed, meaning the hwmon device does not have to be removed explicitly by the removal function.
hwmon_device_register_with_info is the most comprehensive and preferred means to register a hardware monitoring device. It creates the standard sysfs attributes in the hardware monitoring core, letting the driver focus on reading from and writing to the chip instead of having to bother with sysfs attributes. The parent device parameter cannot be NULL with non-NULL chip info. Its parameters are described in more detail below.
devm_hwmon_device_register_with_info is similar to hwmon_device_register_with_info. However, it is device managed, meaning the hwmon device does not have to be removed explicitly by the removal function.
hwmon_device_unregister deregisters a registered hardware monitoring device. The parameter of this function is the pointer to the registered hardware monitoring device structure. This function must be called from the driver remove function if the hardware monitoring device was registered with hwmon_device_register_with_groups or hwmon_device_register_with_info.
devm_hwmon_device_unregister does not normally have to be called. It is only needed for error handling, and only needed if the driver probe fails after the call to devm_hwmon_device_register_with_groups or hwmon_device_register_with_info and if the automatic (device managed) removal would be too late.
All supported hwmon device registration functions only accept valid device names. Device names including invalid characters (whitespace, вЂ*’, or вЂ-вЂ) will be rejected. The вЂname’ parameter is mandatory.
Using devm_hwmon_device_register_with_info()В¶
hwmon_device_register_with_info() registers a hardware monitoring device. The parameters to this function are
Источник
3. x86 Feature Flags¶
3.1. Introduction¶
On x86, flags appearing in /proc/cpuinfo have an X86_FEATURE definition in arch/x86/include/asm/cpufeatures.h. If the kernel cares about a feature or KVM want to expose the feature to a KVM guest, it can and should have an X86_FEATURE_* defined. These flags represent hardware features as well as software features.
If users want to know if a feature is available on a given system, they try to find the flag in /proc/cpuinfo. If a given flag is present, it means that the kernel supports it and is currently making it available. If such flag represents a hardware feature, it also means that the hardware supports it.
If the expected flag does not appear in /proc/cpuinfo, things are murkier. Users need to find out the reason why the flag is missing and find the way how to enable it, which is not always easy. There are several factors that can explain missing flags: the expected feature failed to enable, the feature is missing in hardware, platform firmware did not enable it, the feature is disabled at build or run time, an old kernel is in use, or the kernel does not support the feature and thus has not enabled it. In general, /proc/cpuinfo shows features which the kernel supports. For a full list of CPUID flags which the CPU supports, use tools/arch/x86/kcpuid.
3.2. How are feature flags created?В¶
3.2.1. a: Feature flags can be derived from the contents of CPUID leaves.В¶
These feature definitions are organized mirroring the layout of CPUID leaves and grouped in words with offsets as mapped in enum cpuid_leafs in cpufeatures.h (see arch/x86/include/asm/cpufeatures.h for details). If a feature is defined with a X86_FEATURE_ definition in cpufeatures.h, and if it is detected at run time, the flags will be displayed accordingly in /proc/cpuinfo. For example, the flag “avx2” comes from X86_FEATURE_AVX2 in cpufeatures.h.
3.2.2. b: Flags can be from scattered CPUID-based features.В¶
Hardware features enumerated in sparsely populated CPUID leaves get software-defined values. Still, CPUID needs to be queried to determine if a given feature is present. This is done in init_scattered_cpuid_features(). For instance, X86_FEATURE_CQM_LLC is defined as 11*32 + 0 and its presence is checked at runtime in the respective CPUID leaf [EAX=f, ECX=0] bit EDX[1].
The intent of scattering CPUID leaves is to not bloat struct cpuinfo_x86.x86_capability[] unnecessarily. For instance, the CPUID leaf [EAX=7, ECX=0] has 30 features and is dense, but the CPUID leaf [EAX=7, EAX=1] has only one feature and would waste 31 bits of space in the x86_capability[] array. Since there is a struct cpuinfo_x86 for each possible CPU, the wasted memory is not trivial.
3.2.3. c: Flags can be created synthetically under certain conditions for hardware features.В¶
Examples of conditions include whether certain features are present in MSR_IA32_CORE_CAPS or specific CPU models are identified. If the needed conditions are met, the features are enabled by the set_cpu_cap or setup_force_cpu_cap macros. For example, if bit 5 is set in MSR_IA32_CORE_CAPS, the feature X86_FEATURE_SPLIT_LOCK_DETECT will be enabled and “split_lock_detect” will be displayed. The flag “ring3mwait” will be displayed only when running on INTEL_FAM6_XEON_PHI_[KNL|KNM] processors.
3.2.4. d: Flags can represent purely software features.В¶
These flags do not represent hardware features. Instead, they represent a software feature implemented in the kernel. For example, Kernel Page Table Isolation is purely software feature and its feature flag X86_FEATURE_PTI is also defined in cpufeatures.h.
3.3. Naming of Flags¶
The script arch/x86/kernel/cpu/mkcapflags.sh processes the #define X86_FEATURE_ from cpufeatures.h and generates the x86_cap/bug_flags[] arrays in kernel/cpu/capflags.c. The names in the resulting x86_cap/bug_flags[] are used to populate /proc/cpuinfo. The naming of flags in the x86_cap/bug_flags[] are as follows:
3.3.1. a: The name of the flag is from the string in X86_FEATURE_ by default.В¶
By default, the flag in /proc/cpuinfo is extracted from the respective X86_FEATURE_ in cpufeatures.h. For example, the flag “avx2” is from X86_FEATURE_AVX2.
3.3.2. b: The naming can be overridden.В¶
If the comment on the line for the #define X86_FEATURE_* starts with a double-quote character (“”), the string inside the double-quote characters will be the name of the flags. For example, the flag “sse4_1” comes from the comment “sse4_1” following the X86_FEATURE_XMM4_1 definition.
There are situations in which overriding the displayed name of the flag is needed. For instance, /proc/cpuinfo is a userspace interface and must remain constant. If, for some reason, the naming of X86_FEATURE_ changes, one shall override the new naming with the name already used in /proc/cpuinfo.
3.3.3. c: The naming override can be “”, which means it will not appear in /proc/cpuinfo.¶
The feature shall be omitted from /proc/cpuinfo if it does not make sense for the feature to be exposed to userspace. For example, X86_FEATURE_ALWAYS is defined in cpufeatures.h but that flag is an internal kernel feature used in the alternative runtime patching functionality. So, its name is overridden with “”. Its flag will not appear in /proc/cpuinfo.
3.4. Flags are missing when one or more of these happen¶
3.4.1. a: The hardware does not enumerate support for it.В¶
For example, when a new kernel is running on old hardware or the feature is not enabled by boot firmware. Even if the hardware is new, there might be a problem enabling the feature at run time, the flag will not be displayed.
3.4.2. b: The kernel does not know about the flag.В¶
For example, when an old kernel is running on new hardware.
3.4.3. c: The kernel disabled support for it at compile-time.В¶
For example, if 5-level-paging is not enabled when building (i.e., CONFIG_X86_5LEVEL is not selected) the flag “la57” will not show up 1. Even though the feature will still be detected via CPUID, the kernel disables it by clearing via setup_clear_cpu_cap(X86_FEATURE_LA57).
3.4.4. d: The feature is disabled at boot-time.В¶
A feature can be disabled either using a command-line parameter or because it failed to be enabled. The command-line parameter clearcpuid= can be used to disable features using the feature number as defined in /arch/x86/include/asm/cpufeatures.h. For instance, User Mode Instruction Protection can be disabled using clearcpuid=514. The number 514 is calculated from #define X86_FEATURE_UMIP (16*32 + 2).
In addition, there exists a variety of custom command-line parameters that disable specific features. The list of parameters includes, but is not limited to, nofsgsbase, nosmap, and nosmep. 5-level paging can also be disabled using “no5lvl”. SMAP and SMEP are disabled with the aforementioned parameters, respectively.
3.4.5. e: The feature was known to be non-functional.В¶
The feature was known to be non-functional because a dependency was missing at runtime. For example, AVX flags will not show up if XSAVE feature is disabled since they depend on XSAVE feature. Another example would be broken CPUs and them missing microcode patches. Due to that, the kernel decides not to enable a feature.
5-level paging uses linear address of 57 bits.
© Copyright The kernel development community.
Источник
