Kernel Extensions

In this page we try to gather some ideas for the current kernel in the hope that those ideas might make life a bit easier in mid-term.

RESOURCE.SYS

Some ideas about changes, which can and (from my point of view), must be implemented.

Background

Resource.sys basedev present for long time. It is responsible for HW resources (IRQ, I/O ports, memory ranges) managing. But not only. Resource.sys is a main point, where config.sys processing take a place. Kernel was modified (somewhere around Warp 3 GA) to ask resource.sys for the list of drivers to load. Now, this functionality is used to process so-called snoopers, i.e. files with .SNP extension, which used to detect the presence of some specific hardware and used resources. The idea is to replace resource.sys with another one, which will detect present PCI (and ACPI) devices and load apropriate drivers, based on the some PCI_ID : driver_name database (just like Windows XP does). Why it needed?

At present, the only way to implement PnP-like solution was to place multiple drivers into single binary (like Uniaud and Danis506). The idea seems to be a nice, but in the real world it have some drawbacks. The most common scenario is: we have two versions of (for example) Uniaud. One version works well with chipset X and has a bug in the support of chipset Y. The another version was fixed a bug for Y, but has some bad things for chip Z. Grand total is: we has no driver, which support all 3 chipsets really well and must select the version, based on the HW installed now (and change the version, with change of HW). With implementation of PnP driver selection, we can just have 3 separate drivers, one for each chipset.

Another good thing about re-implementation of resource.sys. Resource.sys is a first BASEDEV to load. So, it can provide some services, available for other drivers. Like additional KEE functions and so on. Really, it's not very hard to add a function from BASEDEV into KEE library, but this addition will only available for drivers, which loaded later. Because resource.sys loaded first (this is hard coded in the OS/2 kernel), it can provide services for anyone driver.

Drivers database

For each type of PnP-aware buses we need a separate INI Section. For example, for most cases we need at least PCI_DEVICES and ACPI_DEVICES sections. Each section contain the keys for each known identifier, like "VEN_105A&DEV_4D30&SUBSYS_4D39105A", the key value is the name of driver section, where parameters are stored, like "FasttrackPCI100". So, we can have a "many-to-one" relations between device identifiers and parameters and save database size. PCI_DEVICES (and possible ACPI_DEVICES) section can have records of different types, which are processed by priority. Largest priority are taken for records with full VendorID, DeviceID and SubsysID name. If matched record not found, resource.sys will look for shortened name, without SubsysID. And, as last resort, it will look for PCI Class ID, so standard devices, like USB and IEEE1394 host controllers, can be supported with single driver binary. Driver section will have some requered fields (like FileName to load, device name for user, driver type flags(basedev/device/legacy/new), etc) and driver-specific fields. For legacy drivers (determined by type flag), resource.sys will construct command-line parameters from special database record. For new drivers, it just pass a resource manager handle, so: 1) Driver know, for which instance of supported devices it loaded 2) Driver can take HW resources used from resource manager 3) Driver can take the name of database section, used for it's loading, and read additional parameters from the database

KEE extensions

KernVMGlobalToProcess

KernVMProcessToGlobal

KernSetIRQ

KernUnsetIRQ

KernOpenEventSem KernCloseEventSem KernPostEventSem KernClearEventSem KernOpen KernClose KernRead KernWrite