| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add host_get_uptime64() mach interface operation. It can be used to get
the time passed since the boot up.
* doc/mach.texi: Add the documentation for the operation
* include/mach/mach_host.defs: Add the interface
* include/mach/time_value.h: Extend the mappable time variable
* kern/mach_clock.c: Operation implementation
* kern/mach_clock.h: Add a new variable for storing uptime
Signed-off-by: Zhaoming Luo <zhmingluo@163.com>
Message-ID: <20241224015751.1282-1-zhmingluo@163.com>
|
| |
|
|
| |
Message-ID: <6qm4fdtthi5nrmmleum7z2xemxz77adohed454eaeuzlmvfx4d@l3pyff4tqwry>
|
| |
|
|
|
| |
Remove unnecessary definitions from sys/types.h.
Message-ID: <oitneneybjishhqq7bgedkasrqqd6nq7vselruaacw27sbe47e@6rt3xbi7fnie>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a new Mach trap that sets the calling thread's state to the
passed value, as if with a call to the thread_set_state() RPC. If the
flavor of state being set is the one that contains the register used for
syscall return value (i386_THREAD_STATE or i386_REGS_SEGS_STATE on x86,
AARCH64_THREAD_STATE on AArch64), the set register value is *not*
overwritten with KERN_SUCCESS when the state gets set successfully, yet
errors do get reported if the syscall fails.
Although the trap is intended to enable userland to implement sigreturn
functionality in the AArch64 port (more on which below), the trap itself
is architecture-independent, and fully implemented in terms of the
existing kernel routines (thread_setstatus & thread_set_syscall_return).
This trap's functionality is similar to sigreturn() on Unix or
NtContinue() on NT. The use case for these all is restoring the local
state of an interrupted thread in the following set-up:
1. A thread is running some arbitrary code.
2. An event happens that deserves the thread's immediate attention,
analogous to a hardware interrupt request. This might be caused by
the thread itself (e.g. running into a Mach exception that was
arranged to be handled by the same thread), or by external events
(e.g. receiving a Unix SIGCHLD).
3. Another thread (or perhaps the kernel, although this is not the case
on Mach) suspends the thread, saves its state at the point of
interruption, alters its state to execute some sort of handler for
the event, and resumes the thread again, now running the handler.
4. Once the thread is done running the handler, it wants to return to
what it was doing at the time it was interrupted. To do this, it
needs to restore the state as saved at the moment of interruption.
Unlike with setjmp()/longjmp(), we cannot rely on the interrupted logic
collaborating in any way, as it's not aware that it's being interrupted.
This means that we have to fully restore the state, including values of
all the general-purpose registers, as well as the stack pointer, program
counter, and any state flags.
Depending on the instruction set, this may or may not be possible to do
fully in userland, simply by loading all the registers with their saved
values. It should be more or less easy to load the saved values into
general-purpose registers, but state flags and the program counter can
be more of a challenge. Loading the program counter value (in other
words, performing an indirect jump to the interrupted instruction) has
to be the very last thing we do, since we don't control the program flow
after that. The only real place program counter can be loaded from is
popped off the stack, since all general-purpose registers would already
contain their restored values by that point, and using global storage is
incompatible with another interruption of the same kind happening at the
time we were about to return. For the same reason, the saved program
counter cannot be really stored outside of the "active" stack area (such
as below the stack pointer), since otherwise it can get clobbered by
another interruption.
This means that to support fully-userland returns, the instruction set
must provide a single instruction that loads an address from the stack,
adjusts the stack pointer, and performs an indirect jump to the loaded
address. The instruction must also either preserve (previously
restored) state flags, or additionally load state flags from the stack
in addition to the jump address.
On x86, 'ret' is such an instruction: it pops an address from the stack,
adjusting the stack pointer without modifying flags, and performs an
indirect jump to the address. On x86_64, where the ABI mandates a red
zone, one can use the 'ret imm16' variant to additionally adjust the
stack pointer by the size of the red zone, atomically restoring the
value of the stack pointer at the time of the interruption while loading
the return address from outside the red zone. This is how sigreturn is
implemented in glibc for the Hurd on x86.
On ARM AArch32, 'pop {pc}' (alternatively written 'ldr pc, [sp], #4') is
such an instruction: since SP and PC are just general-purpose, directly
accessible registers (r13 and r15), it is possible to perform a load
from the address pointed to by SP into PC, with a post-increment of SP.
It is, in fact, possible to restore all the other general-purpose
registers too in a single instruction this way: 'pop {r0-r12, r14, r15}'
will do that; here r13, the stack pointer, gets incremented after all
the other registers get loaded from the stack. This also preserves the
CPSR flags, which would need to be restored just prior to the 'pop'.
On ARM AArch64 however, PC is no longer a directly accessible general-
purpose register (and SP is only accessible that way by some of the
instructions); so it is no longer possible to load PC from memory in a
single instruction. The only way to perform an indirect jump is by
using one of the dedicated branching instructions ('br', 'blr', or
'ret'). All of them accept the address to branch to in a general-
purpose register, which is incompatible with our use case.
Moreover, with the BTI extension, there is a BTYPE field in PSTATE that
tracks which type (if any) of an indirect branch was the last executed
instruction; this is then used to raise an exception if the instruction
the indirect branch lands on was not intended to be a target of an
indirect branch (of a matching type). It is important to restore the
BTYPE (among the other state) when returning to an interrupted context;
failing to do that will either cause an unexpected BTI failure exception
(if the last executed instruction before the interruption was not an
indirect branch, but the last instruction of the restoration logic is),
or open up a window for exploitation (if the last executed instruction
before the interruption was an indirect branch, but the last instruction
of the restoration logic is not -- note that 'ret' is not considered an
indirect branch for the purposes of BTI).
So, it is not possible to fully restore the state of an interrupted
context in userland on AArch64. The kernel can do that however (and is
in fact doing just that every time it handles a fault or an IRQ): the
'eret' instruction for returning from an exception is accessible to EL1
(the kernel), but not EL0 (the user). 'eret' atomically restores PC
from the ELR_EL1 system register, and PSTATE from the SPSR_EL1 system
register (and does other things); both of these system registers are
inaccessible from userland, and so couldn't have been used by the
interrupted context for any purpose, meaning their values doesn't need
to be restored. (They can be used by the kernel code, which presents an
additional complication when it's the kernel context that gets
interrupted and has to be returned to. To make this work, the kernel
masks interrupt requests and avoids doing anything that could cause a
fault when using those registers.)
The above justifies the need for a kernel API to atomically restore
saved userland state on AArch64 (and possibly other platforms that
aren't x86). Mach already has an API to set state of a thread, namely
the thread_set_state() RPC; however, a thread calling thread_set_state()
on itself is explicitly disallowed. We have previously relaxed this
restriction to allow setting i386_DEBUG_STATE and i386_FSGS_BASE_STATE
on the current thread, so one way to address the need for such an API on
AArch64 would be to also allow setting AARCH64_THREAD_STATE on the
current thread. That is what I have originally proposed and
implemented. Like the thread_set_self_state() trap implemented by this
patch, the implementation of setting AARCH64_THREAD_STATE on the current
thread needs to ensure that the set value of the x0 register does not
get immediately overwritten with the return value of the mach_msg()
trap.
However, it's not only the return value of the mach_msg() trap that is
important, but also the RPC reply message. The thread_set_state() RPC
should not generate a reply message when used for returning to an
interrupted context, since there'd be nobody expecting the message.
This could be achieved by special-casing that in the kernel as well, or
(simpler) by userland not passing a valid reply port in the first place.
Note that the implementation of sigreturn in glibc already uses the
strategy of passing an invalid reply port for the last RPC is does
before returning to the interrupted context (which is deallocating the
reply port used by the signal handler).
Not passing a valid reply port and consequently not blocking on awaiting
the reply message works, since the way Mach is implemented, kernel RPCs
are always executed synchronously when userland sends the request
message (unless the routine implementation includes explicit asynchrony,
as device RPCs do, and gsync_wait() should do, but currently doesn't),
meaning the RPC caller never has to *wait* for the reply message, as one
is produced immediately. In other words, the mere act of invoking a
kernel RPC (that does not involve explicit asynchrony) is enough to
ensure it completes when mach_msg() returns, even if a reply message is
not received (whether because an invalid reply port has been specified,
or because MACH_RCV_MSG wasn't passed to mach_msg(), or because a
message other than the kernel RPC's reply was received by the call).
However, the same is not true when interposing is involved, and the
thread's self port does not in fact point directly to the kernel, but to
a userspace proxy of some sort. The two primary examples of this are
Hurd's rpctrace tool, which interposes all the task's ports and proxies
all RPCs after tracing them, and Mach's old netmsg/netname server, which
proxies ports and messages over network. In this case, the actual
implementation only runs once the request reaches the actual kernel, and
not once the request message has been sent by the original caller, so it
*is* necessary for the caller to await the reply message if it wants to
make sure that the requested action has been completed. This does not
cause much issues for deallocation of a reply port on the sigreturn code
path in glibc, since that only delays when the port is deallocated, but
does not otherwise change the program behavior. With
thread_set_state(mach_thread_self()), however, this would be quite
catastrophic, since the message-send would return back to the caller
without changing its state, and the actual change of state would only
happen at some later point.
This issue is avoided nicely by turning the functionality into an
explicit Mach trap rather than an RPC. As it's not an RPC, it doesn't
involve messaging, and doesn't need a reply port or a reply message. It
is always a direct call to the kernel (and not to any interposer), and
it's always guaranteed to have completed synchronously once the trap
returns. That also means that the thread_set_self_state() call won't be
visible to rpctrace or forwarded over network for netmsg, but this is
fine, since all it does is sets thread state (i.e. register values); the
thread could do the same on its own by issuing relevant machine
instruction without involving any Mach abstractions (traps or RPCs) at
all if it weren't for the need of atomicity.
Finally, this new trap is unfortunately somewhat of a security concern
(as any sigreturn-like functionality is in general), since it would
potentially allow an attacker who already has a way to invoke a function
with 3 controlled argument values to set the values of all registers to
any desired values (sigreturn-oriented programming). There is currently
no mitigation for this other than the generic ones such as PAC and stack
check guards.
The limit of 150 used in the implementation has been chosen to be large
enough to fit the largest thread state flavor so far, namely
AARCH64_FLOAT_STATE, but small enough to not overflow the 4K stack. If
a new thread state flavor is added that is too big to fit on the stack,
the implementation should be switched to use kalloc instead of on-stack
storage.
Message-ID: <20240415090149.38358-9-bugaevc@gmail.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
And make it so that the generic vm_param.h doesn't require the machine-
specific one to define PAGE_SIZE etc. We *don't* want a PAGE_SIZE
constant to be statically exported to userland; instead userland should
initialize vm_page_size by querying vm_statistics(), and then use
vm_page_size.
We'd also like to eventually avoid exporting VM_MAX_ADDRESS, but this is
not feasible at the moment. To make it feasible in the future, userland
should try to avoid relying on the definition where possible.
Message-ID: <20240415090149.38358-5-bugaevc@gmail.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is distinct from CPU_TYPE_ARM, since we're going to exclusively use
AArch64 / A64, which CPU_TYPE_ARM was never meant to support, and to
match EM_AARCH64, which is also separate from EM_ARM. CPU_TYPE_X86_64
was similarly made distinct from CPU_TYPE_I386.
This is named CPU_TYPE_ARM64 rather than CPU_TYPE_AARCH64, since AArch64
is an "execution state" (analogous to long mode on x86_64) rather than a
CPU type. "ARM64" here is not a name of the architecture, but simply
means an ARM CPU that is capable of (and for our case, will only really
be) running in the 64-bit mode (AArch64).
There are no subtypes defined, and none are expected to be defined in
the future. Support for individual features/extensions should be
discovered by other means, i.e. the aarch64_get_hwcaps() RPC.
Message-ID: <20240415090149.38358-2-bugaevc@gmail.com>
|
| |
|
|
|
| |
If a bootstrap ELF contains a PT_GNU_STACK phdr, take stack protection
from there. Otherwise, default to VM_PROT_ALL.
|
| |
|
|
|
| |
Not only on x86_64.
Message-ID: <20240327161841.95685-5-bugaevc@gmail.com>
|
| |
|
|
| |
Message-ID: <20240327161841.95685-4-bugaevc@gmail.com>
|
| |
|
|
|
| |
It's not only x86_64, none of new architectures are going to have it.
Message-ID: <20240327161841.95685-3-bugaevc@gmail.com>
|
| |
|
|
|
|
|
|
| |
Is _IO{,R,W,WR} macros conflict with the glibc-provided macros and bring
confusion as to what is supposed to be the right definition.
There is currently no user of it anyway, the Hurd console driver has its
own copy.
|
| |
|
|
|
|
|
| |
Like task_set_name, we use the same size as the task name and will
inherit the task name, whenever it exists. This will be used to
implement pthread_setname_np.
Message-ID: <20240212062634.1082207-2-flaviocruz@gmail.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
declarations.
I was trying to reuse TASK_NAME_SIZE in kern/thread.h but it was
impossible because files included from kern/task.h end up requiring
kern/thread.h (through percpu.h), creating a recursive dependency.
With this change, mach_types.h only defines forward declarations and
modules have to explicitly include the appropriate header file if they
want to be able touch those structures. Most of the other includes are
required because we no longer grab many different includes through
mach_types.h.
Message-ID: <20240212062634.1082207-1-flaviocruz@gmail.com>
|
| |
|
|
|
|
|
|
| |
For rumpdisk to efficiently determine the physical address, both
for checking whether it is below 4GiB, and for giving it to the disk
driver, we need a gnumach primitive (and that is not conditioned by
MACH_VM_DEBUG like mach_vm_region_info and mach_vm_object_pages_phys
are).
|
| |
|
|
| |
Message-ID: <20231228194301.745811-11-luca@orpolo.org>
|
| |
|
|
|
|
|
|
| |
aligned
msgt_unused appears right after msgt_size since msgt_size can be reduced
to only 8 bits in the future, so we leave the door opened to make
msgt_unused 13 bits long.
|
| |
|
|
|
|
|
|
|
|
| |
If a port is inlined in a message, the user has to use
mach_port_name_inlined_t to define each port. Out of line memory
continues to use mach_port_name_t since that memory has to be copied to
the kernel anyway.
Both copyinmsg and copyoutmsg can be reduced to nothing (if we ignore
USER32) as a follow up but kept this patch simple for ease of review.
|
| |
|
|
|
|
| |
byte aligned"
This reverts commit 2db6b9b7b23b3bab944665b3b6012d24dd425d97.
|
| |
|
|
| |
This reverts commit 29d4bcaafc4c2040df27a6247603c68e7757205c.
|
| |
|
|
|
|
|
|
|
|
|
| |
If a port is inlined in a message, the user has to use
mach_port_name_inlined_t to define each port. Out of line memory
continues to use mach_port_name_t since that memory has to be copied to
the kernel anyway.
Both copyinmsg and copyoutmsg can be reduced to nothing (if we ignore
USER32) as a follow up but kept this patch simple for ease of review.
Message-ID: <ZWg00XzFPqqL1yF-@jupiter.tail36e24.ts.net>
|
| |
|
|
|
|
|
|
|
| |
aligned
msgt_unused appears right after msgt_size since msgt_size can be reduced
to only 8 bits in the future, so we leave the door opened to make
msgt_unused 13 bits long.
Message-ID: <ZWGT6a6GeqFAtOUn@jupiter.tail36e24.ts.net>
|
| | |
|
| |
|
|
| |
static_assert was introduced in C++11.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Make full use of the 8 bytes available in mach_msg_type_t by moving
into the unused 4 bytes. This allows us to use 32bits for
mach_msg_type_number_t whether we use the longform or not.
* Make mach_msg_type_long_t exactly the same as mach_msg_type_t.
Updating MiG is strongly encouraged since it will generate better code
to handle this new format.
After this change, any compatibility with compiled binaries for Hurd x86_64
will break since the message format is different. However, the new
schema simplifies the overall ABI, without having "holes" and also
avoids the need to have a 16 byte mach_msg_type_long_t.
Was able to boot a basic system up to a bash shell.
Message-Id: <ZIfqFe5bPNPeH4xg@jupiter.lan>
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
Apparently the ELF world changed their mind on the naming of integers,
let's get coherent with it.
Elf64_Quarter (16b) disappeared, replaced by Elf64_Half (now 16b instead of
Elf64_32b). And previous Elf64_Half (16b) thus now need to be Elf64_Word
(16b).
|
| |
|
|
|
|
| |
We are checking for the existence of time_value64_t but we didn't add
that to the task_thread_times_info structure.
Message-Id: <ZGRDbS0XIm1fJwkG@jupiter.tail36e24.ts.net>
|
| | |
|
| |
|
|
|
|
|
| |
We can fast track the simplification of the RPC ABI for x86_64 if we don't have
MACH_MSG_TYPE_STRING used in RPCs which forces msgt_size to use more than 8
bits.
Message-Id: <ZFht+/9cVPHuV90D@jupiter.tail36e24.ts.net>
|
| |
|
|
|
| |
File is unused.
Message-Id: <ZFSSbAzZ+7KYKtOF@jupiter.tail36e24.ts.net>
|
| | |
|
| |
|
|
|
|
|
|
|
| |
* include/mach/mig_support.h: Drop the ifndef because this file is only
used internally to compile gnumach. We export mig_support.h from glibc
already.
* kern/ipc_mig.c: len should be vm_size_t.
* kern/ipc_mig.h: Drop duplicate prototypes.
Message-Id: <ZFBjEk07CaQgx9Ru@jupiter.tail36e24.ts.net>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Added device_open_new and device_open_new_request and reused the old MiG
ID for xxx_device_set_status which has not been in used in the past
decade.
Note that device_open_new is gated on defining
DEVICE_ENABLE_DEVICE_OPEN_NEW because otherwise some hurd servers
wouldn't compile anymore unless patched. This macro allows us to control
the rollout.
Message-Id: <ZEi1LV+9ShuXqtcr@jupiter.tail36e24.ts.net>
|
| |
|
|
|
|
| |
RPCs remain compatible with existing clients but if they know about the
new size then we will populate the new fields.
Message-Id: <ZDzPLCJccKeRB5Pd@mars.tail36e24.ts.net>
|
| |
|
|
|
| |
Not used.
Message-Id: <ZDN13tll1jYc1jYh@jupiter.tail36e24.ts.net>
|
| |
|
|
|
|
| |
host_get_kernel_boot_info was added recently to fix the use of
MACH_MSG_TYPE_STRING.
Message-Id: <ZC5Sz8a4FCT6IjCY@jupiter.tail36e24.ts.net>
|
| |
|
|
|
|
|
|
|
| |
On EXC_BAD_ACCESS, exception subcode is used to pass the faulting memory
address, so it needs to be (at least) pointer-sized. Thus, make it into
a long.
This requires matching changes in glibc and the Hurd.
Message-Id: <20230319151017.531737-4-bugaevc@gmail.com>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
As far as I can see, this file was imported in the very beginning of GNU Mach
history, and unused since then. Nobody implements or uses this interface. GNU
Mach uses a different way to pass the privileged ports to the bootstrap tasks:
instead of the task(s) actively asking for the ports in an RPC, the ports are
preemptively inserted into the IPC space(s) of the task(s), as configured by
the boot script.
Remove bootstrap.defs so as to not confuse anyone into thinking it works.
Message-Id: <20230319151017.531737-3-bugaevc@gmail.com>
|
| |
|
|
|
|
|
|
|
|
| |
As mentioned in 5447f965, the c_string type correctly uses
msgt_size/msgt_number, resulting in a more compact ABI that doesn't
require mach_msg_type_long_t.
I redefined host_load_symbol_table with a new Id since this is just a
debug RPC and is not used anywhere.
Message-Id: <ZBFgyJp+Pcb7zFhf@mars.tail36e24.ts.net>
|
| | |
|
| |
|
|
|
|
|
|
| |
Changed kern/timer.c to use the higher precision time_value64_t.
Of course, this won't suffer from the 2038 overflow but it does provide
nanosecond precision (if gnumach ever uses a better timer) and
moves us closer to only having time_value64_t.
Message-Id: <ZA63tGcv3bETUJFJ@jupiter.tail36e24.ts.net>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
The existing definitions for kernel_version_t and kernel_boot_info_t use
(MACH_MSG_TYPE_STRING, length*8) which result in message types that have
a single element of 512 or 4096 bytes (set as msgt_size). This results
in MiG generating mach_msg_type_long_t. Using c_string has the benefit
of moving this size to be defined as msgt_number which doesn't overflow.
This will allow us to simplify the 64 bit RPC ABI since all msgt_size can
be defined with just 8 bits (as it should be expected).
The resulting implementation is the same but we still need to define new
RPCs since server and user expect different mach_msg_type_t.
Message-Id: <ZA63pS8j9J6NwuXY@jupiter.tail36e24.ts.net>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
uintptr_t.
With this change, any 64 bit code using the IPC subsystem without relying on
MiG will work without any changes. We have a few examples of this inside gnumach but
also in the Hurd servers. For example, in hurd/console/display.c
typedef struct
{
mach_msg_header_t Head;
mach_msg_type_t ticknoType;
natural_t tickno;
mach_msg_type_t changeType;
file_changed_type_t change;
mach_msg_type_t startType;
loff_t start;
mach_msg_type_t endType;
loff_t end;
} Request;
This will now work correctly in 64 bits, without requiring any explicit padding.
As a follow up, we can simplify mach_msg_type_long_t so that we
only need an 8 byte structure where the second field will include the
number of elements for the long form. This is already included in
mach_msg_type_t as unused_msgtl_number.
Message-Id: <ZAbhOfOzsb8qPFs6@jupiter.tail36e24.ts.net>
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
We introduce both a user alignment and a kernel alignment. These are
separate requirements since for 64 bit with a 32 bit kernel we need to
ensure the kernel can consume messages that are 8-byte aligned. This
change removes any possibility of undefined behavior and also allows the
kernel to support 64 bit RPCs for the userland.
A lot of the code that performs alignment was simplified under the
assumption that the message headers are well aligned. To enforce that
going forward, a few static assertions were added.
Message-Id: <Y/KrixiC9Njmu7ef@jupiter.tail36e24.ts.net>
|
| |
|
|
|
| |
We can use these in userland with the new time_value64_t struct.
Message-Id: <Y/RRck2JffqNenif@jupiter.tail36e24.ts.net>
|
| |
|
|
|
| |
File is not included anywhere.
Message-Id: <Y/K1haNulJ63eDBd@jupiter.tail36e24.ts.net>
|
| |
|
|
|
|
|
|
|
| |
* i386/include/mach/i386/exec/elf.h: add Elf64 definitions and define
common Elf structures, corresponding to 32/64 bit variants at
compile time.
* include/mach/exec/elf.h: add Elf64 definitions
* kern/elf-load.c: use common Elf structures
Message-Id: <20230216213318.2048699-2-luca@orpolo.org>
|
| |
|
|
|
|
|
|
| |
This has several advantages:
1) We don't need to resize mach_msg_header_t, it is just a copy.
2) Mig won't require any changes because it statically computes the size
of mach_msg_header_t, otherwise we would need two sizes (28 vs 32 bytes).
Message-Id: <Y+l8UhXXX9Qo9tVA@jupiter.tail36e24.ts.net>
|
