Dynamic alteration of operating system kernel resource tables

Details Dynamic alteration of operating system kernel resource tables Dynamic alteration of operating system kernel resource tables

1998-08-13

2001-08-07

Banankhah, Majid (Department: 2151)

Electrical computers and digital processing systems: multicomput

Computer-to-computer data routing

Least weight routing

C709S241000

Reexamination Certificate

active

06272519

ABSTRACT:

1. BACKGROUND OF THE INVENTION
The invention relates in general to the field of computer software optimization and, more particularly, to run-time alterations in operating system resource allocation data. Specifically, the invention describes a method for dynamically altering operating system kernel resource control tables without the need to shut-down and reboot the computer system to invoke the changes.
An application executing under the control of, for example, the Unix operating system requests the use or allocation of resources controlled by the kernel through a mechanism known as a system call. The system call technique provides a standard interface in all currently available Unix variants and is essentially a branch table indexed by the function being requested. See
FIG. 1. A
non-exhaustive set of system call examples include open a file, close a file, allocate memory, perform an input-output (I/O) operation, and allocate or use an interprocess communication resource such as a message queue, semaphore, or shared memory.
As part of the processing of a system call, special kernel program code switches the state of the operating environment from that of the application (commonly referred to as user mode, problem state, or protected mode) to a state required by the kernel to accomplish its control tasks (commonly referred to as kernel mode, supervisor state, or privileged mode). It then indexes into the branch table (commonly called a sysent table
100
), extracts the address
105
of the routine to process the requested function, and calls the routine
120
at that address to perform the requested function. When the kernel function
120
has completed its processing, it returns its result(s) and control back to the operating environment (e.g., user or protected mode) of the application that originated the system call.
1.1 Resource Allocation
In a specific example a system call is executed to allocate, control, update or manipulate, and release resources associated with semaphores, shared memory and message queues which are collectively known as interprocess communications (IPC) facilities. In the allocate functions, such as Unix's semget, shmget, and msgget, the application making the IPC resource request submits a key with which to uniquely identify the resource and any information required to define or initialize the resource (e.g. size of shared memory segment, number of semaphores, and access permissions). In response to the request, the kernel generates and returns an identifier, referred to as a kernel identifier, which is used by the calling application in all further references to the resource or resource set; those resources allocated during the allocate process. (A kernel identifier is, generally, a numeric value returned to an application program, from the kernel, that identifies a specific resource element. For example, if an application program requests a shared memory segment from the kernel, the returned kernel identifier identifies the specific resource control blocks for that shared memory segment.) In all subsequent actions or control functions executed against the allocated resource, the kernel identifier is submitted as a parameter in the system call to identify the target resource set to the kernel.
As part of the allocation process, the kernel makes several determinations on the “get resource” request. If no resource is currently in existence for the submitted kernel identifier, the kernel attempts to allocate the requested resource by determining if there is a sufficient quantity of the resource available to satisfy the request and a free control structure (commonly known as semid_ds, shmid_ds, or msqid_ds) in the kernel to represent the resource set. For each resource, there is a preset system-wide limit of the number of these control structures (and therefore kernel identifiers) that can be active at any one time. If a control structure is available, then it is initialized using the information provided in the system call parameter list and a kernel identifier is generated based on which control structure was found available.
If, on the other hand, the application executes a system call using a kernel identifier that is already associated with a resource (e.g., resource control structure), the kernel performs a validation process to ensure the calling application is authorized to use the identified resource. If it is, the kernel identifier already assigned to the referenced resource is returned to the application. In this way, many applications can share a resource.
1.2 Allocation of Kernel Control Structures
Kernel control structures are generally organized into arrays or tables herein referred to as resource control tables. Because the number/quantity of any specified resource is known at system startup time, resource control tables may be created as static or dynamic memory elements. That is, a resource control tables memory allocation is defined in such a way as to make its location and size constant.
Static allocation is realized in the way a particular structure (e.g., resource control table) is defined in the kernel's program. For example, in the C programming language, a static array/table can be created by defining an instance of a structure array in the global data space by using the following statement:
struct sample {int a; int b;} sampletable [100];
This statement creates a static array identified by the name ‘sampletable’ having 100 elements, where each element is of type ‘sample.’ As would be well known to those of ordinary skill, this type of array can be defined using other programming languages using definition statements that are equivalent in function to those stated here for the C programming language.
Key aspects of the sampletable structure (see
FIG. 2
) created using static allocation techniques include: (1) it is created in the compile or assembly phase of program development; (2) table initialization, if any, is done during the compile or assembly phase as well; (3) the table's location in memory is determined by references to the array name sampletable
200
; (4) the table's memory space is part of the executable object
205
and cannot be released or reused; and (5) the compiler, or assembler, will have placed other data elements of global scope around this structure array,
210
and
215
, rendering it impossible to increase the number of elements in the array while leaving it at the same location in the executable program.
Dynamic allocation, in contrast, is performed at run-time, i.e., during program execution. In this method, definition of the ‘sampletable’ data structure takes the form of a pointer in the program, where only the pointer is defined at compile or assemble time. Only at program execution, such as during program startup or when the array is first referenced, would the sampletable structure be initialized. Typically, initialization can take the form of a call to a free storage management routine (such as malloc or calloc) provided by the operating environment to acquire the address of a section of memory large enough to hold an array of the desired number of elements. The address of the memory section would be placed into the pointer variable, referenced by the name sampletable. References to the array would thereafter be accomplished by using the address contained in the pointer variable (array name). Again using the C programming language as an example, this could be accomplished with the following code fragment:
struct sample*sampletable;
sampletable=(sample*) malloc(100*sizeof(sample) )
Key aspects of the sampletable structure (see
FIG. 3
) created using dynamic allocation techniques include: (1) the only storage reserved during the compile or assembly phase is for the pointer to the array sampletable
300
; (2) storage for the array sampletable is not part of the executable module
305
loaded at run-time; (3) storage for the sampletable array must be acquired and initialized during execution of the program if sampletable is to be used during progr

Affiliated with

Also associated with

Rating

Dynamic alteration of operating system kernel resource tables does not yet have a rating. At this time, there are no reviews or comments for this patent.

If you have personal experience with Dynamic alteration of operating system kernel resource tables, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Dynamic alteration of operating system kernel resource tables will most certainly appreciate the feedback.

Rate now

Comments { 0 }

Profile ID: LFUS-PAI-O-2478097