Aren
/
NetBSD
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
NetBSD/sys/compat/mach/mach_services.master

482 lines
12 KiB
Plaintext
Raw Normal View History

merge ktrace-lwp.
2005-12-11 15:16:03 +03:00
$NetBSD: mach_services.master,v 1.13 2005/12/11 12:20:20 christos Exp $
Enforce good santity checks with Mach messages sizes: 1) make sure Mach servers will not work on data beyond the end of the request message buffer. 2) make sure that on copying out the reply message buffer, we will not leak kernel data located after the buffer. 3) make sure that the server will not overwrite memory beyond the end of the reply message buffer. That check is the responsability of the server, there is just a DIAGNOSTIC test to check everything is in good shape. All currently implemented servers in NetBSD have been modified to check for this condition While we are here, build the mach services table (formerly in mach_namemap.c) and the services prototypes automatically from mach_services.master, just as this is done for system calls. The next step would be to fold the message formats in the mach_services.master file, but this tends to be difficult, as some messages are quite long and complex.
2003-11-13 16:40:39 +03:00
;
nuke trailing whitespace
2005-02-27 01:58:54 +03:00
; Mach services list.
Enforce good santity checks with Mach messages sizes: 1) make sure Mach servers will not work on data beyond the end of the request message buffer. 2) make sure that on copying out the reply message buffer, we will not leak kernel data located after the buffer. 3) make sure that the server will not overwrite memory beyond the end of the reply message buffer. That check is the responsability of the server, there is just a DIAGNOSTIC test to check everything is in good shape. All currently implemented servers in NetBSD have been modified to check for this condition While we are here, build the mach services table (formerly in mach_namemap.c) and the services prototypes automatically from mach_services.master, just as this is done for system calls. The next step would be to fold the message formats in the mach_services.master file, but this tends to be difficult, as some messages are quite long and complex.
2003-11-13 16:40:39 +03:00
;
#include <sys/types.h>
#include <sys/param.h>
nuke trailing whitespace
2005-02-27 01:58:54 +03:00
Enforce good santity checks with Mach messages sizes: 1) make sure Mach servers will not work on data beyond the end of the request message buffer. 2) make sure that on copying out the reply message buffer, we will not leak kernel data located after the buffer. 3) make sure that the server will not overwrite memory beyond the end of the reply message buffer. That check is the responsability of the server, there is just a DIAGNOSTIC test to check everything is in good shape. All currently implemented servers in NetBSD have been modified to check for this condition While we are here, build the mach services table (formerly in mach_namemap.c) and the services prototypes automatically from mach_services.master, just as this is done for system calls. The next step would be to fold the message formats in the mach_services.master file, but this tends to be difficult, as some messages are quite long and complex.
2003-11-13 16:40:39 +03:00
#include <compat/mach/mach_types.h>
#include <compat/mach/mach_message.h>
#include <compat/mach/mach_bootstrap.h>
#include <compat/mach/mach_iokit.h>
#include <compat/mach/mach_clock.h>
#include <compat/mach/mach_host.h>
#include <compat/mach/mach_port.h>
#include <compat/mach/mach_task.h>
#include <compat/mach/mach_thread.h>
#include <compat/mach/mach_semaphore.h>
More work on exceptions. Once a task has raised an exception, it remains blocked in the kernel. The task that catched the exception may unblock it by sending a reply to the exception message (Of course it will have to change something so that the exception is not immediatly raised again). Handling of this reply is a bit complicated, as the kernel acts as the client instead of the server. In this situation, we receive a message but we will not send any reply (the message we receive is already a reply). I have not found anything better than a special case in mach_msg_overwrite_trap() to handle this. A surprise: exceptions ports are preserved accross forks. While we are there, use appropriate 64 bit types for make_memory_entry_64.
2003-11-18 04:40:18 +03:00
#include <compat/mach/mach_notify.h>
Move exception related code to a dedicated file
2003-12-09 15:13:44 +03:00
#include <compat/mach/mach_exception.h>
Enforce good santity checks with Mach messages sizes: 1) make sure Mach servers will not work on data beyond the end of the request message buffer. 2) make sure that on copying out the reply message buffer, we will not leak kernel data located after the buffer. 3) make sure that the server will not overwrite memory beyond the end of the reply message buffer. That check is the responsability of the server, there is just a DIAGNOSTIC test to check everything is in good shape. All currently implemented servers in NetBSD have been modified to check for this condition While we are here, build the mach services table (formerly in mach_namemap.c) and the services prototypes automatically from mach_services.master, just as this is done for system calls. The next step would be to fold the message formats in the mach_services.master file, but this tends to be difficult, as some messages are quite long and complex.
2003-11-13 16:40:39 +03:00
#include <compat/mach/mach_vm.h>
#include <compat/mach/mach_services.h>
%%
Try to add all mach servers defined in Darwin in the server list. Most of them will never be implemented, of course.
2003-11-15 20:44:38 +03:00
;
; Port Notification messages
;
64 OBSOL notify_first
First work on Mach exceptions. Things that can turn into signals on UNIX may turn into exceptions on Mach: a small message sent by the kernel to the task that requested the exception. On Darwin, when an exception is sent, no signal can be delivered. TODO: more exceptions: arithmetic, bad instructions, emulation, s software, and syscalls (plain and Mach). There is also RPC alert, but I have no idea about what it is. While we are there, remove some user ktrace in notification code, and add a NODEF qualifier in mach_services.master: it will be used for notifications and exceptions, where the kernel is always client and never server: we don't want the message to be displayed as "unimplemented xxx" in kdump (thus UNIMPL is not good), but we don't want to generate the server prototype (therefore, STD is not good either). NODEF will declare it normally in the name tables without creating the prototype.
2003-11-17 04:52:14 +03:00
65 NODEF notify_port_deleted
Try to add all mach servers defined in Darwin in the server list. Most of them will never be implemented, of course.
2003-11-15 20:44:38 +03:00
66 OBSOL notify_msg_accepted
67 OBSOL notify_ownership_rights
68 OBSOL notify_receive_rights
First work on Mach exceptions. Things that can turn into signals on UNIX may turn into exceptions on Mach: a small message sent by the kernel to the task that requested the exception. On Darwin, when an exception is sent, no signal can be delivered. TODO: more exceptions: arithmetic, bad instructions, emulation, s software, and syscalls (plain and Mach). There is also RPC alert, but I have no idea about what it is. While we are there, remove some user ktrace in notification code, and add a NODEF qualifier in mach_services.master: it will be used for notifications and exceptions, where the kernel is always client and never server: we don't want the message to be displayed as "unimplemented xxx" in kdump (thus UNIMPL is not good), but we don't want to generate the server prototype (therefore, STD is not good either). NODEF will declare it normally in the name tables without creating the prototype.
2003-11-17 04:52:14 +03:00
69 NODEF notify_port_destroyed
70 NODEF notify_port_no_senders
71 NODEF notify_port_send_once
72 NODEF notify_port_dead_name
Try to add all mach servers defined in Darwin in the server list. Most of them will never be implemented, of course.
2003-11-15 20:44:38 +03:00
;
; Host subsystem
;
Enforce good santity checks with Mach messages sizes: 1) make sure Mach servers will not work on data beyond the end of the request message buffer. 2) make sure that on copying out the reply message buffer, we will not leak kernel data located after the buffer. 3) make sure that the server will not overwrite memory beyond the end of the reply message buffer. That check is the responsability of the server, there is just a DIAGNOSTIC test to check everything is in good shape. All currently implemented servers in NetBSD have been modified to check for this condition While we are here, build the mach services table (formerly in mach_namemap.c) and the services prototypes automatically from mach_services.master, just as this is done for system calls. The next step would be to fold the message formats in the mach_services.master file, but this tends to be difficult, as some messages are quite long and complex.
2003-11-13 16:40:39 +03:00
200 STD host_info
Try to add all mach servers defined in Darwin in the server list. Most of them will never be implemented, of course.
2003-11-15 20:44:38 +03:00
201 UNIMPL host_kernel_version
Enforce good santity checks with Mach messages sizes: 1) make sure Mach servers will not work on data beyond the end of the request message buffer. 2) make sure that on copying out the reply message buffer, we will not leak kernel data located after the buffer. 3) make sure that the server will not overwrite memory beyond the end of the reply message buffer. That check is the responsability of the server, there is just a DIAGNOSTIC test to check everything is in good shape. All currently implemented servers in NetBSD have been modified to check for this condition While we are here, build the mach services table (formerly in mach_namemap.c) and the services prototypes automatically from mach_services.master, just as this is done for system calls. The next step would be to fold the message formats in the mach_services.master file, but this tends to be difficult, as some messages are quite long and complex.
2003-11-13 16:40:39 +03:00
202 STD host_page_size
Try to add all mach servers defined in Darwin in the server list. Most of them will never be implemented, of course.
2003-11-15 20:44:38 +03:00
203 UNIMPL memory_object_memory_entry
204 UNIMPL host_processor_info
Enforce good santity checks with Mach messages sizes: 1) make sure Mach servers will not work on data beyond the end of the request message buffer. 2) make sure that on copying out the reply message buffer, we will not leak kernel data located after the buffer. 3) make sure that the server will not overwrite memory beyond the end of the reply message buffer. That check is the responsability of the server, there is just a DIAGNOSTIC test to check everything is in good shape. All currently implemented servers in NetBSD have been modified to check for this condition While we are here, build the mach services table (formerly in mach_namemap.c) and the services prototypes automatically from mach_services.master, just as this is done for system calls. The next step would be to fold the message formats in the mach_services.master file, but this tends to be difficult, as some messages are quite long and complex.
2003-11-13 16:40:39 +03:00
205 STD host_get_io_master
206 STD host_get_clock_service
Try to add all mach servers defined in Darwin in the server list. Most of them will never be implemented, of course.
2003-11-15 20:44:38 +03:00
207 UNIMPL kmod_get_info
208 UNIMPL host_zone_info
209 UNIMPL host_virtual_physical_table_info
210 UNIMPL host_ipc_hash_info
; Probably Darwin specific...
211 UNIMPL enable_bluebox
212 UNIMPL disable_bluebox
Added Mach services (no real implementation, just empty shells to make userland happy) processor_set_default, host_processor_set_priv, and thread_set_policy
2003-12-29 04:30:27 +03:00
213 STD processor_set_default
Try to add all mach servers defined in Darwin in the server list. Most of them will never be implemented, of course.
2003-11-15 20:44:38 +03:00
214 UNIMPL processor_set_create
215 UNIMPL memory_object_memory_entry_64
216 UNIMPL host_statistics
;
; Host subsystem (private)
;
400 UNIMPL host_get_boot_info
401 UNIMPL host_reboot
402 UNIMPL host_priv_statistics
Added port_get_refs and port_mod_refs
2004-07-24 19:46:02 +04:00
; Implemented by mach_init, clashes with host_default_memory_manager
403 UNIMPL boostrap_register
; Implemented by mach_init, clashes with vm_wire
nuke trailing whitespace
2005-02-27 01:58:54 +03:00
404 STD bootstrap_look_up
Try to add all mach servers defined in Darwin in the server list. Most of them will never be implemented, of course.
2003-11-15 20:44:38 +03:00
405 UNIMPL thread_wire
406 UNIMPL vm_allocate_cpm
407 UNIMPL host_processors
408 UNIMPL host_get_clock_control
409 UNIMPL kmod_create
410 UNIMPL kmod_destroy
411 UNIMPL kmod_control
412 UNIMPL host_get_special_port
413 UNIMPL host_set_special_port
414 UNIMPL host_set_exception_ports
415 UNIMPL host_get_exception_ports
416 UNIMPL host_swap_exception_ports
417 UNIMPL host_load_symbol_table
418 UNIMPL task_swappable
419 UNIMPL host_processor_sets
Added Mach services (no real implementation, just empty shells to make userland happy) processor_set_default, host_processor_set_priv, and thread_set_policy
2003-12-29 04:30:27 +03:00
420 STD host_processor_set_priv
Try to add all mach servers defined in Darwin in the server list. Most of them will never be implemented, of course.
2003-11-15 20:44:38 +03:00
421 UNIMPL set_dp_control_port
422 UNIMPL get_dp_control_port
423 UNIMPL host_set_UNDServer
424 UNIMPL host_get_UNDServer
;
; Host security
;
600 UNIMPL host_security_create_task_token
601 UNIMPL host_security_set_task_token
;
; Clock subsystem
;
Enforce good santity checks with Mach messages sizes: 1) make sure Mach servers will not work on data beyond the end of the request message buffer. 2) make sure that on copying out the reply message buffer, we will not leak kernel data located after the buffer. 3) make sure that the server will not overwrite memory beyond the end of the reply message buffer. That check is the responsability of the server, there is just a DIAGNOSTIC test to check everything is in good shape. All currently implemented servers in NetBSD have been modified to check for this condition While we are here, build the mach services table (formerly in mach_namemap.c) and the services prototypes automatically from mach_services.master, just as this is done for system calls. The next step would be to fold the message formats in the mach_services.master file, but this tends to be difficult, as some messages are quite long and complex.
2003-11-13 16:40:39 +03:00
1000 STD clock_get_time
Try to add all mach servers defined in Darwin in the server list. Most of them will never be implemented, of course.
2003-11-15 20:44:38 +03:00
1001 UNIMPL clock_get_attributes
1002 UNIMPL clock_alarm
;
; Clock subsystem (private)
;
1200 UNIMPL clock_set_time
1201 UNIMPL clock_set_attributes
;
; Memoey management
;
2000 UNIMPL memory_object_get_attributes
2001 UNIMPL memory_object_change_attributes
2002 UNIMPL memory_object_synchronize_completed
2003 UNIMPL memory_object_lock_request
2004 UNIMPL memory_object_destroy
2005 UNIMPL memory_object_upl_request
2006 UNIMPL memory_object_super_upl_request
2007 UNIMPL memory_object_page_op
2008 UNIMPL memory_object_recover_named
2009 UNIMPL memory_object_release_name
;
; UPL (External memory management)
;
2050 UNIMPL upl_abort
2051 UNIMPL upl_abort_range
2052 UNIMPL upl_commit
2053 UNIMPL upl_commit_range
;
; Memory management (control)
;
2200 UNIMPL memory_object_init
2201 UNIMPL memory_object_terminate
2202 UNIMPL memory_object_data_request
2203 UNIMPL memory_object_data_return
2204 UNIMPL memory_object_data_initialize
2205 UNIMPL memory_object_data_unlock
2206 UNIMPL memory_object_synchronize
2207 UNIMPL memory_object_unmap
;
; Memory management (default)
;
2250 UNIMPL memory_object_create
;
; Default pager (object)
;
2275 UNIMPL default_pager_object_create
2276 UNIMPL default_pager_info
2277 UNIMPL default_pager_objects
2278 UNIMPL default_pager_object_pages
2279 UNIMPL default_pager_backing_store_create
2280 UNIMPL default_pager_backing_store_delete
2281 UNIMPL default_pager_add_segment
2282 UNIMPL default_pager_backing_store_info
2283 UNIMPL default_pager_add_file
2284 UNIMPL default_pager_triggers
;
; Default pager (alerts)
;
2295 UNIMPL default_pager_space_alert
;
; Mach exception interface
;
First work on Mach exceptions. Things that can turn into signals on UNIX may turn into exceptions on Mach: a small message sent by the kernel to the task that requested the exception. On Darwin, when an exception is sent, no signal can be delivered. TODO: more exceptions: arithmetic, bad instructions, emulation, s software, and syscalls (plain and Mach). There is also RPC alert, but I have no idea about what it is. While we are there, remove some user ktrace in notification code, and add a NODEF qualifier in mach_services.master: it will be used for notifications and exceptions, where the kernel is always client and never server: we don't want the message to be displayed as "unimplemented xxx" in kdump (thus UNIMPL is not good), but we don't want to generate the server prototype (therefore, STD is not good either). NODEF will declare it normally in the name tables without creating the prototype.
2003-11-17 04:52:14 +03:00
2401 NODEF exception_raise
2402 NODEF exception_raise_state
2403 NODEF exception_raise_state_identity
Try to add all mach servers defined in Darwin in the server list. Most of them will never be implemented, of course.
2003-11-15 20:44:38 +03:00
;
; Profiling
;
2450 UNIMPL samples
2451 UNIMPL notices
More work on exceptions. Once a task has raised an exception, it remains blocked in the kernel. The task that catched the exception may unblock it by sending a reply to the exception message (Of course it will have to change something so that the exception is not immediatly raised again). Handling of this reply is a bit complicated, as the kernel acts as the client instead of the server. In this situation, we receive a message but we will not send any reply (the message we receive is already a reply). I have not found anything better than a special case in mach_msg_overwrite_trap() to handle this. A surprise: exceptions ports are preserved accross forks. While we are there, use appropriate 64 bit types for make_memory_entry_64.
2003-11-18 04:40:18 +03:00
;
nuke trailing whitespace
2005-02-27 01:58:54 +03:00
; Mach exception Replies.
; Defined because the kernel is the client here:
More work on exceptions. Once a task has raised an exception, it remains blocked in the kernel. The task that catched the exception may unblock it by sending a reply to the exception message (Of course it will have to change something so that the exception is not immediatly raised again). Handling of this reply is a bit complicated, as the kernel acts as the client instead of the server. In this situation, we receive a message but we will not send any reply (the message we receive is already a reply). I have not found anything better than a special case in mach_msg_overwrite_trap() to handle this. A surprise: exceptions ports are preserved accross forks. While we are there, use appropriate 64 bit types for make_memory_entry_64.
2003-11-18 04:40:18 +03:00
; it has to handle replies instead of reequest.
;
2501 STD exception_raise
2502 STD exception_raise_state
2503 STD exception_raise_state_identity
Try to add all mach servers defined in Darwin in the server list. Most of them will never be implemented, of course.
2003-11-15 20:44:38 +03:00
;
; Mach IOKit
;
Enforce good santity checks with Mach messages sizes: 1) make sure Mach servers will not work on data beyond the end of the request message buffer. 2) make sure that on copying out the reply message buffer, we will not leak kernel data located after the buffer. 3) make sure that the server will not overwrite memory beyond the end of the reply message buffer. That check is the responsability of the server, there is just a DIAGNOSTIC test to check everything is in good shape. All currently implemented servers in NetBSD have been modified to check for this condition While we are here, build the mach services table (formerly in mach_namemap.c) and the services prototypes automatically from mach_services.master, just as this is done for system calls. The next step would be to fold the message formats in the mach_services.master file, but this tends to be difficult, as some messages are quite long and complex.
2003-11-13 16:40:39 +03:00
2800 STD io_object_get_class
2801 STD io_object_conforms_to
2802 STD io_iterator_next
2803 STD io_iterator_reset
nuke trailing whitespace
2005-02-27 01:58:54 +03:00
2804 STD io_service_get_matching_services
Enforce good santity checks with Mach messages sizes: 1) make sure Mach servers will not work on data beyond the end of the request message buffer. 2) make sure that on copying out the reply message buffer, we will not leak kernel data located after the buffer. 3) make sure that the server will not overwrite memory beyond the end of the reply message buffer. That check is the responsability of the server, there is just a DIAGNOSTIC test to check everything is in good shape. All currently implemented servers in NetBSD have been modified to check for this condition While we are here, build the mach services table (formerly in mach_namemap.c) and the services prototypes automatically from mach_services.master, just as this is done for system calls. The next step would be to fold the message formats in the mach_services.master file, but this tends to be difficult, as some messages are quite long and complex.
2003-11-13 16:40:39 +03:00
2805 STD io_registry_entry_get_property
Try to add all mach servers defined in Darwin in the server list. Most of them will never be implemented, of course.
2003-11-15 20:44:38 +03:00
2806 UNIMPL io_registry_create_iterator
2807 UNIMPL io_registry_iterator_enter_entry
2808 UNIMPL io_registry_iterator_exit_entry
nuke trailing whitespace
2005-02-27 01:58:54 +03:00
2809 STD io_registry_entry_from_path
Try to add all mach servers defined in Darwin in the server list. Most of them will never be implemented, of course.
2003-11-15 20:44:38 +03:00
2810 UNIMPL io_registry_entry_get_name
Enforce good santity checks with Mach messages sizes: 1) make sure Mach servers will not work on data beyond the end of the request message buffer. 2) make sure that on copying out the reply message buffer, we will not leak kernel data located after the buffer. 3) make sure that the server will not overwrite memory beyond the end of the reply message buffer. That check is the responsability of the server, there is just a DIAGNOSTIC test to check everything is in good shape. All currently implemented servers in NetBSD have been modified to check for this condition While we are here, build the mach services table (formerly in mach_namemap.c) and the services prototypes automatically from mach_services.master, just as this is done for system calls. The next step would be to fold the message formats in the mach_services.master file, but this tends to be difficult, as some messages are quite long and complex.
2003-11-13 16:40:39 +03:00
2811 STD io_registry_entry_get_properties
Try to add all mach servers defined in Darwin in the server list. Most of them will never be implemented, of course.
2003-11-15 20:44:38 +03:00
2812 UNIMPL io_registry_entry_get_property_bytes
Enforce good santity checks with Mach messages sizes: 1) make sure Mach servers will not work on data beyond the end of the request message buffer. 2) make sure that on copying out the reply message buffer, we will not leak kernel data located after the buffer. 3) make sure that the server will not overwrite memory beyond the end of the reply message buffer. That check is the responsability of the server, there is just a DIAGNOSTIC test to check everything is in good shape. All currently implemented servers in NetBSD have been modified to check for this condition While we are here, build the mach services table (formerly in mach_namemap.c) and the services prototypes automatically from mach_services.master, just as this is done for system calls. The next step would be to fold the message formats in the mach_services.master file, but this tends to be difficult, as some messages are quite long and complex.
2003-11-13 16:40:39 +03:00
2813 STD io_registry_entry_get_child_iterator
2814 STD io_registry_entry_get_parent_iterator
2815 STD io_service_open
2816 STD io_service_close
2817 STD io_connect_get_service
2818 STD io_connect_set_notification_port
2819 STD io_connect_map_memory
2820 STD io_connect_add_client
2821 STD io_connect_set_properties
2822 STD io_connect_method_scalari_scalaro
2823 STD io_connect_method_scalari_structo
nuke trailing whitespace
2005-02-27 01:58:54 +03:00
2824 STD io_connect_method_scalari_structi
Enforce good santity checks with Mach messages sizes: 1) make sure Mach servers will not work on data beyond the end of the request message buffer. 2) make sure that on copying out the reply message buffer, we will not leak kernel data located after the buffer. 3) make sure that the server will not overwrite memory beyond the end of the reply message buffer. That check is the responsability of the server, there is just a DIAGNOSTIC test to check everything is in good shape. All currently implemented servers in NetBSD have been modified to check for this condition While we are here, build the mach services table (formerly in mach_namemap.c) and the services prototypes automatically from mach_services.master, just as this is done for system calls. The next step would be to fold the message formats in the mach_services.master file, but this tends to be difficult, as some messages are quite long and complex.
2003-11-13 16:40:39 +03:00
2825 STD io_connect_method_structi_structo
2826 STD io_registry_entry_get_path
2827 STD io_registry_get_root_entry
Try to add all mach servers defined in Darwin in the server list. Most of them will never be implemented, of course.
2003-11-15 20:44:38 +03:00
2828 UNIMPL io_registry_entry_set_properties
2829 UNIMPL io_registry_entry_in_plane
2830 UNIMPL io_object_get_retain_count
2831 UNIMPL io_service_get_busy_state
2832 UNIMPL io_service_wait_quiet
Enforce good santity checks with Mach messages sizes: 1) make sure Mach servers will not work on data beyond the end of the request message buffer. 2) make sure that on copying out the reply message buffer, we will not leak kernel data located after the buffer. 3) make sure that the server will not overwrite memory beyond the end of the reply message buffer. That check is the responsability of the server, there is just a DIAGNOSTIC test to check everything is in good shape. All currently implemented servers in NetBSD have been modified to check for this condition While we are here, build the mach services table (formerly in mach_namemap.c) and the services prototypes automatically from mach_services.master, just as this is done for system calls. The next step would be to fold the message formats in the mach_services.master file, but this tends to be difficult, as some messages are quite long and complex.
2003-11-13 16:40:39 +03:00
2833 STD io_registry_entry_create_iterator
Try to add all mach servers defined in Darwin in the server list. Most of them will never be implemented, of course.
2003-11-15 20:44:38 +03:00
2834 UNIMPL io_iterator_is_valid
2835 UNIMPL io_make_matching
2836 UNIMPL io_catalog_send_data
2837 UNIMPL io_catalog_terminate
2838 UNIMPL io_catalog_get_data
2839 UNIMPL io_catalog_get_gen_count
2840 UNIMPL io_catalog_module_loaded
2841 UNIMPL io_catalog_reset
2842 UNIMPL io_service_request_probe
Enforce good santity checks with Mach messages sizes: 1) make sure Mach servers will not work on data beyond the end of the request message buffer. 2) make sure that on copying out the reply message buffer, we will not leak kernel data located after the buffer. 3) make sure that the server will not overwrite memory beyond the end of the reply message buffer. That check is the responsability of the server, there is just a DIAGNOSTIC test to check everything is in good shape. All currently implemented servers in NetBSD have been modified to check for this condition While we are here, build the mach services table (formerly in mach_namemap.c) and the services prototypes automatically from mach_services.master, just as this is done for system calls. The next step would be to fold the message formats in the mach_services.master file, but this tends to be difficult, as some messages are quite long and complex.
2003-11-13 16:40:39 +03:00
2843 STD io_registry_entry_get_name_in_plane
Try to add all mach servers defined in Darwin in the server list. Most of them will never be implemented, of course.
2003-11-15 20:44:38 +03:00
2844 UNIMPL io_service_match_property_table
2845 UNIMPL io_async_method_scalari_scalaro
2846 UNIMPL io_async_method_scalari_structo
2847 UNIMPL io_async_method_scalari_structi
2848 UNIMPL io_async_method_structi_structo
2849 UNIMPL io_service_add_notification
Enforce good santity checks with Mach messages sizes: 1) make sure Mach servers will not work on data beyond the end of the request message buffer. 2) make sure that on copying out the reply message buffer, we will not leak kernel data located after the buffer. 3) make sure that the server will not overwrite memory beyond the end of the reply message buffer. That check is the responsability of the server, there is just a DIAGNOSTIC test to check everything is in good shape. All currently implemented servers in NetBSD have been modified to check for this condition While we are here, build the mach services table (formerly in mach_namemap.c) and the services prototypes automatically from mach_services.master, just as this is done for system calls. The next step would be to fold the message formats in the mach_services.master file, but this tends to be difficult, as some messages are quite long and complex.
2003-11-13 16:40:39 +03:00
2850 STD io_service_add_interest_notification
Try to add all mach servers defined in Darwin in the server list. Most of them will never be implemented, of course.
2003-11-15 20:44:38 +03:00
2851 UNIMPL io_service_acknowledge_notification
2852 UNIMPL io_connect_get_notification_semaphore
2853 UNIMPL io_connect_unmap_memory
Enforce good santity checks with Mach messages sizes: 1) make sure Mach servers will not work on data beyond the end of the request message buffer. 2) make sure that on copying out the reply message buffer, we will not leak kernel data located after the buffer. 3) make sure that the server will not overwrite memory beyond the end of the reply message buffer. That check is the responsability of the server, there is just a DIAGNOSTIC test to check everything is in good shape. All currently implemented servers in NetBSD have been modified to check for this condition While we are here, build the mach services table (formerly in mach_namemap.c) and the services prototypes automatically from mach_services.master, just as this is done for system calls. The next step would be to fold the message formats in the mach_services.master file, but this tends to be difficult, as some messages are quite long and complex.
2003-11-13 16:40:39 +03:00
2854 STD io_registry_entry_get_location_in_plane
Try to add all mach servers defined in Darwin in the server list. Most of them will never be implemented, of course.
2003-11-15 20:44:38 +03:00
2855 UNIMPL io_registry_entry_get_property_recursively
;
; Processor subsystem
;
3000 UNIMPL processor_start
3001 UNIMPL processor_exit
3002 UNIMPL processor_info
3003 UNIMPL processor_control
3004 UNIMPL processor_assign
3005 UNIMPL processor_get_assignment
;
; Mach ports
;
3200 UNIMPL port_names
Enforce good santity checks with Mach messages sizes: 1) make sure Mach servers will not work on data beyond the end of the request message buffer. 2) make sure that on copying out the reply message buffer, we will not leak kernel data located after the buffer. 3) make sure that the server will not overwrite memory beyond the end of the reply message buffer. That check is the responsability of the server, there is just a DIAGNOSTIC test to check everything is in good shape. All currently implemented servers in NetBSD have been modified to check for this condition While we are here, build the mach services table (formerly in mach_namemap.c) and the services prototypes automatically from mach_services.master, just as this is done for system calls. The next step would be to fold the message formats in the mach_services.master file, but this tends to be difficult, as some messages are quite long and complex.
2003-11-13 16:40:39 +03:00
3201 STD port_type
Try to add all mach servers defined in Darwin in the server list. Most of them will never be implemented, of course.
2003-11-15 20:44:38 +03:00
3202 UNIMPL port_rename
3203 UNIMPL port_allocate_name
Enforce good santity checks with Mach messages sizes: 1) make sure Mach servers will not work on data beyond the end of the request message buffer. 2) make sure that on copying out the reply message buffer, we will not leak kernel data located after the buffer. 3) make sure that the server will not overwrite memory beyond the end of the reply message buffer. That check is the responsability of the server, there is just a DIAGNOSTIC test to check everything is in good shape. All currently implemented servers in NetBSD have been modified to check for this condition While we are here, build the mach services table (formerly in mach_namemap.c) and the services prototypes automatically from mach_services.master, just as this is done for system calls. The next step would be to fold the message formats in the mach_services.master file, but this tends to be difficult, as some messages are quite long and complex.
2003-11-13 16:40:39 +03:00
3204 STD port_allocate
3205 STD port_destroy
3206 STD port_deallocate
Added port_get_refs and port_mod_refs
2004-07-24 19:46:02 +04:00
3207 STD port_get_refs
3208 STD port_mod_refs
Try to add all mach servers defined in Darwin in the server list. Most of them will never be implemented, of course.
2003-11-15 20:44:38 +03:00
3210 UNIMPL port_set_mscount
3211 UNIMPL port_get_set_status
Enforce good santity checks with Mach messages sizes: 1) make sure Mach servers will not work on data beyond the end of the request message buffer. 2) make sure that on copying out the reply message buffer, we will not leak kernel data located after the buffer. 3) make sure that the server will not overwrite memory beyond the end of the reply message buffer. That check is the responsability of the server, there is just a DIAGNOSTIC test to check everything is in good shape. All currently implemented servers in NetBSD have been modified to check for this condition While we are here, build the mach services table (formerly in mach_namemap.c) and the services prototypes automatically from mach_services.master, just as this is done for system calls. The next step would be to fold the message formats in the mach_services.master file, but this tends to be difficult, as some messages are quite long and complex.
2003-11-13 16:40:39 +03:00
3212 STD port_move_member
3213 STD port_request_notification
3214 STD port_insert_right
Try to add all mach servers defined in Darwin in the server list. Most of them will never be implemented, of course.
2003-11-15 20:44:38 +03:00
3215 UNIMPL port_extract_right
3216 UNIMPL port_set_seqno
Enforce good santity checks with Mach messages sizes: 1) make sure Mach servers will not work on data beyond the end of the request message buffer. 2) make sure that on copying out the reply message buffer, we will not leak kernel data located after the buffer. 3) make sure that the server will not overwrite memory beyond the end of the reply message buffer. That check is the responsability of the server, there is just a DIAGNOSTIC test to check everything is in good shape. All currently implemented servers in NetBSD have been modified to check for this condition While we are here, build the mach services table (formerly in mach_namemap.c) and the services prototypes automatically from mach_services.master, just as this is done for system calls. The next step would be to fold the message formats in the mach_services.master file, but this tends to be difficult, as some messages are quite long and complex.
2003-11-13 16:40:39 +03:00
3217 STD port_get_attributes
3218 STD port_set_attributes
Try to add all mach servers defined in Darwin in the server list. Most of them will never be implemented, of course.
2003-11-15 20:44:38 +03:00
3219 UNIMPL port_allocate_qos
3220 UNIMPL port_allocate_full
3221 UNIMPL task_set_port_space
3222 UNIMPL port_get_srights
3223 UNIMPL port_space_info
3224 UNIMPL port_dnrequest_info
3225 UNIMPL port_kernel_object
Enforce good santity checks with Mach messages sizes: 1) make sure Mach servers will not work on data beyond the end of the request message buffer. 2) make sure that on copying out the reply message buffer, we will not leak kernel data located after the buffer. 3) make sure that the server will not overwrite memory beyond the end of the reply message buffer. That check is the responsability of the server, there is just a DIAGNOSTIC test to check everything is in good shape. All currently implemented servers in NetBSD have been modified to check for this condition While we are here, build the mach services table (formerly in mach_namemap.c) and the services prototypes automatically from mach_services.master, just as this is done for system calls. The next step would be to fold the message formats in the mach_services.master file, but this tends to be difficult, as some messages are quite long and complex.
2003-11-13 16:40:39 +03:00
3226 STD port_insert_member
Try to add all mach servers defined in Darwin in the server list. Most of them will never be implemented, of course.
2003-11-15 20:44:38 +03:00
3227 UNIMPL port_extract_member
;
; Mach tasks
;
3400 UNIMPL task_create
Add task_terminate
2003-11-30 23:42:03 +03:00
3401 STD task_terminate
Enforce good santity checks with Mach messages sizes: 1) make sure Mach servers will not work on data beyond the end of the request message buffer. 2) make sure that on copying out the reply message buffer, we will not leak kernel data located after the buffer. 3) make sure that the server will not overwrite memory beyond the end of the reply message buffer. That check is the responsability of the server, there is just a DIAGNOSTIC test to check everything is in good shape. All currently implemented servers in NetBSD have been modified to check for this condition While we are here, build the mach services table (formerly in mach_namemap.c) and the services prototypes automatically from mach_services.master, just as this is done for system calls. The next step would be to fold the message formats in the mach_services.master file, but this tends to be difficult, as some messages are quite long and complex.
2003-11-13 16:40:39 +03:00
3402 STD task_threads
Try to add all mach servers defined in Darwin in the server list. Most of them will never be implemented, of course.
2003-11-15 20:44:38 +03:00
3403 UNIMPL ports_register
Enforce good santity checks with Mach messages sizes: 1) make sure Mach servers will not work on data beyond the end of the request message buffer. 2) make sure that on copying out the reply message buffer, we will not leak kernel data located after the buffer. 3) make sure that the server will not overwrite memory beyond the end of the reply message buffer. That check is the responsability of the server, there is just a DIAGNOSTIC test to check everything is in good shape. All currently implemented servers in NetBSD have been modified to check for this condition While we are here, build the mach services table (formerly in mach_namemap.c) and the services prototypes automatically from mach_services.master, just as this is done for system calls. The next step would be to fold the message formats in the mach_services.master file, but this tends to be difficult, as some messages are quite long and complex.
2003-11-13 16:40:39 +03:00
3404 STD ports_lookup
3405 STD task_info
Try to add all mach servers defined in Darwin in the server list. Most of them will never be implemented, of course.
2003-11-15 20:44:38 +03:00
3406 UNIMPL task_set_info
Enforce good santity checks with Mach messages sizes: 1) make sure Mach servers will not work on data beyond the end of the request message buffer. 2) make sure that on copying out the reply message buffer, we will not leak kernel data located after the buffer. 3) make sure that the server will not overwrite memory beyond the end of the reply message buffer. That check is the responsability of the server, there is just a DIAGNOSTIC test to check everything is in good shape. All currently implemented servers in NetBSD have been modified to check for this condition While we are here, build the mach services table (formerly in mach_namemap.c) and the services prototypes automatically from mach_services.master, just as this is done for system calls. The next step would be to fold the message formats in the mach_services.master file, but this tends to be difficult, as some messages are quite long and complex.
2003-11-13 16:40:39 +03:00
3407 STD task_suspend
3408 STD task_resume
3409 STD task_get_special_port
3410 STD task_set_special_port
Try to add all mach servers defined in Darwin in the server list. Most of them will never be implemented, of course.
2003-11-15 20:44:38 +03:00
3411 UNIMPL thread_create
Enforce good santity checks with Mach messages sizes: 1) make sure Mach servers will not work on data beyond the end of the request message buffer. 2) make sure that on copying out the reply message buffer, we will not leak kernel data located after the buffer. 3) make sure that the server will not overwrite memory beyond the end of the reply message buffer. That check is the responsability of the server, there is just a DIAGNOSTIC test to check everything is in good shape. All currently implemented servers in NetBSD have been modified to check for this condition While we are here, build the mach services table (formerly in mach_namemap.c) and the services prototypes automatically from mach_services.master, just as this is done for system calls. The next step would be to fold the message formats in the mach_services.master file, but this tends to be difficult, as some messages are quite long and complex.
2003-11-13 16:40:39 +03:00
3412 STD thread_create_running
3413 STD task_set_exception_ports
3414 STD task_get_exception_ports
Try to add all mach servers defined in Darwin in the server list. Most of them will never be implemented, of course.
2003-11-15 20:44:38 +03:00
3415 UNIMPL task_swap_exception_ports
3416 UNIMPL lock_set_create
3417 UNIMPL lock_set_destroy
Enforce good santity checks with Mach messages sizes: 1) make sure Mach servers will not work on data beyond the end of the request message buffer. 2) make sure that on copying out the reply message buffer, we will not leak kernel data located after the buffer. 3) make sure that the server will not overwrite memory beyond the end of the reply message buffer. That check is the responsability of the server, there is just a DIAGNOSTIC test to check everything is in good shape. All currently implemented servers in NetBSD have been modified to check for this condition While we are here, build the mach services table (formerly in mach_namemap.c) and the services prototypes automatically from mach_services.master, just as this is done for system calls. The next step would be to fold the message formats in the mach_services.master file, but this tends to be difficult, as some messages are quite long and complex.
2003-11-13 16:40:39 +03:00
3418 STD semaphore_create
3419 STD semaphore_destroy
Try to add all mach servers defined in Darwin in the server list. Most of them will never be implemented, of course.
2003-11-15 20:44:38 +03:00
3420 UNIMPL task_policy_set
3421 UNIMPL task_policy_get
3422 UNIMPL task_sample
3423 UNIMPL task_policy
3424 UNIMPL task_set_emulation
3425 UNIMPL task_get_emulation_vector
3426 UNIMPL task_set_emulation_vector
3427 UNIMPL task_set_ras_pc
3428 UNIMPL kernel_task_create
3429 UNIMPL task_assign
3430 UNIMPL task_assign_default
3431 UNIMPL task_get_assignment
3432 UNIMPL task_set_policy
;
; Mach threads
;
3600 UNIMPL thread_terminate
3601 UNIMPL act_get_state
3602 UNIMPL act_set_state
Enforce good santity checks with Mach messages sizes: 1) make sure Mach servers will not work on data beyond the end of the request message buffer. 2) make sure that on copying out the reply message buffer, we will not leak kernel data located after the buffer. 3) make sure that the server will not overwrite memory beyond the end of the reply message buffer. That check is the responsability of the server, there is just a DIAGNOSTIC test to check everything is in good shape. All currently implemented servers in NetBSD have been modified to check for this condition While we are here, build the mach services table (formerly in mach_namemap.c) and the services prototypes automatically from mach_services.master, just as this is done for system calls. The next step would be to fold the message formats in the mach_services.master file, but this tends to be difficult, as some messages are quite long and complex.
2003-11-13 16:40:39 +03:00
3603 STD thread_get_state
3604 STD thread_set_state
Rework Mach exception and Darwin's ptrace. gdb is now able to attach a remote process. This new implementation also passes all the test programs I've written so far. - When exceptions come from traps, no UNIX signal should evet be sent. - Add a lock to ensure a debugger handles only one exception at a time - Use a structure to hold flavor and behavior in exception ports, instead of stuffing the two argument into an int. - Implement new Mach services: thread_suspend, thread_resume and thread_abort - Implement Darwin's ptrace PT_ATTACHEXC and PT_THUPDATE commands - Handle NULL second argument correctly in sigprocmask. - One mistake in the last commit (darwin_tracesig prototype)
2003-12-25 02:22:22 +03:00
3605 STD thread_suspend
3606 STD thread_resume
3607 STD thread_abort
Try to add all mach servers defined in Darwin in the server list. Most of them will never be implemented, of course.
2003-11-15 20:44:38 +03:00
3608 UNIMPL thread_abort_safely
3609 UNIMPL thread_depress_abort
3610 UNIMPL thread_get_special_port
3611 UNIMPL thread_set_special_port
Enforce good santity checks with Mach messages sizes: 1) make sure Mach servers will not work on data beyond the end of the request message buffer. 2) make sure that on copying out the reply message buffer, we will not leak kernel data located after the buffer. 3) make sure that the server will not overwrite memory beyond the end of the reply message buffer. That check is the responsability of the server, there is just a DIAGNOSTIC test to check everything is in good shape. All currently implemented servers in NetBSD have been modified to check for this condition While we are here, build the mach services table (formerly in mach_namemap.c) and the services prototypes automatically from mach_services.master, just as this is done for system calls. The next step would be to fold the message formats in the mach_services.master file, but this tends to be difficult, as some messages are quite long and complex.
2003-11-13 16:40:39 +03:00
3612 STD thread_info
Try to add all mach servers defined in Darwin in the server list. Most of them will never be implemented, of course.
2003-11-15 20:44:38 +03:00
3613 UNIMPL thread_set_exception_ports
3614 UNIMPL thread_get_exception_ports
3615 UNIMPL thread_swap_exception_ports
Enforce good santity checks with Mach messages sizes: 1) make sure Mach servers will not work on data beyond the end of the request message buffer. 2) make sure that on copying out the reply message buffer, we will not leak kernel data located after the buffer. 3) make sure that the server will not overwrite memory beyond the end of the reply message buffer. That check is the responsability of the server, there is just a DIAGNOSTIC test to check everything is in good shape. All currently implemented servers in NetBSD have been modified to check for this condition While we are here, build the mach services table (formerly in mach_namemap.c) and the services prototypes automatically from mach_services.master, just as this is done for system calls. The next step would be to fold the message formats in the mach_services.master file, but this tends to be difficult, as some messages are quite long and complex.
2003-11-13 16:40:39 +03:00
3616 STD thread_policy
Try to add all mach servers defined in Darwin in the server list. Most of them will never be implemented, of course.
2003-11-15 20:44:38 +03:00
3617 UNIMPL thread_policy_set
3618 UNIMPL thread_policy_get
3619 UNIMPL thread_sample
3620 UNIMPL etap_trace_thread
3621 UNIMPL thread_assign
3622 UNIMPL thread_assign_default
3623 UNIMPL thread_get_assignment
Added Mach services (no real implementation, just empty shells to make userland happy) processor_set_default, host_processor_set_priv, and thread_set_policy
2003-12-29 04:30:27 +03:00
3624 STD thread_set_policy
Try to add all mach servers defined in Darwin in the server list. Most of them will never be implemented, of course.
2003-11-15 20:44:38 +03:00
;
; VM mappings
;
Enforce good santity checks with Mach messages sizes: 1) make sure Mach servers will not work on data beyond the end of the request message buffer. 2) make sure that on copying out the reply message buffer, we will not leak kernel data located after the buffer. 3) make sure that the server will not overwrite memory beyond the end of the reply message buffer. That check is the responsability of the server, there is just a DIAGNOSTIC test to check everything is in good shape. All currently implemented servers in NetBSD have been modified to check for this condition While we are here, build the mach services table (formerly in mach_namemap.c) and the services prototypes automatically from mach_services.master, just as this is done for system calls. The next step would be to fold the message formats in the mach_services.master file, but this tends to be difficult, as some messages are quite long and complex.
2003-11-13 16:40:39 +03:00
3800 STD vm_region
3801 STD vm_allocate
3802 STD vm_deallocate
3803 STD vm_protect
3804 STD vm_inherit
Implement vm_read, vm_write, and a framework for vm_machine_attribute. THe machine dependent bit nees to be written.
2003-11-30 02:56:08 +03:00
3805 STD vm_read
Try to add all mach servers defined in Darwin in the server list. Most of them will never be implemented, of course.
2003-11-15 20:44:38 +03:00
3806 UNIMPL vm_read_list
Implement vm_read, vm_write, and a framework for vm_machine_attribute. THe machine dependent bit nees to be written.
2003-11-30 02:56:08 +03:00
3807 STD vm_write
Enforce good santity checks with Mach messages sizes: 1) make sure Mach servers will not work on data beyond the end of the request message buffer. 2) make sure that on copying out the reply message buffer, we will not leak kernel data located after the buffer. 3) make sure that the server will not overwrite memory beyond the end of the reply message buffer. That check is the responsability of the server, there is just a DIAGNOSTIC test to check everything is in good shape. All currently implemented servers in NetBSD have been modified to check for this condition While we are here, build the mach services table (formerly in mach_namemap.c) and the services prototypes automatically from mach_services.master, just as this is done for system calls. The next step would be to fold the message formats in the mach_services.master file, but this tends to be difficult, as some messages are quite long and complex.
2003-11-13 16:40:39 +03:00
3808 STD vm_copy
Try to add all mach servers defined in Darwin in the server list. Most of them will never be implemented, of course.
2003-11-15 20:44:38 +03:00
3809 UNIMPL vm_read_overwrite
Enforce good santity checks with Mach messages sizes: 1) make sure Mach servers will not work on data beyond the end of the request message buffer. 2) make sure that on copying out the reply message buffer, we will not leak kernel data located after the buffer. 3) make sure that the server will not overwrite memory beyond the end of the reply message buffer. That check is the responsability of the server, there is just a DIAGNOSTIC test to check everything is in good shape. All currently implemented servers in NetBSD have been modified to check for this condition While we are here, build the mach services table (formerly in mach_namemap.c) and the services prototypes automatically from mach_services.master, just as this is done for system calls. The next step would be to fold the message formats in the mach_services.master file, but this tends to be difficult, as some messages are quite long and complex.
2003-11-13 16:40:39 +03:00
3810 STD vm_msync
Try to add all mach servers defined in Darwin in the server list. Most of them will never be implemented, of course.
2003-11-15 20:44:38 +03:00
3811 UNIMPL vm_behavior_set
Enforce good santity checks with Mach messages sizes: 1) make sure Mach servers will not work on data beyond the end of the request message buffer. 2) make sure that on copying out the reply message buffer, we will not leak kernel data located after the buffer. 3) make sure that the server will not overwrite memory beyond the end of the reply message buffer. That check is the responsability of the server, there is just a DIAGNOSTIC test to check everything is in good shape. All currently implemented servers in NetBSD have been modified to check for this condition While we are here, build the mach services table (formerly in mach_namemap.c) and the services prototypes automatically from mach_services.master, just as this is done for system calls. The next step would be to fold the message formats in the mach_services.master file, but this tends to be difficult, as some messages are quite long and complex.
2003-11-13 16:40:39 +03:00
3812 STD vm_map
Implement vm_read, vm_write, and a framework for vm_machine_attribute. THe machine dependent bit nees to be written.
2003-11-30 02:56:08 +03:00
3813 STD vm_machine_attribute
Try to add all mach servers defined in Darwin in the server list. Most of them will never be implemented, of course.
2003-11-15 20:44:38 +03:00
3814 UNIMPL vm_remap
3815 UNIMPL task_wire
3816 UNIMPL make_memory_entry
3817 UNIMPL vm_map_page_query
3818 UNIMPL vm_region_info
3819 UNIMPL vm_mapped_pages_info
3820 UNIMPL vm_region_object_create
3821 UNIMPL vm_region_recurse
3822 UNIMPL vm_region_recurse_64
3823 UNIMPL vm_region_info_64
Enforce good santity checks with Mach messages sizes: 1) make sure Mach servers will not work on data beyond the end of the request message buffer. 2) make sure that on copying out the reply message buffer, we will not leak kernel data located after the buffer. 3) make sure that the server will not overwrite memory beyond the end of the reply message buffer. That check is the responsability of the server, there is just a DIAGNOSTIC test to check everything is in good shape. All currently implemented servers in NetBSD have been modified to check for this condition While we are here, build the mach services table (formerly in mach_namemap.c) and the services prototypes automatically from mach_services.master, just as this is done for system calls. The next step would be to fold the message formats in the mach_services.master file, but this tends to be difficult, as some messages are quite long and complex.
2003-11-13 16:40:39 +03:00
3824 STD vm_region_64
Try to add all mach servers defined in Darwin in the server list. Most of them will never be implemented, of course.
2003-11-15 20:44:38 +03:00
3825 STD make_memory_entry_64
3826 UNIMPL vm_map_64
3827 UNIMPL vm_map_get_upl
3828 UNIMPL vm_upl_map
3829 UNIMPL vm_upl_unmap
;
; Processor set
;
4000 UNIMPL processor_set_statistics
4001 UNIMPL processor_set_destroy
4002 UNIMPL processor_set_max_priority
4003 UNIMPL processor_set_policy_enable
4004 UNIMPL processor_set_policy_disable
4005 UNIMPL processor_set_tasks
4006 UNIMPL processor_set_threads
4007 UNIMPL processor_set_policy_control
4008 UNIMPL processor_set_stack_usage
4009 UNIMPL processor_set_info
;
; Ledger
;
5000 UNIMPL ledger_create
5001 UNIMPL ledger_terminate
5002 UNIMPL ledger_transfer
5003 UNIMPL ledger_read
;
; User Notification subsystem (UNDRequest)
;
6000 UNIMPL und_execute_rpc
6001 UNIMPL und_display_notice_from_bundle_rpc
6002 UNIMPL und_display_alert_from_bundle_rpc
6003 UNIMPL und_display_custom_from_bundle_rpc
6004 UNIMPL und_display_custom_from_dictionary_rpc
6005 UNIMPL und_cancel_notification_rpc
6006 UNIMPL und_display_notice_simple_rpc
6007 UNIMPL und_display_alert_simple_rpc
;
; User Notification subsystem (UNDReply)
;
6200 UNIMPL und_alert_completed_with_result_rpc
6201 UNIMPL und_notification_created_rpc(
;
; Mach Norma
;
555001 UNIMPL task_set_child_node
555002 UNIMPL norma_node_self
555005 UNIMPL norma_task_clone
555006 UNIMPL norma_task_create
555007 UNIMPL norma_get_special_port
555008 UNIMPL norma_set_special_port
555009 UNIMPL norma_task_teleport
555012 UNIMPL norma_port_location_hint
;
; Sync, overlapping with Lock set
;
;617000 UNIMPL semaphore_create
;617001 UNIMPL semaphore_destroy
;617002 UNIMPL semaphore_signal
;617003 UNIMPL semaphore_signal_all
;617004 UNIMPL semaphore_wait
;617013 UNIMPL semaphore_signal_thread
;617014 UNIMPL semaphore_timedwait
;
; Lock set
;
617000 UNIMPL lock_acquire
617001 UNIMPL lock_release
617002 UNIMPL lock_try
617003 UNIMPL lock_make_stable
617004 UNIMPL lock_handoff
617005 UNIMPL lock_handoff_accept
617005 UNIMPL lock_set_create
617006 UNIMPL lock_set_destroy
617007 UNIMPL lock_acquire
617008 UNIMPL lock_release
617009 UNIMPL lock_try
617010 UNIMPL lock_make_stable
617011 UNIMPL lock_handoff
617012 UNIMPL lock_handoff_accept
;
; Semaphores
;
617200 UNIMPL semaphore_signal
617201 UNIMPL semaphore_signal_all
617202 UNIMPL semaphore_wait
617203 UNIMPL semaphore_signal_thread
617204 UNIMPL semaphore_timedwait
617205 UNIMPL semaphore_wait_signal
617206 UNIMPL semaphore_timedwait_signal