driverkit/doc/OLD_NRW/SWGotchas.wn - view

File: [Apple Darwin 0.x] / driverkit / doc / OLD_NRW / SWGotchas.wn
Revision 1.1.1.1 (vendor branch): download - view: text, annotated - select for diffs
Tue Apr 24 17:37:51 2018 UTC (8 years, 3 months ago) by root
Branches: MAIN, Apple
CVS tags: HEAD, Darwin03, Darwin02

Darwin 0.2 Driver Kit

u-/�� *C�d99�dHHd�/dr�Qr�QDda��d-/�� *C�d99�dHHd�/da�Qa�QDdPrrr�� 88xHH�/d[(�HHdd'�@%�Z Z�0��Devices Project "Gotchas" �l Q�@�`0�* Mach vm calls (vm_allocate(), vm_copy(), etc.) made in the kernel need to cast the return from IOTaskSelf() to a type vm_task_t. This is because of a problem in the definition of vm_task_t; in user space it's a port_t, but in the kernel it's a vm_map_t. Actually in code using libIO, KERNEL and KERNL_FEATURES are both defined, so the first argument to vm_allocate is in fact a port_t. But in mach_types, vm_task_t ends up being a vm_map_t because its type isn't affected by the value of KERNEL_FEATURES. This whole mess, in which data types are redefined inside and outside of the kernel, needs a lot of work. For now, just cast IOTaskSelf() to a vm_task_t for vm calls to avoid compiler warnings; the code will do the right thing. d��Z Z�0��Devices Project "Gotchas" �l Q�@�`0�* Mach vm calls (vm_allocate(), vm_copy(), etc.) made in the kernel need to cast the return from IOTaskSelf() to a type vm_task_t. This is because of a problem in the definition of vm_task_t; in user space it's a port_t, but in the kernel it's a vm_map_t. Actually in code using libIO, KERNEL and KERNL_FEATURES are both defined, so the first argument to vm_allocate is in fact a port_t. But in mach_types, vm_task_t ends up being a vm_map_t because its type isn't affected by the value of KERNEL_FEATURES. This whole mess, in which data types are redefined inside and outside of the kernel, needs a lot of work. For now, just cast IOTaskSelf() to a vm_task_t for vm calls to avoid compiler warnings; the code will do the right thing. * All of the mach RPCs done by drivers (port_allocate(), vm_allocate(), etc.) must be done from a thread in the IO task. Thus driver probe calls must be done from a thread in this task, not from the initial kernel startup code. d�4q�Z Z�0��Devices Project "Gotchas" �l Q�@�`0�* Mach vm calls (vm_allocate(), vm_copy(), etc.) made in the kernel need to cast the return from IOTaskSelf() to a type vm_task_t. This is because of a problem in the definition of vm_task_t; in user space it's a port_t, but in the kernel it's a vm_map_t. Actually in code using libIO, KERNEL and KERNL_FEATURES are both defined, so the first argument to vm_allocate is in fact a port_t. But in mach_types, vm_task_t ends up being a vm_map_t because its type isn't affected by the value of KERNEL_FEATURES. This whole mess, in which data types are redefined inside and outside of the kernel, needs a lot of work. For now, just cast IOTaskSelf() to a vm_task_t for vm calls to avoid compiler warnings; the code will do the right thing. * All of the mach RPCs done by drivers (port_allocate(), vm_allocate(), etc.) must be done from a thread in the IO task. Thus driver probe calls must be done from a thread in this task, not from the initial kernel startup code. Alternatively, could require that drivers allocate their ports and so forth from their I/O threads... d �Pa d �Pr

This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.