CushionTheBlow (구 BluemoonSoft)

LXR Cross Referencer, usually known as LXR, is a general-purpose source code indexer and cross-referencer that provides web-based browsing of source code, with links to the definition and usage of any identifier. LXR is written in Perl and supports multiple programming languages.

Reference:
http://en.wikipedia.org/wiki/LXR_Cross_Referencer

Object Linking and Embedding (OLE) is a technology that allows embedding and linking to documents and other objects developed by Microsoft. It is found on the Component Object Model. For developers, it brought OLE custom controls (OCX), a way to develop and use custom user interface elements. On a technical level, an OLE object is any object that implements the IOleObject interface, possibly along with a wide range of other interfaces, depending on the object's needs.

Reference:
http://en.wikipedia.org/wiki/Object_Linking_and_Embedding

In computing, a named pipe (also FIFO for its behaviour) is an extension to the traditional pipe concept on Unix and Unix-like systems, and is one of the methods of inter-process communication. The concept is also found in Microsoft Windows, although the semantics differ substantially. A traditional pipe is "unnamed" because it exists anonymously and persists only for as long as the process is running. A named pipe is system-persistent and exists beyond the life of the process and must be "unlinked" or deleted once it is no longer being used. Processes generally attach to the named pipe (usually appearing as a file) to perform IPC (inter-process communication).

Reference:
http://en.wikipedia.org/wiki/Named_pipes

A hardware abstraction layer (HAL) is an abstraction layer, implemented in software, between the physical hardware of a computer and the software that runs on that computer. Its function is to hide differences in hardware from most of the operating system kernel, so that most of the kernel-mode code does not need to be changed to run on systems with different hardware. On a PC, HAL can basically be considered to be the driver for the motherboard and allows instructions from higher level computer languages to communicate with lower level components, such as directly with hardware.

The Windows NT-based operating systems have a HAL in the kernel. This allows portability of the Windows NT kernel-mode code to a variety of processors, with different memory management unit architectures, and a variety of systems with different I/O bus architectures; most of that code runs without change on those systems, when compiled for the instruction set for those systems. For example, the SGI Intel x86-based workstations were not IBM PC compatible workstations, but due to the HAL, Windows NT was able to run on them.

BSD, Mac OS X, Linux, CP/M, DOS, Solaris, and some other portable operating systems also have a HAL, even if it's not explicitly designated as such. Some systems, such as Linux, have the ability to insert one while running, like Adeos. The NetBSD operating system kernel is widely known as having a clean hardware abstraction layer which allows it to be highly portable. As part of this system are uvm(9)/pmap(9), bus_space(9), bus_dma(9) and other subsystems. Popular buses which are used on more than one architecture are also abstracted, such as ISA, EISA, PCI, PCI-E, etc., allowing drivers to also be highly portable with a minimum of code modification.

An "extreme" example of a HAL can be found in the System/38 and AS/400 architecture. Most compilers for those systems generate an abstract machine code; the Licensed Internal Code, or LIC, translates this virtual machine code into native code for the processor on which it is running and executes the resulting native code. (The exceptions are compilers that generate the LIC itself; those compilers are not available outside IBM.) This was so successful that application software and operating system software above the LIC layer that were compiled on the original S/38 run without modification and without recompilation on the latest AS/400 systems. This despite the fact that the underlying hardware has been changed dramatically; at least three different types of processors have been in use.

Hardware abstraction layers are of an even lower level in computer languages than application programming interfaces (API) because they interact directly with hardware instead of a system kernel, therefore HALs require less processing time than APIs. Higher level languages often use HALs and APIs to communicate with lower level components.

Operating systems having a defined HAL are easily portable across different hardware. This is especially important for embedded systems that run on dozens of different platforms.

Reference:
http://en.wikipedia.org/wiki/Hardware_abstraction_layer

On Unix-like computer systems, procfs, short for process file system, is a pseudo file system (a file system dynamically generated at boot) used to access process information from the kernel. The file system is often mounted at the /proc directory. Because /proc is not a real file system, it consumes no storage space and only a limited amount of memory.

procfs is supported under:

- Solaris
- BSD
- Linux (which extends it to non-process-related data)
- IBM AIX (operating system) (which bases its implementation on Linux to improve compatibility)
- QNX

Reference:
http://en.wikipedia.org/wiki/Procfs

Plug and play is a computer feature that allows the addition of a new device, normally a peripheral, without requiring reconfiguration or manual installation of device drivers.

Modern plug-and-play includes both the traditional boot-time assignment of I/O addresses and interrupts to prevent conflicts and identify drivers, as well as hotplug systems such as USB and Firewire.

Plug-and-surf is applied to network devices to connect to the Internet. It generally uses DHCP.

Reference:
http://en.wikipedia.org/wiki/Plug-and-play

Hot swapping and hot plugging are terms used to separately describe the functions of replacing system components; hot swapping describes changing components like fans and power supplies which do not interact with the system software, while hot plugging describes changing or adding components like hard drives which do interact with the operating system. Both terms describe the ability to remove and replace components of a machine, usually a computer, while it is operating. For hot swapping once the appropriate software is installed on the computer, a user can plug and unplug the component without rebooting. A well-known example of this functionality is the Universal Serial Bus (USB) that allows users to add or remove peripheral components such as a mouse, keyboard, or printer. It usually requires more sophisticated software and hardware than does plug-and-play.

