Hi :)
I've been reworking the receiver object lookup in
Hurd/mig/gnumach. I'll briefly sketch the current state of affairs.
Suppose a file is truncated. To do that, a file_set_size message is
sent to some port. The relevant ipc routine is:
routine file_set_size (
trunc_file: file_t;
RPT
new_size: loff_t);
Here, trunc_file is the receiver, its type is file_t. This patch set
optimizes the receiver lookup in the server.
Suppose the receiving server is implemented using libports like most
Hurd components are. Now three lookups take place.
1. In the kernel, matching the sender thread to the receiver.
2. In libports, in either manage_multithread or manage_one_thread.
3. In the in-translator function defined for file_t by setting FILE_INTRANS.
This patch set adds support for protected payloads to GNU Mach, mig
and the Hurd. It adds an kernel call to gnumach to set the payload for
receive rights:
routine mach_port_set_protected_payload(
task : ipc_space_t;
name : mach_port_name_t;
payload : natural_t);
Once this is done for a port, incoming messages will carry the payload
instead of the local port:
--- a/include/mach/message.h
+++ b/include/mach/message.h
@@ -136,7 +136,10 @@ typedef struct {
mach_msg_bits_t msgh_bits;
mach_msg_size_t msgh_size;
mach_port_t msgh_remote_port;
- mach_port_t msgh_local_port;
+ union {
+ mach_port_t msgh_local_port;
+ unsigned long msgh_protected_payload;
+ };
mach_port_seqno_t msgh_seqno;
mach_msg_id_t msgh_id;
} mach_msg_header_t;
A new mach type MACH_MSG_TYPE_PROTECTED_PAYLOAD is defined to indicate
that the message carries a payload, not a port name. libports is
patched to handle the payloads. This takes care of lookup number 2.
Removing the need for lookup 3 is actually more involved. It requires
changes to mig so that one can specify a payload-aware in-translation
function. Such a function is almost exactly like the port-based
in-translation function, here is a typical one:
--- a/libcons/priv.h
+++ b/libcons/priv.h
@@ -80,6 +80,12 @@ begin_using_notify_port (fs_notify_t port)
return ports_lookup_port (cons_port_bucket, port, cons_port_class);
}
+static inline cons_notify_t
+begin_using_notify_payload (unsigned long payload)
+{
+ return ports_lookup_payload (cons_port_bucket, payload, cons_port_class);
+}
A thing that we need to take care of at this point is that some server
functions actually expect a port name, not an object. Fortunately this
is easy to cover, we provide an in-translation function for that:
type mach_port_t = MACH_MSG_TYPE_COPY_SEND
intranpayload: mach_port_t HURD_DEFAULT_PAYLOAD_TO_PORT;
There are some gory details at this point, but I'm confident that all
issues can be dealt with. The kernel and mig parts seem to be feature
complete for my current needs, and I've been running the patched
kernel compiled using the patched mig just fine for the last day or
two on my development machine. An earlier Hurd patch series that did
only address lookup #2 but not #3 did actually boot on my test machine.
The Hurd part is what it is. hello{,-mt} work, so does tmpfs. I broke
rpctrace, libpager, proxy-defpager, ext2fs hangs, bootstrap fails,
exec replies EOPNOTSUPP so I must have broken an lookup there...
The really nice thing about this approach is the smooth upgrade
path. The protected payload code in libports is used only as an
optimization, so if it is run on an older kernel, it will fall back to
the port-based lookup #2 *but* will then store the object's address in
the message. This way, the third lookup is optimized away. It's a
kernel patch that makes Hurd faster on unpatched kernels. It's that
smooth.
But I need a break from this stuff and I wanted to get your
opinions. The code is here for easy access:
http://darnassus.sceen.net/gitweb/teythoon/gnumach.git/log/refs/heads/feature-protected-payload-4
http://darnassus.sceen.net/gitweb/teythoon/mig.git/log/refs/heads/feature-protected-payload-2
http://darnassus.sceen.net/gitweb/teythoon/hurd.git/log/refs/heads/feature-protected-payload-3
I'll spam the list with the patches to get the discussion going :)
Justus
--
To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/20131128235647.1092.90...@thinkbox.jade-hamburg.de
