1 Directory Description

Directory Description **bin**Essential command binaries Binary program of basic commands available to all users **boot**Static files of the boot load...
Directory Description
**bin**Essential command binaries Binary program of basic commands available to all users **boot**Static files of the boot loader The static files that the boot loader must use, kernel initramfs(initrd),grub And so on. **dev**Device files There are two types of devices for storing special files or device files: block device (random device) and character device (linear device) //Hard disk, hard disk partition, usb flash disk / dev/sd[a-p] Digital 25 Needle printer /dev/lp[0-2] usb Interface printer /dev/usb/lp[0-15] //Floppy disk / dev/fd[0-7] VirtI/O Interface /dev/vd[a-p] //Mouse / dev/input/mouse[0-15] (general) CDROM/DVDROM /dev/scd[0-1] /dev/sr[0-1] /dev/cdrom //Drive / dev/ht0 IDE interface /dev/sr0 SATA/SCSI Interface /dev/tape current tape **etc** Host-specific system configuration System program configuration file, not binary **home** The centralized location of the home directory of ordinary users. Generally, the home directory of each user is a subdirectory with the same name as the user under the directory by default, /home/$USER **root** Home directory for the root user (optional) Administrator's home directory, optional. You should log in with a normal user. **lib** Essential shared libraries and kernel modules Basic shared libraries and kernel modules are used to start or follow applications on the file system(/bin,/sbin Provide shared libraries and kernel modules for the kernel libc.so.* the dynamically-linked C library dynamic link c library ld* the execution time linker/loader Runtime linker, loader **/lib: ** Required directory or soft link: mldules loadable kernal modules Loadable kernel module **lib64:** 64 Special path for storing 64 bit shared library in 32-bit system lib lower **media: ** Mount point for removeable media Mobile, portable device mount point **mnt: ** Mount point for mounting a filesystem temporarily Temporary mount points for other file systems **opt: ** Add-on application software packages Installation location of additional application package, optional **sbin: ** Essential system binaries Basic system management binary **srv: ** Data for services provided by this system Data of services provided by the system **tmp: ** Temporary files A directory for storing temporary files generated by a program. All users of this directory can write to it. **usr: ** Secondary hierarchy usr The second most important file system is hierarchy, bin ,sbin lib, lib64 include: c Program header file share: Storage location of architecture specific files such as command man pages and self-contained documents local: Hierarchical structure X11R6: x Windows system installation directory games: src: Source file storage location local /usr/local local hierarchy System administrators install applications; typically used to install third-party programs ** var** contains variable data files. This includes spool directories and files, administrative and logging data, and transient and temporary files. Store data that changes from time to time cache Application cache datalibVariable state information local Variable data for /usr/local lock Lock files Lock file log Log files and directories log file opt Variable data for /opt run Data relevant to running processes In operation spool Application spool data tmp Temporary files preserved between system reboots Temporary files to keep after restart **proc**Memory based virtual file system, which stores kernel and process related files, mostly kernel parameters, such as net.ipv4.ip_forward,Virtual as net/ipv4/ip_forward , The full path is /proc/sys/net/ipv4/ip_forward **sys** Memory based sysfs Virtual file system provides a comparison between proc A more ideal way to access kernel data is to manage Linux Device provides a unified model interface

/Contents of subdirectories under sys
Devices is the hierarchical representation model of the kernel for all devices in the system, and it is also the most important directory structure of / sys file system management devices. The following will further analyze its internal structure;
Under the directory of dev, a symbolic link file that links the primary and secondary numbers (major:minor) of character devices and block devices to the real devices (under / sys/devices) is maintained. It was first introduced in kernel 2.6.26;
Bus is a directory structure that the kernel devices are placed in layers according to the type of bus. All devices in devices are connected under a certain bus. The symbolic link of each specific device can be found under each specific bus here. It is also a part of the unified device model of Linux;
Class this is a device model classified by device function. For example, all input devices of the system will appear under / sys/class/input, no matter what bus they are connected to the system. It is also part of the unified device model of Linux;
Block here is where all the current block devices in the system are located. According to the function, it is more appropriate to place them under / sys/class, but they only exist in / sys/block due to historical legacy factors, but they have been marked as obsolete since 2.6.22. This directory exists only when the config ﹣ sysfs ﹣ deprecated configuration is turned on, and they have been corrected in the 2.6.26 kernel Move to / sys/class/block. The old interface / sys/block exists for backward compatibility, but its content has changed to a symbolic link file pointing to their real devices in / sys/devices /;
Firmware here is the user space interface of the firmware loading mechanism of the system. There is a set of API for firmware loading. In Appendix LDD3, there is a more detailed introduction about the firmware loading mechanism supported by the kernel;
fs is designed to describe all the file systems in the system, including the file system itself and the mounted points stored according to the file system classification. At present, only a few file systems such as fuse and gfs2 support the sysfs interface. Some traditional hierarchical control parameters of the virtual file system (VFS) are still in the sysctl (/proc/sys/fs) interface;
Kernel is the location of all adjustable parameters of kernel. At present, only uevent_helper, kexec_loaded, mm, and new slab allocator are using it. Other adjustable parameters of kernel are still in sysctl (/proc/sys/kernel) interface;
Module here has the information of all modules in the system. Whether these modules are compiled inline into the kernel image file (vmlinuz) or as external modules (ko files), they may appear in / sys/module: when they are compiled as external modules (ko files), the corresponding / sys/module / < module [name > /, and some attributes will appear in this directory Files and attribute directories are used to represent some information of the external module, such as version number, loading status, driver provided, etc.; for modules compiled as inline mode, the corresponding / sys/module / < module ﹤ name > will appear only when it has module parameters with non-0 attributes, and the available parameters of these modules will appear in / sys / modules / < module name > / parameters / < param ﹤ name >, such as / sys/ The read-write parameter module / printk / parameters / time controls whether the inline module printk adds a time prefix when printing kernel messages. Parameters of all inline modules can also be written on kernel startup parameters in the form of "< module name >. < param_name > = < value >", such as adding the parameter "printk.time=1" when starting the kernel and writing 1 to "/ sys/module/printk/parameters/time" The effect is the same; inline modules without non-0 property parameters will not appear here.
Power here is the power option in the system. There are several attribute files in this directory that can be used to control the power status of the whole machine, such as writing control commands to shut down and restart the machine.
SLAB (corresponding to 2.6.23 kernel, moved to / sys / kernel / SLAB after 2.6.24) can select the implementation of SLAB memory allocator from 2.6.23, and the new SLUB (queued SLAB allocator) is set to the default value; if this option is compiled, under / sys/slab will appear, which has adjustable parameters for each kmem_cache structure. Corresponding to the / proc/slabinfo dynamic adjustment interface under the old SLAB memory allocator, the information and adjustable items in the new / sys / kernel / SLAB / < SLAB_name > interface are more clear.

10 November 2019, 08:26 | Views: 8764

Add new comment

For adding a comment, please log in
or create account

0 comments