Aren/NetBSD
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
6d7eb973a8
NetBSD/sys/compat/mach/Makefile

17 lines
556 B
Makefile
Raw Normal View History

nuke trailing whitespace
2005-02-27 01:58:54 +03:00
# $NetBSD: Makefile,v 1.6 2005/02/26 23:10:19 perry Exp $
Use ${HOST_SH} instead of `sh'. If necessary, pull in <bsd.sys.mk> to get the definition of HOST_SH; Makefiles that pull in one of (most of) <bsd.*.mk> will get this anyway.
2003-10-26 10:25:33 +03:00
nuke trailing whitespace
2005-02-27 01:58:54 +03:00
SYSCALL_DEP= syscalls.conf syscalls.master ../../kern/makesyscalls.sh
SYSCALL_OBJS= mach_sysent.c mach_syscalls.c mach_syscall.h mach_syscallargs.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
MACH_DEP= mach_services.master makemachservices.sh
iTry to gather as much Mach services names as possible, this way we will have unimplemented services showing their names in ktrace Add a new generated file with only service id and name, which will be included by kdump to display services names. This removes the need for using the user ktrace facility for services names.
2003-11-16 01:55:35 +03:00
MACH_OBJ= mach_services.c mach_services.h mach_services_names.c
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
all: ${SYSCALL_OBJS} ${MACH_OBJ}
add a shell that does nothing for now for the mach syscalls.
2001-07-14 06:10:59 +04: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 <bsd.sys.mk> # for HOST_SH
add a shell that does nothing for now for the mach syscalls.
2001-07-14 06:10:59 +04: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
${SYSCALL_OBJS}: ${SYSCALL_DEP}
Use ${HOST_SH} instead of `sh'. If necessary, pull in <bsd.sys.mk> to get the definition of HOST_SH; Makefiles that pull in one of (most of) <bsd.*.mk> will get this anyway.
2003-10-26 10:25:33 +03:00
${HOST_SH} ../../kern/makesyscalls.sh syscalls.conf syscalls.master
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_OBJ}: ${MACH_DEP}
${HOSH_SH} ./makemachservices.sh
Reference in New Issue Copy Permalink