This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "MIG".
The branch, master has been updated
via 01bfa1fc30bd5715918c44a1b226d43c9491a0ae (commit)
via 2ad84d9d271c4e323b065815c05d6c7eaaeb7817 (commit)
from 983b56e9f7ef1fdfcf82ad82cc70f939318e599f (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -----------------------------------------------------------------
commit 01bfa1fc30bd5715918c44a1b226d43c9491a0ae
Author: Luca Dariz <l...@orpolo.org>
Date: Sun Apr 3 17:00:19 2022 +0200
add separate port_size and mach_port_name_size definitions
* cpu.sym: retrieve size of vm_offset_t and mach_port_name_t from
gnumach headers at compile type.
* global.{c,h}: add port size as a variable and initialize it to the
port name size.
* lexxer.l: apply port or port name size to the corresponding types,
instead of using the word size.
* parser.y: update port size if we're generating for kernel-space
(server or client). Also re-initialize default port types to account
for this change.
* type.c: use port size instead of word size in default port types and
runtime checks.
There are many assumptions about mach_port_t:
- on kernel side, its size is the same as a pointer. This allows to
replace the port name with the address of the corresponding data
structure during copyin in mach_msg()
- in mig, this is also the "word size", which is derived from gnumach
headers as the size of integer_t
- its size is also the same as natural_t, so it's possible to model
structures like mach_port_status_t as an array of integer_t in
mig. This is convenient since arrays and structures can't have
mixed types.
- its size is always the same as the port name size
This patch does not change the current behaviour on 32-bit kernels,
but allows for some of these assumptions to be broken on 64-bit
kernels. This is needed to have 32-bit port names on 64-bit kernels
and be able to support a 32-bit userspace. It still leaves the choice
for a 64-bit userspace, if all integer_t and natural_t are to be
extended to 64 bit.
However keeping 32-bit port names seems to be the right thing, based on
previous discussions [1], even for a 64-bit kernel.
The only assumption kept is that in kernel-space ports are always the
size of a pointer, as they refer to a data structure and not to a
specific port name. To ensure this is true for various user/kernel
combinations, we dynamically change the port size if we're generating
code for kernel-space server or clients, and keep the size of a port the
same of a port name for user-space servers and clients.
[1] https://lists.gnu.org/archive/html/bug-hurd/2012-04/msg00000.html
Signed-off-by: Luca Dariz <l...@orpolo.org>
Message-Id: <20220403150020.120799-2-l...@orpolo.org>
commit 2ad84d9d271c4e323b065815c05d6c7eaaeb7817
Author: Guy-Fleury Iteriteka <gfle...@disroot.org>
Date: Mon May 2 09:27:57 2022 +0200
mig: remove local definition of 'vprintf'
autoconf consider that 'AC_FUNC_VPRINTF' is obsolescent.
see 'info autoconf AC_FUNC_VPRINTF'
* Makefile.am: remove 'vprint.c' on src files.
configure.ac: remove 'AC_FUNC_VPRINTF' macro.
vprint.c: delete file.
Message-Id: <Ym+H/OM0PnucKO4w@debian>
-----------------------------------------------------------------------
Summary of changes:
Makefile.am | 2 +-
configure.ac | 4 -
cpu.sym | 4 +
global.c | 4 +
global.h | 3 +
lexxer.l | 24 ++--
parser.y | 7 +
type.c | 10 +-
vprint.c | 433 -----------------------------------------------------------
9 files changed, 36 insertions(+), 455 deletions(-)
delete mode 100644 vprint.c
hooks/post-receive
--
MIG
