Kernel Extensions

From NikiWiki
Jump to: navigation, search

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.

Proposal by Lars Erdmann

1.) I'd propose to create a 32-bit static replacement library for dhcalls.lib. Basically, for every devhelp function, it will be a thunk from 32-bit to 16-bit in order to call the devhelp function pointer passed on PDD init. I'd propose to stick to 16:16 virtual addresses for every parameter passed as a pointer. It is impossible to write a generic solution to thunk all pointers (a structure may contain pointers or structures that contain pointers etc. so this could go on ad infinitum).

> Yes, it's not possible to thunk any and all pointers, but this is not needed. We can leave existing structures as is. But for new functionality we can have pure 32-bit pointers. About static library - I think it's better to have needed functions added into KEE.


2.) Instead, I'd propose to create DosSelToFlat and DosFlatToSel (callable from 32-bit code) callable on any virtual or linear address, respectively. DosSelToFlat can directly map to the already existing function KernSelToFlat (most likely KernSelToFlat does this: it scans LDT and GDT from the selector, gets the base address and adds the offset). DosFlatToSel has yet to be written and I have already written a 32-bit sample driver that contains it. My implementation allows the developer to select on what selector he wants to have the conversion done (obviously, the developer needs to have a clear view in what segments some code or data address is located).This is due to the fact that mapping from linear to virtual addresses is not unique (in contrast to mapping from virtual to linear). Alternativly it could be implemented as is done in OPENJFS where the flat address is passed as the only parameter and a comparision against a list of segments is done (in case of OPENJFS, the 16-bit code segment, the 16-bit data segment and any dynamically created data segment). Doing it that way has the advantage that making use of the automatic thunking feature of VAC (that translates into the calls to DosSelToFlat and DosFlatToSel) and specifying /NOE (don't search extended library) and instead linking in the custom DosSelToFlat and DosFlatToSel will allow the programmer to use the automatic thunking feature of the compiler (the custom implementations of DosSelToFlat and DosFlatToSel will be called) !

3.) Likewise I would implement a 32-bit static library that implements the FSH functions. Again it thunks from 32-bit to 16-bit code to call the original FSH functions.

> I can't say anything about FSH, was not looked into yet.

For 1.), 2.) and 3.) I could provide a sample 32-bit driver that conceptually implements as described above (without having created static libraries yet).

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