table of Contents:
Overview ◆ / Proc / Directory Introduction ◆ Postscript of Procfs
-------------------------------------------------- ---------------------------------------------------------------------------------------------------------------------------------------
Overview:
Process File System - Procfs - Allows management of kernel processes like management files.
Process file system, procfs, is a pseudo file system that provides a file system interface for kernel process tables, JIM Mauro's summary introduces Procfs.
The purpose of this article is to write SLKM under 64-bit, welcome friends who are interested in communicating.
-------------------------------------------------- ---------------------------------------------------------------------------------------------------------------------------------------
◆ / Proc / Directory Introduction
Process file system, Procfs, is a pseudo file system that allows access to some non-traditional files through the standard file I / O interface. PROCFS has abstract Solaris kernel process architecture, such as all of the running processes in the current system will be reflected in / proc / directory. A subdirectory in each process in the system, the subdirectory name is the corresponding process number (PID), and all process number subdirectory constitute all the contents of the / proc / directory.
Many kernel data structures that provide process data and control points have corresponding reflection in / proc // subdirectory, such as each LWP related data and control structures in multi-threading processes are embodied in / proc // LWP /. The object in the / proc / directory is not a real disk file. These objects are in the kernel memory. When the user performs the LS (1) command to display the / proc / directory structure, the system reads the kernel memory and returns the corresponding content.
By / proc, process information can be obtained relatively simple, such as process execution environments, kernel resource utilization. Process control and Procfs are directly related. Procfs initially design is simple, which is to provide a set of interfaces for writing debuggers, and now has considerable improvements.
The Solaris system provides a set of tools in the / usr / proc / bin / directory, and can perform simple process control from / proc. You can see the Proc (1) man page. The process status command PS (1) also uses the Procfs interface.
The following can be found below the control and information data acquired by the / proc file system, and more information about these files will be found to see the Proc (4) man page.
/ proc - root directory of Procfs
/ proc / - a certain root directory of a certain process, the process PID is the sub-directory name
/ proc // AS - Process address space, a member of the Struct PROC structure. In other words, the process space is displayed in the form of / proc // AS file, and the corresponding process address space can be accessed by this pseudo file system interface.
Struct as * p_as; / * Process address space pointer * /
# ls -l / proc / 53 / as -rw ------- 1 root root 1458176 February 8 17:34 / Proc / 53 / as
The Struct Proc structure is defined in the /usr/include/sys/proc.h file.
/ proc // CTL - a process control file. You can write only the file and send control information to the corresponding process. You can stop, start processes, and set up the process to stop at a particular event. This demonstrates the powerful and convenient of Procfs. Process control, event tracking can be done by opening the control file of the corresponding process, only the control information of the expected behavior is required. See the Proc (4) manual to understand the detailed introduction of the control information and control functions.
/ proc // status - process status information. The Struct Pstatus structure defined in /usr/include/sys/procs.h file. The Proc (4) man page also has been described. There is a member in this structure
LWPSTATUS_T PR_LWP; / * STATUS OF THE REPRESENTATIVE LWP * / This member corresponds to a representative LWP (lightweight process). Single-threaded processes have only one LWP, which is easy to select this representative LWP. Those multi-threaded processes typically have multiple LWPs, one kernel function traversed all LWPs of the current process, selecting this representative LWP according to their status. First select the LWP in execution, if there is no such LWP, select the LWP in order to run, sleep, and stop.
/ proc // LSTATUS - LWPSTATUS structure array, each LWP in the process corresponds to a LWPSTATUS structure. The Struct LWPSTATUS structure is defined in the /usr/include/sys/procs.h file.
/ proc // psinfo - Process information provided by the PS (1) command. Corresponding to the struct psinfo structure, there is a member of the Struct Pstatus structure, and there is a member of the Struct Psinfo structure.
LWPSINFO_T PR_LWP; / * Information for representative LWP * /
The member corresponds to a representative LWP.
/ proc // lpsinfo - LWPSINFO structure array, each LWP in the process corresponds to a LWPSINFO structure
/ proc // MAP - Address space mapping information, you can display these data information with the PMAP (1) command.
/ proc // RMAP - Reserved address space segment in the process. Use the PMAP -R command to display these data information.
/ proc // xMap - Extended address space mapping information. Use the PMAP -X command to display these data information.
/ proc // CRED - Process authentication information, the Struct Prcred structure defined in the /usr/include/sys/procs.h file.
/ proc // sigact - SigAction structure array, description, and all signal settings related to this process. The Struct SigAction structure is defined in the /usr/include/sys/signal.h file.
/ proc // Auxv - Auxv_t structure array, the initial value passed to the dynamic link when the process is executed. The AUXV_T structure is defined in the /usr/include/sys/auxv.h file.
/ Proc // LDT - Local Descriptor Table (LDT), which is only in the Intel X86 architecture.
/ proc // usage - related data of the process resource utilization, corresponding to the Struct Prusage structure, which is defined in the /usr/include/sys/procs.h file.
/ prusage structure array, corresponding to each LWP resource utilization status.
/ Proc // PageData - another manifestation of the process address space can be used to track the reference and modification of the page level. See the Struct PrpageHeader structure definition.
/ prWatch structure array. The PCWATCH operation can be set by writing control file / proc // CTL, and this file is created. Allows to monitor one or more address space ranges, when accessing these monitored pages, generates a fall.
SCZ Note: This feature is similar to the Softice's BPR function. ADB supports this fall, I don't know if PROCFS is used.
/ proc // cwd - symbolic link to the current working directory
/ proc // root - to the symbolic link of the root directory (and what difference above)
/ proc // fd - This is a subdirectory that contains file handles opened by the process.
/ proc // fd / nn - a certain identified file handle that is opened for the corresponding process
/ proc // Object - This is a subdirectory that contains process-related executables and dynamic link libraries.
/ proc // Object / NN - binary target file. The corresponding executable file name is A.out, and the rest is the process-related dynamic link library file. The information provided by the Object directory is the process level. Each / proc // directory has a LWP subdirectory, providing LWP level information:
/ proc // LWP - This is a subdirectory that contains information about all LWPs in the process.
/ proc // LWP / - This is a subdirectory that contains LWP information corresponding to LWPID
/ proc // LWP // LWPCTL - a control file, by it can be released on each LWP level on the LWP level
/ proc // LWP // LWPSTATUS - LWP status information, corresponding to the LWPSTATUS structure, the structural definition in /usr/include/sys/procs.h file
/ proc // lwp // lwpsinfo - corresponding to the LWPSINFO structure, also defined in the /usr/include/sys/procs.h file
/ proc // lwp // lwpusage - LWP resource utilization information, corresponding to prUSAGE structure
/ proc // lwp // xregs - This file is related to the processor architecture, and some files can be not available. For the SPARC system, this article corresponds to the PrxRegSet structure defined in the /usr/include/sys/procfs_isa.h file.
/ proc // lwp // gwindows - Register window. This file is only in the system of the SPARC framework, describing the conventional register group (part of the hardware context) used by the LWP, corresponding to the GWINDOWS structure, which is defined in the /usr/include/sys/regset.h file.
/ Proc // LWP // ASRS - Auxiliary Register Group, only in the SPARC V9 (UltrasParc) architecture, a set of additional hardware registers specifically defined by SPARC V9 architecture, requires Sun4U, 64-bit kernel (Solaris 7 and Its Subsessments), 64-bit processes. Note that the 64-bit kernel can run the 32-bit process, but the 32-bit process does not have such a file and corresponding.
-------------------------------------------------- ---------------------------------------------------------------------------------------------------------------------------------------
◆ Procfs implementation
PROCFS is implemented by dynamically loadable kernel modules. There is a default / proc entry in the system startup / kernel / fs / procfs, / etc / vfstab file, and the system startup process will be disconnected by Mount. The PROCFS PRINIT () and prMount () function will be called in the MOUNT process, which initializes the VFS (virtual file system) structure for the ProCFS, created and initializes a vnode. The VFS structure is defined in the /usr/include/sys/vfs.h file, and the vNode structure is defined in the /usr/include/sys/vnode.h file.
The most of the kernel memory space involved in the / proc directory is dynamically allocated. However, the maximum number of processes supported by the system (can be configured via / etc / system max_nprocs parameter) determines the number of / proc down subdirectory slots, which is initialized by static allocation. The kernel variable procdir is a pointer to the Procent structure array. Each Procent structure corresponds to a procfs directory entry. The number of V.v_Proc variables initiated at the time of the system startup, which is the maximum number of processes supported by the system.
SCZ Note: In the Solaris Kernel Hacking process, it should be used to using the following two commands, many unapproved kernel data structures are quite embodied in the header file under / usr / include, and then use the nm command to confirm that the current kernel is using these kernels. Data structure or kernel function. # Find / usr / include -name "*" | xargs grep -i "procdir" # / usr / ccs / bin / nm -x / dev / ksyms | grep -i "| procdir" [1433] | 0x0000104570D0 | 0x000000000008 | Objt | LOCL | 0 | ABS | ProCDIR # / USR / CCS / BIN / NM -X / DEV / KSYMS | GREP -I "| V $" [8741] | 0x00001041E1F4 | 0x00000000003C | OBJT | GLOB | 0 | ABS | V [6634] | 0x00001041E1F4 | 0x00000000003C | OBJT | GLOB | 0 | ABS | V
In each Procent structure, PE_PROC members point to the corresponding PROC structure, PE_NEXT members point to the next element of the array (SCZ: not only array, but also forming a chain list). The entire ProCDIR array is indexed by the PID_PRSLOT member of the process PID structure. When you create a process (fork ()) system assigns an element in the ProCDIR array, see Figure 1.
-------------------------------------------------- ---------------------------------------------------------------------------------------------------------------------------------------
------ ----> --------- ---- ProCDIR (Procent Structure) | PROC | <-------- --------------- | ----- | PE_PROC | | | | | PE_NEXT | - 0 | P_PIDP | ----> ------- ----- | --------- | | ------ | PID_PRSLOT | ---- | PE_PROC | <- | | ^ | PID_ID | | PE_NEXT | - | Nuclear V | ------------ ------- | | -------- | PE_PROC | | | PE_NEXT | - | | | | ----> --------- | | | P_PIDP | ----> - -------- | | PE_PROC | <- | -------- | PID_PRSLOT | ---- | PE_NEXT | - | Table | ^ | PID_ID | --------- | | V | ------------ ----- | PE_PROC | <- | -------- | | PE_NEXT | | | Proc | <--------------------- --------- | | | | | | p_pidp | | | V -------- | | V.V_PROC
Figure 1. PID_PRSLOT member of the process PID structure is used to index ProCDIR array
-------------------------------------------------- ------------------------ The following is the corresponding header file found on my Sun workstation:
/usr/include/sys/proc.h
struct proc {struct proc * p_next; / * active chain link next * / struct proc * p_prev; / * active chain link prev * / struct pid * p_pidp; / * process ID info * / struct vnode * p_trace; / * pointer to Primary / proc vNode * / struct vNode * p_plist; / * list of / proc vNodes for processing * /}
/ * process ID info * / struct pid {unsigned int PID_PRSLOT: 24; PID_T PID_ID;
The PROCFS kernel code describes the exact format of the PROCFS directory entry. This format is a typical disk file system as a template, and each entry is corresponding to a directory name. The directory entry is included in the directory (the second entry), the length domain, and the Inode number. / PROC's INODE number of file objects is derived from the file object type and process number. Note that the / procate entry does not appear in the directory name search cache, depending on the definition, / proc directory portal is always in physical memory (will not be fanned?).
Because PROCFS is a file system, it is built on the virtual file system VFS and Solaris VNode architecture, the file system instance exists as an VFS object, where the file is described by vnode. Procfs Create a VFS and vNode structure, which can perform file system related operations for PROCFS, such as Mount and Umount, Open, Read, and WRITE operations for / proc directory and file objects.
In addition to the VFS and vNode structures, the PROCFS implementation mainly defines two data structures for describing the file objects in / proc directory. The first is the PrNode structure (/usr/include/siS/proc/prdata.h) describes those file system related data that ultimately link to vNode. The kernel UFS implementation defines a file system related data structure that describes a UFS file, similar, kernel Procfs implementation defines a prnode description a procfs file. Each file in the / proc directory has a vNode and Prnode correspondence.
The second is the Prcommon structure, all over the entire / proc directory structure, in other words, each / proc / and / proc // LWP / directory itself corresponds to a prcommon structure, but the file objects in these directory do not correspond to a prcommon Structure, because it is necessary to be associated with a certain process or LWP because access these file objects. The PRCOMMON structure is abstracted by the file objects in these directories. The Prnode and Prcommon structures are defined in the /usr/include/sys/proc/prdata.h file. Refer to Figure 2.
-------------------------------------------------- ---------------------------------------------------------------------------------------------------------------------------------------
/ proc / / prnode prcommon - ----------------------------- | | | | | | - | | | --------------------------------- --------------------- | Prnode Prchesmon | Prnode Prnode Prnode Per-Process | LWP - | AS - CRED - PSINFO - ... File Objects | / | | | | | | | | | | | / - | | / Prnode Prcommon ---------------------------------------------- -------- / | | | | / / ----------------- -------------------------------------------------- ------------ | Prnode Prnode Prnode Prnode Per-LWP | | LWPCTL - LWPINFO - LWPSTATUS - LWPUSAGE ... FILE Objects | | | | | | | | | | | | | ---------------------- -------------------------------------------------- ------- Figure 2. Prnode and Prcommon structural definition
-------------------------------------------------- ---------------------------------------------------------------------------------------------------------------------------------------
Every process has its own master / proc vNode (that is, this vNode corresponding / proc / file), each LWP has its own vNode corresponding / proc // LWP / file, refer to Figure 3.
-------------------------------------------------- ---------------------------------------------------------------------------------------------------------------------------------------
Back to Proc Structure <------------- -------------- -> -------- ----- -> ---------- PrOCDIR | | Proc | | | Pr_NEXT ---- | - | | PRC_SLOT ----> ---- ----- | | Structure | / Proc | | Pr_COMMON - | - | - ---------- | PE_PROC - | ---------- - | / | | Pr_files --- | - | ---------------- | PE_NEXT | | | | | | | | ---- ----- 1 | | p_trace -------------> --------- | | | P_PLIST | | | | vNode | | | | PE_Next | | | | | | | | --------- | -------- | | | | | | | | | PE_PROC | Multi | | - | - | | | | PE_NEXT | | KTHREAD LWP | / Proc | -------- | | | ------ --- 线 | --------- | / ----------- | | | | | | / lw / vnode | | | | PE_NEXT | | | T_TRACE ----- PrNode | | --------- | | | | | -> ------------ < - | | | PE_PROC | Enter | --------- | | | | Pr_Next ---- | - Prcommon | | | | | | | - | -> ---------- | ------- | KTHREAD LWP | | | | pr_files | | | | | ---- ----- | | | | Pr_vnode | | ---------- | | | | | | --------> --------- | | | | | | | T_TRACE ----- | | | | | | | | | | | | | | | | | | | | -> - ARRAY OF ------------- | - | - | | | | | | - - ---- | | - To vnodes | ------------- | | | for all files / proc // lwp | | --- forin thein / vNode | Prnode | | | DIRECTORY | -> -----------
<- ..... | | | | | | | pra_common - | ------> -------- --- | | | PR_FILES | | Prc_slot | | | | | | Pr_vnode | ---------- --------> --------- | | | | | | | | | | | | | - | - | v_data | | | --------- | ------- ---- Figure 3. Association between a multi-thread process involved
-------------------------------------------------- ---------------------------------------------------------------------------------------------------------------------------------------
Here is the corresponding header file content found on my Sun workstation:
/usr/include/sys/proc/prdata.h
typedef struct prnode {vnode_t * pr_next; / * list of all vnodes for process * / prcommon_t * pr_common; / * common data structure * / prcommon_t * pr_pcommon; / * * process common data structure * and the members of the above difference * / vnode_t ** pr_files; / * contained files array (directory) * / vNode_t pr_vnode; / * Embedded vNode Here is not a pointer * /} prNode_t;
/ * * Common file object to which all / proc vnodes for a specific process * or lwp refer One for the process, one for each lwp * / typedef struct prcommon.. {Int prc_slot; / * process slot number * /} prcommon_t;
/usr/include/sys/vnode.h
/ * * All of the fields in the vnode are read-only once they are initialized * (created) except for: * v_flag: protected by v_lock * v_count: protected by v_lock * v_pages: file system must keep page list in sync with file Size * v_filocks: protected by flock_lock in flock.c * v_shrlocks: protected by v_lock * / typef struct vNode {CADDR_T V_DATA; / * private data for fs * /} vNode_t;
/usr/include/system/thread.h
Typedef struct _kthread {structure; / * pointer to / proc LWP vNode * /} kthread_t;
Figure 3 demonstrates the association between the part-related PROCFS data structure and the association between the PROCFS file and the parties. Notice all of the VNODes related to a process link through the PrNode structure PR_NEXT member. When references a procfs directory and file objects in the directory, kernel dynamically creates the necessary data structure to support this file I / O request, and is also dynamically destroying the relevant data structure. Whenever you do anyway, a procfs directory or file, you seem to always, similar to the light in the refrigerator, it is always bright when you open the refrigerator, but close the refrigerator After the door, it was in fact closed. The data that Procfs can access is obviously always located in the kernel PROC structure and some other data structures, which together constitute a complete process model in the Solaris core. The application can obtain process data through PROCFS, and the control process is executed. The advantage of doing this is to hide the underlying details of the kernel process model, in a relatively common manner, the data interested, perform process control. This dynamic abstraction has been held when the request is to occur when the request occurs.
File I / O operations in PROCFS follow traditional ways, open the file to get the file handle, read and write, turn off the file handle. Create and initialize the Prnode and Prpidar structures when procfs related vNode operations are performed through the vNode switch table mechanism, which is usually the result of the application file request. The actual Procfs vNode operation is processed by the relevant lookup, reads and writes objects in the / proc directory.
Procfs traversal and read requests use a set of function pointer implementations, this group function implements the PROCFS file type. Document type is divided into two layers of maintenance. Among the v_type members of VNODE, the Procfs file type is defined as a Vproc. The PR_TYPE member of the PRNODE structure defines the type of this particular Procfs file. The PROCFS file type directly describes the / proc directory structure, see /usr/include/sys/proc/prdata.h file.
/ * * Node Types for / proc files (Directories and files contained the). * / Typef Enum prnodetype {pr_procdir, / * / proc * / pr_piddir, / * / proc / * / pr_as, / * / proc // as * / Pr_CTL, / * / proc // CTL * / pr_status, / * / proc // status * / pr_lstatus, / * / proco, / * / proco, / * / pr_lpsinfo, / * / proc // lpsinfo * / pr_map, / * / proc // map * /} prNodetyPE_T;
The basic process when opening a procfs file is shown in Figure 4.
-------------------------------------------------- ---------------------------------------------------------------------------------------------------------------------------------------
open ( "/ proc //", O_RDONLY); | Specific procfs directory object Generation | vn_open () lookup functions are invoked | through the pr_lookup_function [] Code | ----> lookupxxx () array | | VOP_LOOKUP () - > prlookup () stream | | Index based on type | | Pr_lookup_function ---------------------- | | | Pr_lookup_piddir () | / | | Construct Full Path Name, ----------------------- / | | LOOKING UP Each Element | Pr_lookup_lwpdir () | / | | in the path. ----------------------- PrgetNode () | | Pr_lookup_Objectdir () | / | | ------------ ----------- / | | | | | / | | ... | ... | | | ----------- -------------------------------- | VOP_Open () -> Propen () V Figure 4. Open a procfs file Basic process
-------------------------------------------------- ---------------------------------------------------------------------------------------------------------------------------------------
The procedure in Figure 4 starts from the application, making the Open (2) system call for a procfs file. Enter the VNODE core (VN_Open ()), complete a series of lookups to build a full path name for the target / proc file. The macros of the vNode layer enters the file system related operations. In the above legend, VOP_lookup () parses the Pr_lookup () function of Procfs. PR_lookup () Completes access check and calls the corresponding PROCFS function based on the directory file type, such as Pr_lookup_PIDDIR () lookup work for / proc / directory. Each Pr_lookup_xxx () directory lookup function completes the work of certain directory types, and then calls prgETNode () to get prnode.
PRGETNODE () Create prnode (in which VNODE) is created for / proc file, and some members of the Prnode and VNODE structures are initialized. For / proc / and / proc // lwp /, a Prcommon structure is also created, and the PRNODE structure is switched and partially initializes. Note that for the directory file under / proc, in order to correctly reflect the type of directory file type, the vNode type changes from Vproc to VDIR, indicating that this is a procfs directory file.
Once the full path name is built, enter the file system-related open () function through the VOP_Open () macro. The PrOCFS's Propen () function completes the rest of the Prnode and VNODE structures and access testing for specific file types. Once propen () is complete, the control returns to VN_Open (). The final file handle represents the file handle of the Procfs file to the main tunner.
Read a PROCFS data file (and a directory file relative) type Open process, the read () system call finally enter the prod () function. Procfs implements a read function related to a data file object (different data structure), such as Pr_Read_PSINFO (), PR_READ_PSTATUS (), and more. These function pointers form an array that indexes with the file type, and proD () finally calls them. The whole process is similar to the Lookup operation. The PROCFS implementation of Solaris 7 is based on the 64-bit kernel, but also supports 32-bit and 64-bit applications, providing 32-bit versions of available data files on the / proc hierarchy. In the 64-Bit Solaris 7 kernel, the data structure of each / proc file object content is described while having 32-bit versions and 64-bit versions, such as lwpstatus and lwstatus32, psinfo, and psinfo32, and more. For each 32-bit version of the structure definition, the corresponding pr_read_xxx () function has supported encoding of 32-bit data modes.
Procfs users will not be aware of a variety of data patterns in the 64-bit core. When calling forward (), it checks the data mode used by the primary, and activates the function of the corresponding data mode. Here is an exception, when reading / proc // AS (address space) file, the main adjustment must have the same data mode as the / proc // AS file, in other words, the 32-bit application in the 64-bit kernel You can read another 32-bit process AS (address space) file, but you cannot read another 64-bit process AS file.
SCZ Note: I think it is better to say that / proc // AS itself is a single data mode, or 32-bit, or 64-bit, not available. Other / proc data file objects may support both data modes.
The PR_READ_XXXX () function reads related data from the kernel, and then writes the corresponding PROCFS data structure and eventually returns to the main tunner. For example, pr_read_psinfo () reads data from the PROC structure of the target process, the CRED structure, and the AS structure, and writes the corresponding member in the PSINFO structure. Synchronize the mutex lock determined by the P_Lockp member of the PROC structure when accessing kernel data, ensuring that only one customer thread can access Per-Process or PER-LWP kernel data each time.
I rarely write access to the procfs file. Don't consider writing a catalog to create a data file, typical write operations are to issue some control messages or LWP control files. Control Message (see Proc (1)) includes STOP / START messages, signal tracking, and control, fault management, execution control (such as post / exiting a system call time suspension) and address space access monitoring.
So far, we discuss all I / O operations for the PROCFS file with standard system calls. This is the only way to program access / proc files from ordinary application level programmers. However, there is another set of specific sets of access interfaces for ProCFS, and / usr / proc / bin / down / prop / bin / down, using Solaris uses this set of interfaces. This set of interfaces are located in the libproc.so dynamic link library, which belongs to an unapproved interface. Sun is starting to prepare documents on this set of interfaces as a standard Solaris APIS. Figure 5 shows the interface relationship between the PROCFS module and the layers in the previously discussed core.
-------------------------------------------------- ---------------------------------------------------------------------------------------------------------------------------------------
------------------------------------ Custom / Proc Code | / USR / Proc / Bin / | ------------------------------------------------------------------ --------- | Stdio Interfaces | | | Libproc | ------------------ - ------ -------- | | System Calls || User ---------------------------------- ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ --------------------- | KERNEL | vNode Layer || ------------------ ------------------- -------- | Procfs | ----------------- ------------------------------ Figure 5. Interface relationship between PROCFS modules and layers
-------------------------------------------------- ---------------------------------------------------------------------------------------------------------------------------------------
Figure 5 demonstrates a plurality of paths to the ProCFS kernel routine. Developers typically enter the vNode layer through the system call, which is the way in the previous introduction. The Proc (1) command is constructed on the interface provided by LibProc.so. Why do you need this set of dynamic link library interfaces, providing a set of easy-to-use routines for application development, reducing the complexity of direct use of kernel mechanisms. Controls the execution of a process, especially multithreaded processes, very complicated, requires a group of coded interfaces that really belong to the API layer, rather than the encoded interface of the kernel layer.
Write an opcode and an optional operand to write to the head 8 bytes of the control file (if the LP64 kernel is the head 16 bytes). The path to the process control file is also vnode layer, and finally call the procfs prWritectL () function. Allowsring a plurality of control messages (opcode and operands) to the control file in one write call, prwritectl () divided by multiple control messages written into independent opcode / operand, order submitted to the kernel The Pr_Control () function, the pr_control () function will set the process or LWP corresponding flag to indicate that the control mechanism is started, such as a certain event occurs. The control function is introduced in the Proc (4) man page.
The implementation of process / LWP control is closely integrated with the process / LWP subsystem in the kernel, and various domains in the P-zone, Us, LWP, and kernel threads are collapsed together to complete process management and control through Procfs. Establishing Process Controls Includes setting flags and bitmask fields to track events that lead to processes, threads, and leaving kernels, including signals, system calls, and fault situations. In response to the entry of these events, the point of leaving the kernel is defined, and a natural control mechanism is provided for the process status change.
System call, signal, and faults correspond to data type sysset_t, sigset_t, and fltset_t, respectively. If you are suspended when a system call occurs, it has not been read from the process to the parameters called to the system. If you are specified to leave a system call, the returns from the system call have been submitted to the process. You can specify a certain fault to enter the kernel trap handler. You can specify that the pause or slave system call, the kernel trap handler is returned, and the process can be woken up.
You can specify a zone in the process virtual address space in monitoring, which is a monitoring point when the monitoring type is monitored (such as read, write access), which is a monitoring point, typically caused by monitoring events. Process, LWP pause, which is implemented by tracking FLTWATCH failures or capturing non-blocking SigTrap signals. In some cases, in order to analyze process information, process control, the control process may require a target process to temporarily complete a particular action. For example, the pfiles (1) command can list information of each file that is turned on the target process, which requires the Target process to do STAT (2) system calls for each open file handle. The process running on the Solaris system typically spends a lot of time blocked on a system call. In order to obtain the task submitted by the control process, you need to snap the CPU when the target process is blocked, protect the current system call status, After the control process is submitted, the restored system call status continues to perform the original task of the target process.
In order to achieve this, Procfs implements another proxy LWP, rather than using the LWP in the target process, otherwise save, restore more complicated. PROCFS provides a mechanism to create a proxy LWP (note the PCAgent control message). After the agent LWP creates success, it will be the only thing in the target process to run LWP until it die. The agent LWP is executed in the target process to complete the task submitted by the control process, such as executing system calls in the target process. Then destroy the agent LWP, restore the saved process / LWP status. There is a member P_AGENTTP in the PROC structure, pointing to the created agent LWP. The kernel code is checked in the target process by checking the pointer.
KThread_t * p_agenttp; / * thread ptr for / proc Agent LWP * /
The Proc (4) man page describes more details of the process control.
-------------------------------------------------- ---------------------------------------------------------------------------------------------------------------------------------------
postscript:
This article and <> are part of <>, because many things lack of kernel Hacking experience and common terminology agreed, translation is quite intensified, so it can be repeatedly understood in accordance with the header files that can be compared to / usr / include /. << [805-3024] Solaris Device Driver Programming Guide >> and << [[805-4038] Solaris Flow Programming Guide >> is a good supplement. In addition, you can ask Sun developers on Comp. Enix.programmer and Comp.unix.Solaris.
