[BACK]Return to SWGotchas.wn CVS log [TXT] [DIR] Up to [Apple Darwin 0.x] / driverkit / doc / OLD_NRW

Annotation of driverkit/doc/OLD_NRW/SWGotchas.wn, revision 1.1.1.1

1.1       root        1: u-/����������       �*C�d99�&&dHH&d�/dr&�Qr&�QDda������d-/����������     �*C�d99�&&dHH&d�/da&�Qa&�QDdPrrr��







&
88xHH�/d&[(�HHd&d&&&&&'&&&�@%�Z
                      2: Z&�0���Devices Project "Gotchas"

�l
                      3: 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
                      4: Z&�0���Devices Project "Gotchas"

�l
                      5: 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
                      6: Z&�0���Devices Project "Gotchas"

�l
                      7: 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
unix.superglobalmegacorp.com

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