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

100 lines
4.9 KiB
C
Raw Normal View History

regen
2005-02-27 02:58:19 +03:00
/* $NetBSD: mach_services.h,v 1.17 2005/02/26 23:58:20 perry 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
/*
* Mach services prototypes.
*
* DO NOT EDIT -- this file is automatically generated.
regen
2005-02-27 02:58:19 +03:00
* created from NetBSD: mach_services.master,v 1.12 2005/02/26 23:10:20 perry 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
*/
#include <sys/cdefs.h>
regen
2005-02-27 02:58:19 +03:00
__KERNEL_RCSID(0, "$NetBSD: mach_services.h,v 1.17 2005/02/26 23:58:20 perry 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
#include <compat/mach/mach_types.h>
#include <compat/mach/mach_message.h>
int mach_host_info(struct mach_trap_args *);
int mach_host_page_size(struct mach_trap_args *);
int mach_host_get_io_master(struct mach_trap_args *);
int mach_host_get_clock_service(struct mach_trap_args *);
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
int mach_processor_set_default(struct mach_trap_args *);
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
int mach_bootstrap_look_up(struct mach_trap_args *);
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
int mach_host_processor_set_priv(struct mach_trap_args *);
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
int mach_clock_get_time(struct mach_trap_args *);
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
int mach_exception_raise(struct mach_trap_args *);
int mach_exception_raise_state(struct mach_trap_args *);
int mach_exception_raise_state_identity(struct mach_trap_args *);
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
int mach_io_object_get_class(struct mach_trap_args *);
int mach_io_object_conforms_to(struct mach_trap_args *);
int mach_io_iterator_next(struct mach_trap_args *);
int mach_io_iterator_reset(struct mach_trap_args *);
int mach_io_service_get_matching_services(struct mach_trap_args *);
int mach_io_registry_entry_get_property(struct mach_trap_args *);
int mach_io_registry_entry_from_path(struct mach_trap_args *);
int mach_io_registry_entry_get_properties(struct mach_trap_args *);
int mach_io_registry_entry_get_child_iterator(struct mach_trap_args *);
int mach_io_registry_entry_get_parent_iterator(struct mach_trap_args *);
int mach_io_service_open(struct mach_trap_args *);
int mach_io_service_close(struct mach_trap_args *);
int mach_io_connect_get_service(struct mach_trap_args *);
int mach_io_connect_set_notification_port(struct mach_trap_args *);
int mach_io_connect_map_memory(struct mach_trap_args *);
int mach_io_connect_add_client(struct mach_trap_args *);
int mach_io_connect_set_properties(struct mach_trap_args *);
int mach_io_connect_method_scalari_scalaro(struct mach_trap_args *);
int mach_io_connect_method_scalari_structo(struct mach_trap_args *);
int mach_io_connect_method_scalari_structi(struct mach_trap_args *);
int mach_io_connect_method_structi_structo(struct mach_trap_args *);
int mach_io_registry_entry_get_path(struct mach_trap_args *);
int mach_io_registry_get_root_entry(struct mach_trap_args *);
int mach_io_registry_entry_create_iterator(struct mach_trap_args *);
int mach_io_registry_entry_get_name_in_plane(struct mach_trap_args *);
int mach_io_service_add_interest_notification(struct mach_trap_args *);
int mach_io_registry_entry_get_location_in_plane(struct mach_trap_args *);
int mach_port_type(struct mach_trap_args *);
int mach_port_allocate(struct mach_trap_args *);
int mach_port_destroy(struct mach_trap_args *);
int mach_port_deallocate(struct mach_trap_args *);
Added port_get_refs and port_mod_refs
2004-07-24 19:46:02 +04:00
int mach_port_get_refs(struct mach_trap_args *);
int mach_port_mod_refs(struct mach_trap_args *);
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
int mach_port_move_member(struct mach_trap_args *);
int mach_port_request_notification(struct mach_trap_args *);
int mach_port_insert_right(struct mach_trap_args *);
int mach_port_get_attributes(struct mach_trap_args *);
int mach_port_set_attributes(struct mach_trap_args *);
int mach_port_insert_member(struct mach_trap_args *);
Add task_terminate
2003-11-30 23:42:03 +03:00
int mach_task_terminate(struct mach_trap_args *);
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
int mach_task_threads(struct mach_trap_args *);
int mach_ports_lookup(struct mach_trap_args *);
int mach_task_info(struct mach_trap_args *);
int mach_task_suspend(struct mach_trap_args *);
int mach_task_resume(struct mach_trap_args *);
int mach_task_get_special_port(struct mach_trap_args *);
int mach_task_set_special_port(struct mach_trap_args *);
int mach_thread_create_running(struct mach_trap_args *);
int mach_task_set_exception_ports(struct mach_trap_args *);
int mach_task_get_exception_ports(struct mach_trap_args *);
int mach_semaphore_create(struct mach_trap_args *);
int mach_semaphore_destroy(struct mach_trap_args *);
int mach_thread_get_state(struct mach_trap_args *);
int mach_thread_set_state(struct mach_trap_args *);
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
int mach_thread_suspend(struct mach_trap_args *);
int mach_thread_resume(struct mach_trap_args *);
int mach_thread_abort(struct mach_trap_args *);
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
int mach_thread_info(struct mach_trap_args *);
int mach_thread_policy(struct mach_trap_args *);
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
int mach_thread_set_policy(struct mach_trap_args *);
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
int mach_vm_region(struct mach_trap_args *);
int mach_vm_allocate(struct mach_trap_args *);
int mach_vm_deallocate(struct mach_trap_args *);
int mach_vm_protect(struct mach_trap_args *);
int mach_vm_inherit(struct mach_trap_args *);
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
int mach_vm_read(struct mach_trap_args *);
int mach_vm_write(struct mach_trap_args *);
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
int mach_vm_copy(struct mach_trap_args *);
int mach_vm_msync(struct mach_trap_args *);
int mach_vm_map(struct mach_trap_args *);
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
int mach_vm_machine_attribute(struct mach_trap_args *);
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
int mach_vm_region_64(struct mach_trap_args *);
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
int mach_make_memory_entry_64(struct mach_trap_args *);