Patent Application
20090307659
The present disclosure relates generally to information handling systems (IHS), and more particularly to a modular advanced configuration and power interface (ACPI) source language (ASL) for an IHS.
As the value and use of information continues to increase, individuals and businesses seek additional ways to process and store information. One option is an information handling system (IHS). An IHS generally processes, compiles, stores, and/or communicates information or data for business, personal, or other purposes. Because technology and information handling needs and requirements may vary between different applications, IHSs may also vary regarding what information is handled, how the information is handled, how much information is processed, stored, or communicated, and how quickly and efficiently the information may be processed, stored, or communicated. The variations in IHSs allow for IHSs to be general or configured for a specific user or specific use such as financial transaction processing, airline reservations, enterprise data storage, or global communications. In addition, IHSs may include a variety of hardware and software components that may be configured to process, store, and communicate information and may include one or more computer systems, data storage systems, and networking systems.
IHS design is moving from basic input/output (BIOS) architecture to extensible firmware interface (EFI) architecture which is modular in nature. The EFI is generally known as a specification/system that defines a software interface between an operating system and platform firmware. A form of EFI is also known as unified EFI (UEFI). BIOS modules/drivers generally interact with other drivers in terms of protocol & event. Drivers register for a specific event and other drivers broadcast the event that causes those pending event methods to be invoked. An event is generally known by those having skill in the art as an action in an IHS that may be initiated by the user, a device (e.g., a timer, a keyboard, and a variety of other devices) or by the operating system. In event driven programming, the flow of the program is generally determined by the events, such as user actions or messages from other programs.
A problem arises with this architecture for advanced configuration and power interface (ACPI) components. ACPI components commonly use ACPI source language (ASL). However, ASL traditionally does not support such a modular concept. The BIOS ACPI components are generally written in a very primitive ASL language that does not follow advanced programming methods, such as callbacks, methods registration and indirect method invocation. Thus, the ASL language poses many challenges to BIOS programmers. For example, one ACPI method may need to call other ACPI methods by the same name. ASL does not have a concept of broadcasting an event to other ASL method. Currently the ASL event method explicitly calls out each of the interested methods that need to act on such event. It is very difficult to integrate ASL modules from various product vendors because one module needs to know the scope, names and parameter of the other dependent modules. This causes a challenge for BIOS writers to isolate the ASL modules as each ASL module directly calls out functions in other ASL component. Also when writing an ASL code that interacts with various platform behavior, chipset, feature etc. the code becomes very convoluted and the code developer adds a build time conditional statement (for example. #if<>/#else statement) in the files so that ASL code behavior can change based on platform, feature, chipset and etc.
When writing ASL code there is a need to build the modular concept (similar to UEFI) so that each ASL module can be separately written without the knowledge of other modules and so each module can interact with other modules via an event mechanism.
Accordingly, it would be desirable to provide an improved modular ASL absent the disadvantages discussed above.
According to one embodiment, a system for source language module interaction uses an event mechanism and includes one or more subsystems to detect a producer event, detect a consumer event, generate a new source language method for the producer event and a new source language method for the consumer event, and link the producer event and the consumer event using the new source language method.
For purposes of this disclosure, an IHS 100 includes any instrumentality or aggregate of instrumentalities operable to compute, classify, process, transmit, receive, retrieve, originate, switch, store, display, manifest, detect, record, reproduce, handle, or utilize any form of information, intelligence, or data for business, scientific, control, or other purposes. For example, an IHS 100 may be a personal computer, a network storage device, or any other suitable device and may vary in size, shape, performance, functionality, and price. The IHS 100 may include random access memory (RAM), one or more processing resources such as a central processing unit (CPU) or hardware or software control logic, read only memory (ROM), and/or other types of nonvolatile memory. Additional components of the IHS 100 may include one or more disk drives, one or more network ports for communicating with external devices as well as various input and output (I/O) devices, such as a keyboard, a mouse, and a video display. The IHS 100 may also include one or more buses operable to transmit communications between the various hardware components.
Other resources can also be coupled to the system through the memory I/O hub 104 using a data bus, including an optical drive 114 or other removable-media drive, one or more hard disk drives 116, one or more network interfaces 118, one or more Universal Serial Bus (USB) ports 120, and a super I/O controller 122 to provide access to user input devices 124, etc. The IHS 100 may also include a solid state drive (SSDs) 126 in place of, or in addition to main memory 108, the optical drive 114, and/or a hard disk drive 116. It is understood that any or all of the drive devices 114, 116, and 126 may be located locally with the IHS 100, located remotely from the IHS 100, and/or they may be virtual with respect to the IHS 100.
Not all IHSs 100 include each of the components shown in
The present disclosure solves the problem of needing to build the modular concept (similar to UEFI) so that each ASL code module may be separately written without the knowledge of other modules and so each module can interact with other modules via an event mechanism. In an embodiment, the problem is solved by adding an ASL Signal/Create event concept to ASL language.
In an embodiment, a UEFI BIOS will be used to auto generate a new ASL method for each event and link both the producer and consumer event using this new ASL method. As such, the BIOS build process may accomplish this using special tags, such as, <CreateEvent(..)>, <SignalEvent(..) in the ASL Modules. The BIOS build process may also accomplish this using a globally unique identifier (GUILD) to uniquely define an event name. A GUID is generally known as a special type of identifier used in software applications to provide a reference number that is unique in any context. Also, the BIOS build process may accomplish this using a special preprocessor utility (e.g., Perl script) that will parse the ASL modules at build time and link all those consumer/producer events by generating new ACPI methods and filling it appropriately. Furthermore, the BIOS build process may accomplish this using a final ASL compilation to build an ACPI binary (called the AML code).
Each ASL modules may be isolated and will not refer to other ASL module directly, but instead through event mechanism. An ASL module will broadcast the event by signaling an event with a unique GUID and other ASL module will receive that events by creating an event with the same GUID and defining the ASL method associated with the method.
Use of a GUID as event name offers a concept as a unique number is generated each time a GUID is generated by GUID tools. Thus, a BIOS developer may create a unique Event name without worrying about the event name colliding with some other event name.
The ASL module that produces/broadcasts the event may use a special tag, such as, “<SingalEvent(Event_GUID>” in the ASL code. The ASL modules that consume the event will use a special tag, such as, “<CreateEvent(Event_GUID, ASLMethodb>” in the ASL code where the ASLMethodb is the actual ASL method that needs to be executed.
During the BIOS build time, a special preprocessor utility (e.g., a perl script) will parse the special tags, such as, <SingalEvent(..)> and <CreateEvent(..)> and create a hash table for each GUID. A hash table is generally referred to by a person having ordinary skill in the art as a data structure that associates keys with values. As such, a hash table supports efficient lookup of information. The contents of hash table include the ASL method names of producers and consumer of the event. After parsing the ASL modules, the preprocessor utility may create a unique method for each unique event GUID it can find. Also, after parsing the ASL modules, the preprocessor utility may replace the ASL line with special tag, such as, “<SignalEvent (Event_GUID,XYZ)>” with the new method that it created. The preprocessor may auto create this new method. This new method may include all the ASL methods that are consumed by this event.
In an embodiment, the script program will convert the code of
Although illustrative embodiments have been shown and described, a wide range of modification, change and substitution is contemplated in the foregoing disclosure and in some instances, some features of the embodiments may be employed without a corresponding use of other features. Accordingly, it is appropriate that the appended claims be construed broadly and in a manner consistent with the scope of the embodiments disclosed herein.
