Kernel Extensions - Revision history

Lightelf: /* Proposal by Lars Erdmann */

2007-01-09T16:13:32Z

Proposal by Lars Erdmann

← Older revision		Revision as of 18:13, 9 January 2007
Line 33:		Line 33:

	>		>

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

Lightelf: /* Proposal by Lars Erdmann */

2007-01-09T16:13:07Z

Proposal by Lars Erdmann

← Older revision		Revision as of 18:13, 9 January 2007
Line 19:		Line 19:

	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).		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.		2.) Instead, I'd propose to create DosSelToFlat and DosFlatToSel (callable from 32-bit code) callable on any virtual or linear address, respectively.
Line 27:		Line 32:
	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.		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.

	~~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).		>

			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==		==Drivers database==

Ktk at 15:49, 9 January 2007

2007-01-09T15:49:47Z

← Older revision		Revision as of 17:49, 9 January 2007
Line 16:		Line 16:
	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.		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===		==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).

			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.

			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.		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.		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.
Line 25:		Line 39:


	===KEE extensions===		==KEE extensions==
	KernVMGlobalToProcess		KernVMGlobalToProcess

Lightelf: /* KEE extensions */

2007-01-09T13:49:14Z

KEE extensions

← Older revision		Revision as of 15:49, 9 January 2007
Line 35:		Line 35:

	KernOpenEventSem		KernOpenEventSem

	KernCloseEventSem		KernCloseEventSem

	KernPostEventSem		KernPostEventSem

	KernClearEventSem		KernClearEventSem

	KernOpen		KernOpen

	KernClose		KernClose

	KernRead		KernRead

	KernWrite		KernWrite

Lightelf: /* KEE extensions */

2007-01-09T13:48:55Z

KEE extensions

← Older revision		Revision as of 15:48, 9 January 2007
Line 27:		Line 27:
	===KEE extensions===		===KEE extensions===
	KernVMGlobalToProcess		KernVMGlobalToProcess

	KernVMProcessToGlobal		KernVMProcessToGlobal

	KernSetIRQ		KernSetIRQ

	KernUnsetIRQ		KernUnsetIRQ

	KernOpenEventSem		KernOpenEventSem
	KernCloseEventSem		KernCloseEventSem

Lightelf at 13:45, 9 January 2007

2007-01-09T13:45:47Z

← Older revision		Revision as of 15:45, 9 January 2007
Line 23:		Line 23:
	2) Driver can take HW resources used from resource manager		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		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

Lightelf at 13:33, 9 January 2007

2007-01-09T13:33:10Z

← Older revision		Revision as of 15:33, 9 January 2007
Line 16:		Line 16:
	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.		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.		===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.		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.		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.

Lightelf at 13:30, 9 January 2007

2007-01-09T13:30:02Z

← Older revision		Revision as of 15:30, 9 January 2007
Line 15:		Line 15:
	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.		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.		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

Ktk at 03:03, 29 December 2006

2006-12-29T03:03:12Z

← Older revision		Revision as of 05:03, 29 December 2006
Line 1:		Line 1:
			[[Category:Ideas]]
	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.		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.

Ktk at 13:20, 28 December 2006

2006-12-28T13:20:15Z

← Older revision		Revision as of 15:20, 28 December 2006
Line 1:		Line 1:
			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.		Some ideas about changes, which can and (from my point of view), must be implemented.
	Background.		===Background===
	Resource.sys basedev present for long time. It is ~~resposible~~ 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.		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.		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.		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.
Line 9:		Line 13:

	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.		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 ~~hardcoded~~ in the OS/2 kernel), it can provide services for anyone driver.		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.