Reference:
http://en.wikipedia.org/wiki/Hot_swapping

A device file system or special file system allows software to interact with the device driver using standard input/output system calls, which simplifies many tasks.

It includes device files, device nodes', or device special files which are interfaces for a device driver that appears in a file system as if it were an ordinary file. This allows software to interact with the device driver using standard input/output system calls, which simplifies many tasks. There are also special device files on Microsoft operating systems, such as MS-DOS and Windows.

Device files often provide simple interfaces to peripheral devices, such as printers. But they can also be used to access specific resources on those devices, such as disk partitions. Finally, device files are useful for accessing system resources that have no connection with any actual device such as data sinks and random number generators.

MS-DOS borrowed the concept of special files from Unix, but renamed them device files. Because early versions of MS-DOS did not support a directory hierarchy, device files were distinguished from regular files by making their names reserved words. This means that certain file names are reserved for device files, and cannot be used to name new files or directories. The reserved names themselves are chosen to be compatible with "special files" handling of PIP command in CP/M.

There are two general kinds of device nodes in Unix-like operating systems, known as character special files and block special files. The difference between them lies in how data written to them and read from them is processed by the operating system and hardware. These together can be called device special files in contrast to named pipes, which are not connected to a device but are not ordinary files either.

Reference:
http://en.wikipedia.org/wiki/Devfs

Sysfs is a virtual file system provided by Linux 2.6. Sysfs exports information about devices and drivers from the kernel device model to userspace, and is also used for configuration.

History
During the 2.5 development cycle, the Linux driver model was introduced to fix several shortcomings of version 2.4:

- No unified method of representing driver-device relationships existed.
- There was no generic hotplug mechanism.
- procfs was cluttered with lots of non-process information.

Sysfs is designed to export the information present in the device tree which would then no longer clutter up procfs. It was written by Patrick Mochel. Maneesh Soni later wrote the sysfs backing store patch to reduce memory usage on large systems.

sysfs is an in-memory filesystem that was originally based on ramfs. ramfs was written around the time Linux 2.4.0 was being stabilized. It was an exercise in elegance, as it showed just how easy it was to write a simple filesystem using the then-new VFS layer. Because of its simplicity and use of the VFS, it provided a good base from which to derive other in-memory based filesystems.

sysfs was originally called ddfs (Device Driver Filesystem) and was initially created to debug the new driver model as it was being written. Previously, debugging was performed by using procfs to export a device tree, but under strict urging from Linus Torvalds, it was converted to use a new filesystem based on ramfs. By the time the new driver model was merged into the kernel around 2.5.1, it had changed names to driverfs to be a little more descriptive.

During the next year of 2.5 development, the infrastructural capabilities of the driver model and driverfs began to prove useful to other subsystems. kobjects were developed to provide a central object management mechanism and driverfs was renamed to sysfs to represent its subsystem agnosticism.

Technical Overview
For each object added in the driver model tree (drivers, devices including class devices) a directory in sysfs is created. The parent/child relationship is reflected with subdirectories under /sys/devices/ (reflecting the physical layout). The subdirectory /sys/bus/ is populated with symbolic links, reflecting how the devices belong to different busses. /sys/class/ shows devices grouped according to classes, like network, while /sys/block/ contains the block devices.

For device drivers and devices, attributes may be created. These are simple files; the rule is that they should only contain a single value and/or allow a single value to be set (unlike some files in procfs, which need to be heavily parsed). These files show up in the subdirectory of the device driver respective to the device. Using attribute groups, a subdirectory filled with attributes may also be created.

Some buses
PCI
Exports information about PCI devices.

USB
Contains both USB devices and USB hosts.

S/390 buses
As the S/390 architecture contains devices not found elsewhere, special buses have been created:

- css: Contains subchannels (currently the only driver provided is for I/O subchannels).
- ccw: Contains channel attached devices (driven by CCWs).
- ccwgroup: Artificial devices, created by the user and consisting of ccw devices. Replaces some of the 2.4 chandev functionality.
- iucv: Artificial devices like netiucv devices which use VM's IUCV interface.

Sysfs and userspace
Sysfs is used by several utilities to access information about hardware and its driver (kernel modules) such as udev or HAL. Scripts have been written to access information previously obtained via procfs, and some scripts configure device drivers and devices via their attributes.

Reference:
http://en.wikipedia.org/wiki/Sysfs

udev is the device manager for the Linux 2.6 kernel series. Its primary function is managing device nodes in /dev. It is the successor of devfs and hotplug, which means that it handles the /dev directory and all user space actions when adding/removing devices, including firmware load.

The latest versions of udev depend on the latest version of the uevent interface of the Linux kernel which has been updated or introduced with Linux kernel 2.6.13. A system using a new version of udev will not boot with kernels older than 2.6.13 unless udev is disabled with bootparam noudev and a traditional /dev directory is used for device access.

Reference:
http://en.wikipedia.org/wiki/Udev